Live by the Mockup, Die by the Mockup

Communication Design

Musings from the merger of medium and message

A column by Luke Wroblewski
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

Champion Advertisement
Continue Reading…

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. 

More Reading

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.

Product Director at Google

Speaker and Author at LukeW Ideation & Design

Silicon Valley, California, USA

Luke WroblewskiBefore joining Google, Luke was CEO and cofounder of Polar and Chief Product Officer and cofounder of Bagcheck. He is the author of three popular Web-design books—Mobile First, Web Form Design, and Site-Seeing: A Visual Approach to Web Usability—in addition to many articles about digital-product design and strategy. He was also the founder of LukeW Ideation & Design, a product strategy and design consultancy. Luke is a top-rated speaker at conferences and companies around the world, and was a cofounder and former board member of the Interaction Design Association (IxDA).  Read More

Other Columns by Luke Wroblewski

Other Articles on Communicating Design

New on UXmatters