Shades of Gray: Wireframes as Thinking Device | Semantic Foundry, LLC
by Will Evans
For me, wireframes act as a form of ‘thinking device’ for the setting and exploration of a given problem space – in this example, a home page 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 UX 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 which allows them to solve one goal quickly, effortlessly, elegantly. In this case, the primary audience wants to easily find the best cruise, at the right time, 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, which explores 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 dialogue 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 information gathering and trying to understand and formulate the design problem. By sketching 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 the idea is worth keeping alive – I think.
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; the one, central 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 CTAs (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.
In this article Will Evans is sharing his wireframe insights and guides through his design process. Please visit Wills site http://semanticfoundry.com/ to learn more about his work. You can also reach him via Twitter @semanticwill.