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.
Sketches
“The intention of sketching is to separate design from the process of making.”
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’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.”
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
“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.”
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
“There is no clear boundary line separating these design artifacts….”
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
“The reality is that wireframes are a design artifact—that is, a tool that facilitates the process of making that leads to design.”
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 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.”
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.
I keep coming back to an idea that I first discussed in my column “The UX Designer’s Place in the Ensemble” and again, in more detail, in “Putting Together a Production: A Rehearsal Strategy for Design.” As I said in that second column, design is not a linear process. Rather, like rehearsal, design is a process that has
- an iterative cycle
- distributed, independent, simultaneous invention
- unifying action
- a director who facilitates
- a forum for conversation
- 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.”
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
“Whatever we call them, all three of these design artifacts are relevant when we use them in the right phase, for the right purpose.”
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.
This article was originally posted over at UXmatters by Traci Lepore. The title already tells, Tracy is comparing three tools: sketches, wireframes and prototypes.
