Shades of Grey: Wireframes as Thinking Device

A picture is worth a thousand words. An interface is worth a thousand pictures.
    Ben Shneiderman, 2003

My good friend Russ Unger recently published a book for Peachpit entitled A Project Guide to UX Design, and he asked me to contribute some designs for his chapter on wireframing, which I was pleased to do. He provided me with some background information and requirements for the redesign of a fictitious cruise line operator homepage, and asked that I design some annotated wireframes that he could use as examples in his book.

After I had completed this little exercise, he asked me to write a brief explanation of my process. This is the unabridged write-up I sent over to him explaining my use of wireframes as a "thinking device" in the design process. No doubt it will be edited to fit the constraints of the book, but he was kind enough to let me post the original here.

Shades of Gray: Wireframes as Thinking Device

For me, wireframes act as a form of 'thinking device' for the setting and exploration of a given problem space—in this example, a homepage for a cruise line operator. To understand the utility of wireframes it is important to understand the nature of designing. I think of "D"esign as an exploration of the conceivable futures. I use my sketches and wireframes as 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.

I think it is quite common for user experience folks to view design as problem solving. For me, designing through the use of wireframes is a search in a problem space of alternatives; it's a process of problem setting as much as it is a process of problem solving, which means that I always start with the context. To simplify, I pick my primary audience and the one activity that allows them to solve one goal quickly, effortlessly, and elegantly.

In this case, the primary audience wants to easily find the best cruise at the right time and for the right price. I don't even look at the requirements document or competitive analysis until after I have sketched a couple of ideas (either on paper or using OmniGraffle) that explore the primary goal. I'm not looking for solutions at this point because the first round of wireframes provide a space to engage in a conversation with other designers, stakeholders, and the wireframes themselves.

My design process could best be described as going from a phase of divergence, through a phase of transformation, to a phase of convergence. Throughout every phase, wireframes are presented to stakeholders for critique and conversation.

During the divergent phase, the constraints and possibilities of the design situation are explored. I try to find facts in the design situation that are stable and hold on to them throughout the process. Large parts of this phase consist of gathering information and trying to understand and formulate the design problem and often times are informed by early conceptual models I have sketched. By generating a number of wireframes, I can explore alternatives. All the impossible and conceivable ideas are presented, tested, and in many cases, tossed away.

My initial visions are formed during this phase. In the cruise line exercise I focused on the 'centrality of search' as a driving goal in the design. I already knew that I wanted to design the best cruise line search interface possible, and I wanted that activity to be brought front and center in the design. I sketched the concept of providing immediate suggested cruises even before the user had committed to seeing a complete search results screen. From the homepage, the user would be pulled into a conversation and engaged with the process of finding a great cruise. The concept behind this was first proposed by Peter Hong some years back at Blast Radius while collaborating on a new search interface between their team and ours at Kayak on the PinPoint Travel interface. It was built but then killed, but I think the idea is worth keeping alive.

In the transformation phase, I decrease the number of alternatives, and the scope of my designs narrows as the wireframes speak back to me. I begin to toss out really bad ideas that I might have fancied in the beginning. It's usually at this point that I go back and read the requirements document and try to understand the complete ecosystem of stakeholder and business needs, and address those in the context of my primary design goal: an elegant solution to the primary epistemic activity of my core audience.

It's also at this point that I begin to address other competing needs. In the case of the cruise line operator, I sketched out the header, footer, and static content and blocked out areas in the design for content modules such as calls-to-action and promotions. I share the output from this stage with the key stakeholders, but also bring in the visual designer, development lead, and quality assurance engineer so they can contribute to the process and provide more ideas while pointing out pitfalls and constraints.

Finally, as the designer, I have to make the decision to implement the design in a specification. During the 'convergence' stage, I create two or three candidates for final consideration. I use annotations to empower the wireframe to plead its case to stakeholders and targeted testers.

Here are two somewhat polished wireframes that survived the process. These are by no means perfect, but they do satisfice for the purposes of the exercise and to illustrate what my wireframes look like.

In conclusion, while wireframes are a common enough deliverable used by user experience professionals to communicate design, it's important to understand them as much as a design process as the final deliverable, each with specific goals. The process can best be broken down intro three phases: divergence, transformation, and convergence. By reframing wireframing as a process as instead of an artifact, I believe designers will find they have the opportunity to more successfully create great user experiences.