Why is every conversation about wireframes I’ve encountered lately so tense? For instance, at a recent UX Book Club meeting whose topic was a discussion of some articles on wireframes, the conversation moved quickly from the actual articles to the question of what a wireframe even was. What the discussion came down to was this: no one knows the answer, and trying to find it feels like a wild-goose chase—or like wandering off on our own down a yellow brick road to find the all-knowing and powerful Oz to figure the answer out for us.
The Wizard of Oz asks questions like: What is courage or heart or a brain?Who should define them for us? As I see it, UX design suffers from similar definitional issues. We don’t all mean the same thing when we say sketch or wireframe or prototype. So how can we all get on the same page? There are differences between a sketch, a wireframe, and a prototype, but how can we understand the distinctions and the best use of each? And what is their value as communication vehicles? Let’s discuss what separates a sketch from a wireframes from a prototype.
Champion Advertisement
Continue Reading…
Sketches
Sketching and design emerged during the medieval period, so these concepts are nothing new. However, what I believe many people forget is that the intention of sketching is to separate design from the process of making. In the context of design, sketching is rapid, freehand drawing that we do with no intention of its becoming a finished product. In fact, many times, sketching is only a foundation upon which we can overlay our actual design work. Thus, sketching is a tool that supports the process of making, not the actual design itself. Unfortunately, it’s all too easy to forget this fact in our quest to get to an end product. We sometimes hold onto our sketches like they are the be-all and end-all of design. Sketches should be
quick—Making them does not require long periods of time.
timely—You can create sketches on demand.
inexpensive—Creating them is cheap, using materials you have on hand.
disposable—You don’t care if sketches get thrown away.
plentiful—Sketches don’t exist in isolation of one another.
clear and use a common vocabulary—Sketches comprise simple symbols and lines.
fluid—They have a fluidity of line and flow that imply creativity.
minimally detailed—Sketches are conceptual and suggest structure.
appropriately refined—They communicate just enough so others can understand your intent.
suggestive and exploratory rather than confirming—When sketching, you haven’t yet made any concrete decisions.
ambiguous—You have yet to work out the details, then overlay your design on the foundation your sketches provide.
Wireframes
A wireframe, in comparison, is a basic visual guide we use to suggest the structure of a Web site, as well as the relationships between its pages. Wireframes come long before we do any visual design. A wireframe’s purpose is to communicate and explore the concepts that come out of sketching—that is, those concepts you actually want to pursue further during user interface design. Wireframing lets us outline a Web site’s basic, overall structure and flow and helps us explore divergent ideas from our sketches. I like Will Evans’ definition of wireframes in a recent article called “Shades of Grey: Wireframes as a Thinking Device.” He says, “for me, wireframes act as a form of thinking device for the setting and exploration of a given problem space.”
You’ll see there isn’t much change from sketch to wireframe—merely a slight refinement and greater formalism. Our initial drafts of wireframes remain tools or artifacts that we use during the process of making to aid conversations as design moves forward. Wireframes should be
quick—Making them does not require long periods of time, but they do take longer than sketches.
inexpensive—Creating them is cheap, using materials and tools you have on hand.
viable—Wireframes are not as plentiful as sketches, so you should have narrowed your concepts down to viable options.
clear and use a common vocabulary—Wireframes comprise simple symbols, lines, and indicators of interactivity.
minimally detailed—They are conceptual and suggest structure.
appropriately refined—They communicate a sense of structure and layout.
confirmatory—Wireframes present concepts that need validation. When creating wireframes, you still haven’t made any concrete decisions.
ambiguous—You have yet to work out the finer points of interaction and content.
Prototypes
As we iterate our wireframes and get clarity on requirements and constraints, some of our ideas naturally fall away. It is at this stage I would say a real prototype exists. Our designs are still not final, but we have defined a set of ideas we know can actually be pursued, and we begin to refine and exemplify them. We may invest some light coding in them to achieve a degree of interactivity, but a prototype is still a communication tool and artifact. Prototypes should be
quick—They should require only minimal development effort.
inexpensive—The development they require does not require a major investment.
clear and use a common vocabulary—Prototypes comprise simple symbols, lines, interactive components, and content.
detailed—Prototypes include content and interactivity.
appropriately refined—They represent an almost real application—though with a faked user experience.
validated—In prototypes, a design is no longer ambiguous or suggestive. A prototype is an actual instantiation of an idea. However, it may still require fine tuning.
Understanding the Continuum
Now comes the tricky part: deciding when a sketch stops being a sketch and becomes a wireframe, then a prototype. There is no clear boundary line separating these design artifacts, which is probably what makes our conversations about them so contentious and hard to articulate. In Bill Buxton’s book, Sketching User Experiences, he provides some descriptors of sketches and prototypes that ring true with me (see Table 1). They elicit the feelings the ends of the continuum should embody.
Table 1—The Sketch to Prototype Continuum, from Sketching User Experiences
Sketch
Prototype
Evocative
Didactic
Suggest
Describe
Explore
Refine
Question
Answer
Propose
Test
Provoke
Resolve
Tentative
Specific
Noncommittal
Depiction
In Figure 1, I’ve attempted to articulate a Sketch to Design Continuum visually. This illustration depicts the relationships between a design’s level of commitment and fidelity and what you are trying to communicate. These are the factors that matter when deciding where you are in this continuum. While the lines demarcating sketches, wireframes, and prototypes aren’t clear, the phases of ideation, concept validation, and refinement and usability are—and that’s where we should focus our attention.
Figure 1—The Sketch to Design Continuum
Sketches or wireframes support ideation and concept validation, while wireframes or prototypes are important for refinement and usability testing. When we are exploring and validating our divergent design ideas, a lack of commitment is important and beneficial. This allows us to be more flexible in our iterations and, therefore, more creative. As we start to whittle down our design options and refine those that merit further exploration, we need to start articulating them in a more realistic manner, so everyone on a product team can participate in the design conversation with the same understanding. This is why it’s more important in later phases to create wireframes or prototypes.
There are also clear differences in the communication that happens during each phase that help distinguish which artifact is the best vehicle. And lastly, you can see that the amount of iteration that occurs gets smaller and farther apart as we move toward the ultimate design. This is a natural progression as divergent ideas converge in an actual solution.
Why the Differences Don’t Matter If You Get the User Experience Right
We often consider our wireframes as deliverables, or final products, but this just isn’t the reality. This can be a tough lesson to learn. I know I’ve already spent a lot of time deciphering the semantics, but we couldn’t have gotten to this point without having first cleared some of that up. The reality is that wireframes are a design artifact—that is, a tool that facilitates the process of making that leads to design. Buxton says the lesson The Wizard of Oz teaches us is that, if we can do an effective job of following the example of the Wizard, we, too, can conjure up systems that let the people who use our products have real and valid user experiences, before any system exists in any real sense of the word. Keep the following in mind:
It is the fidelity of the user experience, not the fidelity of the sketch, wireframe, or prototype that is important from the perspective of ideation.
We can use anything we want to conjure up such user experiences.
The earlier we create such design artifacts during the product development lifecycle, the more valuable they generally are.
It is much easier, cheaper, faster, and more reliable to find a little old man who can create the illusion of wizardry with a microphone and some loud speakers than it is to find a real wizard. Fake it before you actually build it.
Think about this: Developers never actually implement a wireframe as it is—or, at least, I hope they don’t! That doesn’t diminish the importance of wireframes by any means. Creating these artifacts is critically important to a successful design process that leads to a successful product. Let’s just remember the purpose of these artifacts. As Will Evans says, “I use my sketches and wireframes as [a] means to make explorative moves and assess the consequences of those moves. As I explore the problem space, I could relatively easily keep the design models in my head, but I would fail in my primary objective to create a framework for a conversation among the stakeholders, the intended audience, and me.”
The Rehearsal to Production Continuum
If you’ve read any of my other columns, you are probably wondering where the theater is—besides the example of The Wizard of Oz that is. This time, I felt the need to clear up some preliminary points before getting to any theatrical analogy, but here it is: if we treat our sketches, wireframes, and prototypes as what they are—artifacts of the design process—we can see the whole process as nothing more than an iterative rehearsal process, as shown in Figure 2.
a way of establishing structure—in design, the design artifact
Figure 2—The Rehearsal to Production Continuum
Looking Beyond a Single Production
Rehearsal is just one example of how theatrical productions know how to articulate and separate the process from the product. Looking at a bigger picture than any actual, individual theatrical production, there are other parallels to the concepts of sketching, wireframing, and final design in some types of theatrical productions as well.
For example, a sketch is like a staged reading. A staged reading is very much what it sounds like. The actors get up on stage, with almost no rehearsal and no memorization, and run through a show with script in hand. There is no production and minimal, if any, blocking or prep time. A staged reading is a creative experiment in a realistic setting, with an audience that provides feedback. It never turns into anything more, and a theatrical group usually performs it only once. Similar to a quick sketch that you can dispose of later, a staged reading is a tool that lets you talk about a story and its concept with an audience.
A show in a black-box theatre, which seats less than 150 people, is not much more than a prototype or proof of concept. It is a performance that occurs in a small space and has minimal production or technology. The people producing it have narrowed down their ideas, and the content and interactions are there, but they have undertaken no major development. We expect a performance that feels real, and such a show is much like a fully produced show, but its run is short lived, lasting only a few weeks at most.
A Broadway show, on the other hand, is a fully developed product. Lots of work, technology, marketing, and money have gone into it. Shortly before opening night, you can do only minor testing to tweak what is essentially a finished product—similar to doing usability testing at the end of a product development cycle—because big changes would be both difficult to do and expensive. This is the kind of production that runs years—or maybe even decades for a show like Cats.
Become Your Own Oz
Ultimately, I do feel the conversation at our UX Book Club meeting was a good one. It’s nice to get a handle on the perceptions and semantics that are out there and understand what the issues really and truly are. Whatever we call them, all three of these design artifacts are relevant when we use them in the right phase, for the right purpose. But, to make the right decisions for your own projects, you need to become your own Oz. Create design artifacts that adequately define a user experience to help you get good answers to your design questions. When we use these tools as communication vehicles during the design process and understand that they are not themselves the end product, they can help us to design successful products.
References
Buxton, Bill. Sketching User Experience: Getting the Design Right and the Right Design. San Francisco: Morgan Kaufman, 2000
Thanks for a great, helpful article. I can sympathize with the frustration of those who have difficulty defining wireframes. Every company, it seems, has its own definition and style. I’ve dealt with them as far back as CAD in 1990. Focused on Web apps from 1998 onward, I’ve seen:
Sketch > HTML prototype
Sketch > graphic app (Adobe or Quark) > HTML/CSS prototype
All of these, of course, had different levels of detail in the wireframes. My favorites incorporated a certain level of color coding, along with in-page descriptions with separate notes as needed, as opposed to numbered footnotes alone. (Some time ago, a hiring IA manager with limited experience looked at one of these and told me to “come back when I had more experience.” I had to laugh.)
In the vast majority of places, wireframes took into account things like calls to action, alignment, component size, navigation strategy, an so on. They also encompassed larger issues like site flow and overall structure. For any navigational testing, the HTML/CSS prototypes are my personal favorite, as they make it incredibly easy to demo interactive menus and discover flow problems. One place removed the requirements for size and alignment, leaving that in the hands of the graphic UI designers.
I suppose it’s similar to the way the term information architect has changed over time. When I first became one, it included information design, back-end database design, buckets, and taxonomy. Wireframes came late in the process. (I called it data usability when I was consulting, because I optimized the information flow, accuracy, searchability, and interface back-to-front.) Now, too many companies want their IAs to content themselves with simply creating wireframes, and it’s a sad waste of talent.
I appreciate the article, but I think it gets a little too deep in the weeds in worrying about what to call the artifacts. Als,o there is a little too much overlap in the definitions offered to be useful.
The way I think about it: sketches are just disposable iterations of a design, prototypes are interactive presentations, and wireframes are unrendered designs.
While this article hints at it, it doesn’t really address the question of fidelity. There can be many levels of fidelity across wireframes and prototypes, and there’s no real mention of how visual design comps fit into the picture.
I don’t disagree with you, Jamie. The question of fidelity is an important one. It just was not the focus of my point for this column.
My definitions are overlapping because I believe that the truth is that there isn’t a clear line between them. And I don’t believe there has to be either. If you recall, I did say sketches are the framework on which design is overlaid. What I wanted to articulate was that, whatever form you use, the artifact is meant to be a tool to help the design process and is not the actual end product—even if, in the end, the visual design is derived from or overlaid onto our sketch or prototype or wireframe. There is still another step required to make that translation. Though, yes, agreed, a wireframe or prototype sometimes does happen to get developed as is. I was implying that I hope it does not.
Understanding the phase of the process you are in and communicating accordingly, with the right fidelity, is important and not something that happens only with the design team. This is something I reflected on with my quote from Will Evans that talked about the artifact being a tool for conversation between me, the stakeholders, and intended audience.
You raise some interesting questions about the future and the direction in which technology will take us. I really like your words “throwaway,” “evolving,” and “mature” as a way to describe the artifact. They help imply an appropriate level of fidelity. Like Bill Buxton’s words, they elicit more of a feeling that people can understand. But I hope we, as UX designers, never truly separate from the idea of a sketch, because as a thinking tool, nothing compares! Sketching is also quite important to making design conversations productive, because it helps to have a concrete and shared understanding of what is being discussed and shared.
Maybe I’m way off in how most people use the terms, but I thought sketch, wireframe, and prototype were defined by their function, not their level of refinement: sketches illustrate a design for discussion, wireframes are specs for development, prototypes are representations for testing.
I would say there is a strong tendency for there to be a continuum of refinement as you go from sketches to wireframes to prototypes in most design processes, but by my definitions, it doesn’t always have to be that way. They are not necessarily even physically separate artifacts.
A colleague and I scribble a Web page design on a cocktail napkin, discussing pros and cons: that’s a sketch. The bartender asks what we’re doing. Sensing an opportunity for a little usability test, I hand him the napkin and say, “It’s an idea for a foo site. If you were to foo your bar with this, what would you do?” Now the same napkin is a low-fidelity prototype. Afterward, our developer arrives, studies the napkin and says, “That’s enough for me to get started,” so we let him keep it. Now the same napkin is a wireframe. Note that even the order isn’t necessarily a sketch, wireframe, or prototype.
I have read your article about the process for creating wireframes and prototypes. It was very interesting and helpful, but I’d like to add some extra points, as follows:
With over fifteen years of experience as an interaction designer and user researcher, focusing on user-centered design methods, Traci has experienced a broad range of work practices. After ten years of consulting, Traci transitioned to working on staff with product teams at companies such as Avid and Oracle. Through her UXmatters column, Dramatic Impact, Traci shares how she infuses aspects of theatrical theory and practice into her design practice to bring a more empathetic, user-centered focus to her work. Traci holds an M.A. in Theater Education from Emerson and a B.S. in Communications Media from Fitchburg State College. She is a member of the Boston chapters of UXPA and IxDA and has spoken at conferences such as the IA Summit and Big Design. She is also a nominee for the 2016 New Hampshire Theatre Awards in the best supporting actress category. Read More
we use to suggest the structure of a Web site,
