Live by the Mockup, Die by the Mockup
Published: February 6, 2006
Mockup… The term itself brings to mind the duality inherent in this omnipresent design artifact. It’s both a direct representation of a product experience and a shallow portrayal of an interactive system at the same time. Perhaps the term originated with engineers or product managers intent on pointing out that the mockup was just that: a superficial representation that could never compare to the real product they had to build.
Regardless of what you call it, the mockup can either sell your design or plummet you into a cyclical tunnel of churn. That’s why, like it or not, interface designers often live and die by the mockup.
Live by the Mockup
“How would I summarize the importance of design vision communication deliverables? He or she who owns the drawings, [mockups, storyboards, or wireframes] owns the vision.”—Jim Leftwich
There are few communication techniques available to interface designers that speak with the immediacy and relevance of the mockup. When properly designed, a mockup presents all of the content and actions that are associated with a specific product interaction and communicates both their relative importance and their relationships to each other and the entire application. A mockup explains how users know where they are in a flow, how they can complete a task, and what other options are available to them.
It’s little wonder that mockups often stand in for functional specifications today—especially in agile development processes. A mockup makes visible what needs to be on a screen and where. When used in sequence, such representations can depict state changes, basic interactions, and dynamic information. In other words, we can use mockups to illustrate a large part of the product experience.
Through a mockup, we can articulate a product’s messaging as well. What is this? How do I use it? Why should I care? Showing the mockup to potential users and stakeholders, therefore, can communicate the essence of a product quickly and easily. High-fidelity mockups are especially capable of eliciting powerful reactions. It takes only a second—or 50 milliseconds, depending on who you ask—to determine whether a product design appeals to you. We can use this strong emotive reaction to effectively sell a design. Get the visceral design right, and you can reap the benefits of a positive audience response.
Mockups are, by their very nature, much easier to iterate than real products are. Need to add a feature? No problem. Want to reposition the product’s value proposition? Not an issue. This flexibility, however, is both a blessing and a curse, as not all things about mockups are positives. While a mockup can vividly communicate a slice of the product design, it represents it alone and out of context.
Die by the Mockup
In essence, a mockup is a portion of a product isolated in time. As a result, it does a poor job of communicating rich interactions. Timing, transition, and response are, after all, difficult to illustrate on a static page. A mockup also has a hard time communicating how it fits into the system that really defines a product. Interactive products are not sequential pages; they are a series of components, processes, and possibilities. A static mockup has little hope of capturing this complex dynamic, and most stakeholders unfortunately have a hard time interpreting the types of artifacts that more effectively communicate interactions such as flow diagrams and storyboards.
A mockup’s isolation from the system that defines a product experience often means it must hold its own weight against criticism. It can’t count on the rest of the product to define and promote it. Perhaps this is why mockups often suffer from feature bloat, which then makes its way into the final product. Because the mockup is responsible for representing all of a product’s features, all the features have to be present.
“He who can define the problem, declares the solution.”—Bob Baxley
As if being isolated from the complete product experience weren’t bad enough, many times a mockup is presented without the larger market and organizational context that created it: what is the problem this design is trying to solve? There are many aspects of problem definition: technical limitations, user research, market data, past experiences, and more provide the constraints and opportunities that ultimately define a design.
By framing the presentation of a design with problem definition, designers can focus stakeholder feedback on how well the design addresses their goals. If the proper high-level definition is not present to provide context, feedback can quickly turn into a critique of the mockup not the solution. After all, it’s much easier to have an opinion on font sizes and color choices than on the right strategic positioning of an important product.
If not used judiciously, mockups also have the potential to undermine a designer’s value. Because mockups can be quickly assembled, designers often present stakeholders with too many options and risk opening themselves up to design by committee. The message is: “I don’t know enough about your users or goals to give you the right answer, so you pick what works best.” Now the design is in a non-designer’s hands, who may very well be wondering why he hired a designer in the first place. There’s also a very high probability that upon seeing multiple design options, a stakeholder will ask for some of each one resulting in a Frankenstein design.
A Solution, Not a Mockup
When interface designers focus too much on mockups rather than product solutions, the design profession may suffer. This type of dilemma already exists for visual designers, who are routinely called upon just to “make things pretty.” As a result, every interface designer should focus on building a reputation as a problem solver and communicating that through the language of design and business. The presentation medium will change, the need to solve problems will not.
Grohol, John. “Web Users Judge Sites in the Blink of an Eye.” Dr. John Grohol’s Psych Central, January 14, 2006. Retrieved on February 6, 2006.
Scrum. “What Is Scrum?” Retrieved on February 6, 2006.
Wroblewski, Luke. “Design Vision: Introduction.” Functioning Form, February 5, 2006. Retrieved on February 6, 2006.
Wroblewski, Luke. “The Three Aspects of Visual Design.” Functioning Form, April 16, 2004. Retrieved on February 6, 2006.