The art historian Ernst Gombrich offers the following commentary on the intriguing artifact above, pointing out the sensory, cognitive, and cultural contexts needed to interpret the drawing as NASA intended:
"The National Aeronautics and Space Administration has equipped a deep-space probe with a pictorial message 'on the off-chance that somewhere on the way it is intercepted by intelligent scientifically educated beings.'
These beings would first of all have to be equipped with 'receivers' among their sense organs that respond to the same band of electromagnetic waves as our eyes do. Even in that unlikely case they could not possibly get the message. Reading an image, like the reception of any other message, is dependent on prior knowledge of possibilities; we can only recognize what we know. Even the sight of the awkward naked figures in the illustration cannot be separated in our mind from our knowledge. We know that feet are for standing and eyes are for looking and we project this knowledge onto these configurations, which would look 'like nothing on earth' without this prior information.
A second drawing shows the earth and the other planets in relation to the sun and the path of Pioneer from earth and swinging past Jupiter. The trajectory, it will be noticed, is endowed with a directional arrowhead; it seems to have escaped the designers that this is a conventional symbol unknown to a race that never had the equivalent of bows and arrows."
Fortunately for us, it's rare that we need to communicate with alien beings, though it can sometimes seem that our own co-workers are just as prone to misreading our work. As proof, think about how often you've found yourself saying something like, "No, this is not the site architecture...the real layout...the actual color palette."
So then, how do we say what we mean? How can we improve the likelihood that people will interpret our ideas and proposals and design arguments in the way we intend? What's the appropriate form of representation for a given concept, and what interpretive contexts can we safely assume are shared by our co-workers and our clients?
Such questions of intent and interpretation are important to us as designerswe constantly create and use representations that have meanings subject to interpretation. We use sketches, diagrams, specifications, even verbal descriptions throughout the design process to make the concepts in our heads tangible and communicable. In fact, a "design" lives only in our heads and in our representations until it's rendered in its final form, whether the finished product be software, hardware, print, or another medium.
Some professions are disciplined about their representations, with standardized formats and formal systems of notationfor example, electronics schematics, architectural drawings, state/transition diagrams, and chemical process control diagrams. Information and interaction design, however, tend to be less disciplined, with a plethora of ill-defined forms and conflicting nomenclature. Perhaps it's because the field is so broad, or because it's relatively young and its standards are still forming. Or perhaps it's because we're so facile at inventing new kinds of representationswe just can't resist the fun of creating a new kind of diagram instead of using something tried and true. Whatever the reasons, our most fundamental tools lack the communicative power and precision that we need.
Too Much Stuff, Too Many Names
As my favorite punk band says, "freedom of choice drives everybody crazy." There's just too much of everything: diagrams, briefs, plans, models, schematics, wireframes, flow diagrams, decision trees, prototypes, specifications, and on and on. It's not that we don't need many ways to describe our ideas, and not that we can't improve on what's been done before; but increasingly we can't even explain to our co-workers, much less our clients, what we mean by a particular term: is this a "comp" or a "wireframe"? Or is it a "storyboard"? What's the difference?
Ignoring the Interpretive Context
We often don't pay attention to the pre-existing experiences, assumptions, and expectations of our co-workers and clients. This is unwise, given how strongly such frames of reference determine the "meaning" of any given representation. Often, our favorite diagrammatic styles and nomenclatures can be unintelligible outside the interaction design communityand sometimes even within it.
Contradictions of Medium and Message
Anyone who's had to say "no, this isn't the real layout, it's just a sketch" knows how easy it is for a representation to cause misinterpretation, confusion, and generally waste everyone's time. The form of a representation carries information that is crucial to its "correct" interpretation; inappropriate reuse of existing symbolic languages and excessive graphical refinement can subvert understanding.
We're Just Too Damn Good at It
Lore has it that Thomas Jefferson once apologized for the length of a letter, lacking sufficient time to make it shorter. Similarly, we often decide to invent a new diagram rather than find one that's been successfully used before. Although there's always room for improvement, familiarity and proven reliability often serve the design process betterwitness the improvement in programmer productivity due to the "code reuse" ethic that's at the heart of object-oriented programming.
In the remainder of this article, I will discuss some of the attributes of design representations and suggest how a better understanding of these attributes can help us create and wield our representations more accurately and effectively. Ultimately, these attributes may constitute a framework for assessing their appropriateness and efficacy.
My definition of a design representation would be something like "a perceptible expression of a design idea, proposal, or fact." This is unhelpfully broad; therefore, I propose to refine this via a rough categorization of representational form.
Undoubtedly the most common way of representing design ideas, is through conversations about things that could be and things that are similar; we explain ourselves by drawing pictures in the air with our hands; we connect our ideas to our co-workers' own experiences with analogies and metaphors.
Proposals and Plans
Design briefs, project proposals, requirement specifications, process maps, and schedules help us reach consensus on what's to be designed. These are often the broadest, and most abstract, of all representations, yet they are crucial in communicating what the final product or service is meant to be.
Spaces and Clusters
We often need to represent and manipulate design concepts in the most flexible and noncommittal way possible. Clustering techniques such as mood boards, context landscapes, and information maps minimize the influence of existing structures, permit a broad inclusion of topics or features, and encourage reconfiguration and the emergence of relationships.
Most often used to quickly propose design solutions, sketches provide a conduit from idea-in-the-head to idea-in-the-world, making concepts available for extension and elaboration by design collaborators. Sketching is a broadly applicable form, conveying everything from abstract concepts to user interaction to visual style. The ephemeral and casual nature of sketches bespeaks the provisionality of the ideas they represent.
Symbolic and Schematic
Conceptual models, system models, information architecture, and interaction sequences are among the many abstract design aspects represented by schematic and symbolic illustrations. These often depend heavily on established languages of form and symbol to communicate which aspect of the design is being described; for example, lines and boxes imply hierarchical information architecture, circles and arrows imply algorithmic states and transitions, and boxes inside boxes imply graphical layout.
Scenarios and Storyboards
Scenarios and storyboards are widely used to suggest user and product interaction and to portray usage in the context of artifacts, people, and work practices. This form can describe both users' current and proposed activities and contexts, that is, both before and after the product or service is in use. The often sketchy style helps to indicate that the activities portrayed are suggestive of general cases rather than definitive and comprehensive.
Prototypes in all forms serve to embody potential design solutions; this embodiment in turn serves several purposes within the design process: to evaluate an idea within a larger design solution, to prove or assess its technical feasibility, to present it to users for evaluation, and so on. Prototype styles vary widelyin their degree of completeness, level of finish, medium of implementation, and the likedepending on the designer's goals. Though powerful, prototypes are notoriously prone to misinterpretation, with the designer's need to present concepts "realistically" often creating the impression that the prototype is for all intents and purposes equivalent to the actual product.
After form, a key characteristic of design representations is content, the concept or artifact being described. Content and form work together to describe ideas, but it's important to keep straight which is saying what in order to achieve the most concise and powerful communication. For example, in describing the flow of control to module A to module B, the use of a decision tree diagram carries the information "flow of control," whereas the actual lines, boxes, and arrows (which modules are involved and what their states are) carry the content.
Representations play a number of overlapping roles in design; being clear about what a representation needs to do can help us decide on an appropriate form and style.
Specification is probably what most people think that all representations do; however, many are so abstract, provisional, and open to interpretation that few can really be said to specify what is to be designed or implemented. For example, the illustration labeled "Specification" specifies only the broad structures of the site architecture; even in the most detailed map such as this, much is left to the implementer's interpretation and imagination.
Making Ideas and Intentions Tangible
It's difficult for most people to create a detailed mental model of a design idea unless it has some graphical or physical form. This is especially true for those without experience with the relevant domain- and discipline-specific nomenclature; for example, "OK, here the business logic talks to the UI manager through the API"without visualization, these relationships can be hard to see and evaluate.
Making Ideas Manipulable
In many stages in the design process, it's valuable to be able to manipulate the organization, layout, orientation, and juxtaposition of things. Embodying concepts in tangible, readily changeable artifacts enables experimentation and reflection; it helps us notice patterns, similarities, discontinuities, and relationships of all kinds that can be exploited or corrected.
Involving Multiple Ways of Thinking: Verbal, Visual, Symbolic, and Emotional
We use many different expressive forms to describe our ideas: sketching, diagramming, photographing, writing, speaking, gesticulating. Each allows us a certain range of expression, each has its special descriptive power, and each engages in us a particular way of thinking.
How often have you said, "No, it's more like this...", followed by a quick sketch on a napkin or whiteboard? Abstractions are subject to interpretation; the more abstract a description, the more interpretive work is needed to supply the context and details. Thus, we often find ourselves making explicit representations to correct misinterpretations.
Limiting the Issues
At any given time, we can attend to only a few aspects of the complex things we design. We can't grasp the information organization, software architecture, user interface model, and visual design of an entire system at once; rather, we have to consider oneor at most a fewaspects at a time. We often use our design representations to limit the scope of the issues being considered, thus making the ideas clearer and the design problems more tractable. A representation's form can help communicate what its scope is and isn't, and thus limit the discussion that can be had about it; for example, a spare boxes-and-arrows diagram probably isn't describing visual design.
Forcing Things into the Open
Rendering an idea into a concrete representation often highlights design problems: missing subsystems, duplicate elements, inconsistent components, illogical relationships, and excessive scales. It can also reveal patterns and emphasize key ideas. We often chooseoften unconsciouslya representational form for this effect; for example, using Post-It notes to enumerate features can, because of the notes' small size, force each feature to be simple and unitary.
A frequent step in any design activity is stating and restating what we knowa way of making clear the choices and interpretations we've made, of getting all the participants focused on the same goals. We often create simplified summaries of what we know, what we've found out, and what we're assuming in order to make our collaborators aware of the state of a design and to obtain consensus on it.
Summarizing Design Decisions
Often a design representation is a comprehensive proposal of a number of provisional design decisions; in this case, the basic interaction model, specific user interface elements, visual style, and brand application. This interactive prototype conveys a holistic sense of the user experience, represents a (potential) consensus on it, and serves as a kind of integrated specification for the design team.
We often say "here's the site design" or "this is the system architecture," but in reality our representations are quite limited in the scope of their description. They generally describe only a subset of the features and aspects of a system; they are most often abstractions, leaving out final, concrete details; and they generally describe things that are as yet incompletely decided. Thus it's good to keep in mind that any design representation is a partial, abstract, provisional description of the thing being designed, and designers should ensure that the form of the representation doesn't imply otherwise.
What is the relationship between a representation and the thing it describes? This semiotic puzzle has real consequences for information design, in that the things we design and our descriptions of them are often executed in the same media: graphics and interactive software. If René Magritte had been a pipe designer, his client wouldn't have mistaken a drawing of a pipe for the real thing. For information and interaction designers, our tentative visual expressionssymbols, colors, layouts, and so onare frequently mistaken for the final product.
A little semiotic theory can help us understand these relationshipsin particular, its description of the modes of relationship between the signifier (the representation) and the signified (the thing represented).
The signifier does not resemble the signified but is arbitrary or based on convention, so that the relationship must be learned; for example, a Venn diagram indicating the organization of information.
The signifier is perceived as resembling or imitating the signified; for example, the stylized graphical user interface elements we use in our sketches.
The signifier is not arbitrary but is directly connected in some way (physically or causally) to the signified; for example, an icon that stands for and allows access to a particular software feature.
As designers, we are responsible for our audience's interpretations of our representations, and semiotic distinctions such as these can help us create the desired interpretation. Carefully choosing the medium, form, and style of our representations can help our audience understand the relationship we intend to portray.
We make points with our design representations; we inform, suggest, argue, declare, insist; we manipulate the thinking of others, just as we're paid to do. We manipulate both explicitly and implicitly, choosing the form and language of our representations to carry certain meanings. We do so knowing the predispositions of our audience: do they want concreteness, or do they want possibilities? Do they prefer substantial documentation or poetic brevity? Do they get excited by mood boards or by source code? Are they paying for quantitative or qualitative?
To the extent that design succeeds only by good communication, we must take responsibility for crafting our messages: knowing what we mean to say, both explicitly and implicitly, and knowing how those messages are likely to be interpreted. For example, my firm, MetaDesign, has a strong ethic about the information-design quality of all our design representations, even when they represent early, provisional work. Though it could be argued that great information design isn't really needed at such an early stage, it builds the client's level of trust in our competence and dedication to quality. Thus our rhetorical intent is twofold: to communicate the state of our design and to assure the client that she's in good hands.
We can be better designers by paying attention to the rhetorical intent of our representations, thoughtfully using both explicit and inexplicit means to inform, propose, and convince as appropriate.
Semiotic theory relates "genres" to "interpretive communities" thus: a genre constitutes particular conventions of content and form, whereas an interpretive community shares certain values, attitudes, assumptions, and practices with which it creates and interprets that content and form. I believe this provides a useful framework for managing all the aforementioned aspects of design representations: content, form, role, scope, intent, interpretation, and so on. These two frameworksgenre and interpretive communityare at once specific and flexible, giving us a common language with which to describe our representations and their audiences with some hope that our messages and intent can be understood.
With such tools, we are better able to conduct disciplined, accurate, and productive conversations about our design representations by referring to genres and the interpretive communities they're appropriate to. For example, if we know that a "layout sketch" (assuming there was such a genre we all agreed on) isn't normally used by "software engineers" (an interpretive community), we might quickly spot the mismatch and decide to either use a different kind of representation or simply not ask a software engineer to make an informed decision from a layout sketch.
As a working designer, I wish terms such as "layout sketch," "wireframe," and "schematic" denoted usable genres; but it seems every time I use themor hear them useda lengthy discussion ensues: "What do you mean when you say 'wireframe'? Isn't this a schematic?" How do we get our genres to be genres? How can we encourage them to be stable and unambiguous? Perhaps it's a matter of timegenres and interpretive communities evolve together over timeor maybe it's a matter of policy-making by the interaction design community. Perhaps a conference workshop would be a good first effort to identify potential genres and communities. If you've got an opinion or idea about that, let me know: email@example.com.
Harry J. Saddler
350 Pacific Avenue
San Francisco, CA 94111
Design Column Editors
89 South St, 2nd Floor
Boston MA 02111
Rivendel Consulting & Design, Inc.
P.O. Box 334
8115 La Honda Rd. (for courier services)
La Honda, CA 94020 USA
©2001 ACM 1072-5220/01/0700 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2001 ACM, Inc.