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.
There are two quotes I particularly like:
“Prototypes can be wellsprings of knowledge, but they can also betray the whirlpools of organizational ignorance” - Dorothy Leonard- Barton
and:
“The truly insightful model is a truly inciteful model” - not sure who said it, but I think I read it in Serious Play…
Very well written article. I have found myself, as I am sure everyone else has, at times in this position. My only quip is that simply because you don’t create a mockup and explain things to the client so that they agree with your solution to the problem does not mean that said client will not have something to say about or want changes to the product.
Inevitably, the client may want some aspect of the design emphasized or want to change the color scheme of a certain area or the entire site. I believe while back-seat-designers are sometimes a pain, we as designers should let the client get involved in the process. We should still retain a role of professionalism, giving our thoughts and professional opinons, but a client that is invested in the process and feels a part of it can be a strong ally if guided by us in the right direction.
The client should be our partners throughout, not simply onlookers, then come in at the final stages. That can be disastrous. If anything, there should be checkpoints that everyone agrees upon, before moving on.
Hi David, I’m certainly not advising against checkpoints. I fully agree involving the right team members and stakeholders throughout the process is a key to success. What I am saying is that at EACH checkpoint—anything designers present should be shown in the context of the problem or customer need being addressed. Too many time images are simply emailed or posted on an extranet for client feedback. There is no context, no explanation of how the design addresses project goals, etc.
So yes, of course you should get client input—but do it within a discussion of a solution—not a mockup.
Mockups are wonderful things in the right hands. By far the biggest problem I’ve found when using them is getting across the point that just because it may look “done” does not mean it’s anywhere near actual completion.
I try and make my mockups as close to the final product in terms of look and flow; in recent years, that’s meant mockup Web apps with dummy data. Thing is, those figures are not real data. There’s still lots and lots of plumbing to do before a single TCP/IP packet goes out the door.
Before 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
