Are We Designing Interactions or Designing Software?

Published on Author Christopher Fahey9 Comments

One of the problems faced by designers trying to integrate their work with most software development processes, even (or possibly especially) with Agile development, is that the literature makes no distinction between software development and software design, or at least no distinction that makes any sense to dedicated user experience designers.

The common complaint among interaction designers working with Agile is that, with some important exceptions, the design of the “user interface” is seen as a cosmetic final stage in the overall software development process. The fundamental designing of the software itself, however — the interactions, the mental models, the metaphors and behaviors — is built-in to the overall Agile process, woven in with with and indistinguishable from the software architecture and code development.

In Mitch Kapor‘s Software Design Manifesto, originally delivered in 1990 and included in Terry Winograd‘s Bringing Design to Software (1996), it’s clear that this ambiguity has deep roots:

Software design is not the same as user interface design.

The overall design of a program is to be clearly distinguished from the design of its user interface. If a user interface is designed after the fact, that is like designing an automobile’s dashboard after the engine, chassis, and all other components and functions are specified. The separation of the user interface from the overall design process fundamentally disenfranchises designers at the expense of programmers and relegates them to the status of second-class citizens.

The software designer is concerned primarily with the overall conception of the product. Dan Bricklin’s invention of the electronic spreadsheet is one of the crowning achievements of software design. It is the metaphor of the spreadsheet itself, its tableau of rows and columns with their precisely interrelated labels, numbers, and formulas—rather than the user interface of VisiCalc—for which he will be remembered. The look and feel of a product is but one part of its design.

On my first read, the whole terminology of this felt alien to me. Is the paper spreadsheet metaphor not the “user interface design”? It seems “look and feel” is being equated with “user interface” here, but I think he’s implying that what I consider the user interface is, in fact, the software itself. I suppose this is a more glorified definition of the word “software” than what I am accustomed to, one in which the software design included the mental model of the user’s approach to the software.

On my second read, though, it became clear that Kapor is in fact laying the early groundwork for what we now call interaction design. He still sees it as closely bound with programming, although he is clear that it’s not the same thing. He is also working in a climate where user experiences are far simpler than they are now — graphic capabilities were primitive, network interactions were almost non-existent, and interfraces had few modes, even few features. Today, with the high level of complexity of both computer code and user interfaces, it’s easier to consider the two challenges (user experience and code) separately — or even better giving primacy to the user interface — the part that people actually see and use.

Design and Technology

It’s obviously important that interaction designers are well-versed in what the technologies they are designing for can actually do. I wonder, however, what interaction designers today would think of the degree of technical expertise Kapor requires of designers:

Technology courses for the student designer should deal with the principles and methods of computer program construction. Topics would include computer systems architecture, microprocessor architectures, operating systems, network communications, data structures and algorithms, databases, distributed computing, programming environments, and object-oriented development methodologies.

Designers must have a solid working knowledge of at least one modern programming language (C or Pascal) in addition to exposure to a wide variety of languages and tools, including Forth and Lisp.

In preparing the syllabus for my upcoming course this fall at SVA, I am quite certain that I don’t share Kapor’s technical requirements for a software design education, neither specifically (Forth?) or generally. Instead, I think a firm grounding in a broad range of designed experiences far outweighs any need for hands-on experience in the deepest challenges of technology implementation.

Yes, some designers will delve deep into technology, being hands-on coders and fabricators of interactive artifacts. In fact, some great interaction designers already spend most of their days thinking of themselves primarily as technologists. Others, however, will focus on the design parts of interaction design. These people will most often work closely with other individuals and teams to implement their designs.

In short, great design will come from great designers, and great technologists will make those designs happen. Sometimes these skills will be found the same person, but increasingly not. An interaction design education should support both models, of course.

Interfaces and Software

Despite my difference with Kapor’s admonition, I still think that in a way we are coming full circle. The recently-articulated idea that the “interface is the spec“, or even “the interface is the product“, isn’t so different from Kapor’s thinking. The metaphors, mental models, and processes that users experience using the software are, in both cases, the most definitive and salient qualities of the “design” of the software (not, as many software development processes presume, the architecture of the code or the technical features that happen under the hood).
The important thing that Kapor left out, however, is that the “user interface” — the stuff that comes between human beings and cold hard technology –  should be thought of as including graphic design as well as the underlying conceptual models of the interactive experience he rightly praises. In fact, the “user interface” concept should also include the software’s motion graphics, its sound and music, the copywriting, voice and personality, the community that builds around the product, and so many other qualities of software design that, frankly, had not really come to maturity yet in 1990.

We are only recently starting to appreciate the idea that interaction design is really about the intersection of the behaviors of systems and people (a favorite word of mine for obvious reasons). The explosion of new and innovative software experiences brought on since 1990 by the World Wide Web and console video games, I think, has fundamentally changed our understanding of what software can be.

9 Responses to Are We Designing Interactions or Designing Software?

  1. Thanks, Ben. Your own post expresses pretty much what I see as the difference between the world Kapor was thinking and working in and the world you and I now work in — where exponentially more complex technological products can, and paradoxically should, be designed by designers. By “designers” I mean people immersed in the same stuff designers have always been immersed in — style, culture, communication, art, humanism. And of course technology, but not (or at least not necessarily) technology first. The “design thinking” school is also trying to bridge this gap, I think, and while I am generally skeptical I suppose we should commend them for that much.

  2. I’ve recently started taking more of an interest in interaction design, and have begun to play the role of interaction designer on some projects at work.

    One of the challenges I’ve run into is that because I have a very strong background in both design (having worked as a designer for years) and technology (having a computer science degree that focused on all those theoretical things), I tend to try to “solutionize” — worrying about the “how is it going to be built” rather than letting the developers focus on that while I focus on the users.

    Of course, it doesn’t help that in the past, I’ve usually been both the designer and the developer ;-) But in my limited experience, I guess I’d say that having such a deeply technical background can be both a blessing and a curse. I can understand the needs of the developers and thereby can talk with them in their language, but I always have to remind myself that I’m not doing “software design”.

  3. The metaphors, mental models, and processes that users experience using the software are, in both cases, the most definitive and salient qualities of the “design” of the software (not, as many software development processes presume, the architecture of the code or the technical features that happen under the hood).

    I disagree, to the extent that you’re drawing a false dichotomy here. The metaphors, etc. are indeed the primary qualities of the user interface and experience design, but the code architecture, etc. are also the primary qualities of the underlying software model’s design.

    It’s just an unfortunate coincidence that the two are both often referred to simply as “design”. As a software developer, I am firmly convinced that a well-designed software model should be able to support many different user interface/experience designs with little or no modification required, just as a single UI/X design could be implemented by a wide range of different underlying models.

  4. @Dave Sherohman: Thank you for pointing out the false dichotomy I set up there — I am really trying to avoid those, or any dichotomies at all for that matter.

    That said, I think my point was that the user interface metaphors, the processes, etc, are the only thing the user cares about. Performance and such are obviously important, but a good design will take into account what’s possible technically and design for that. As you rightly note, it’s unfortunate that “design” refers to both sides of this, but I intended it to mean what users think of as “design”.

    I also slightly disagree with the first half of your last statement. Yes, a good software model should be so modular that you can switch out or modify the UI without having to rearchitect the code… but I also think that this is a potentially dangerous way of thinking about user experience because it’s often the root cause of bad UI design, where the UI is seen as something slapped on top of the functionality/code, rather than viewing the code as something that delivers a well-thought-out user experience.

    I’m going to be deliberately controversial here, but I’d rather have a world where designers are ignorant of technology and force coders to jump through hoops to deliver their idealistic user experience designs, rather than a world where coders force designer to jump through hoops to transform functionality into user experience.

    There I go with a dichotomy again! And of course, it’s a false one again — rarely are design and code so ridiculously separated as that. But I think it’s a worthwhile exercise sometimes to imagine the extreme possibilities in order to strategize a software design approach.

  5. I think that any user interface designer worth anything would want to be a part of the design process from the very beginning stages. Everything is thought out up front and then molded into the perfect solution as the project rolls toward completion. Design isn’t how it looks, it’s how it works.

    But I disagree that designers need to become developers or vice versa. Someone who is focused on the user experience should have a high-view understanding of what is possible or not but they should also be allowed to free-think and find innovative ideas and interaction paradigms that move software development forward. If a great idea is thought up and the expert software developer can bend the technology to their will and provide a solution, something amazing happens.

    These are 2 roles that complement each other very well and are rarely done at a high level by an individual person.

  6. @ChrisFreitag Design is how it looks and how it works. The very best software is formed from equal parts excellent software design (incl. db, coding, architecture, etc) and excellent graphic design (incl. graphic design, information architecture, interaction design, etc).

  7. كيرم در كوس خواهر تان شما تمام دنيا را بر باد كرده ايد

Leave a Reply

Your email address will not be published. Required fields are marked *