A really useful article from the blog - graphpaper
Are We Designing Interactions or Designing Software?
February 11th, 2009
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.
