Mockups are expensive to create, hard to iterate on, and communicate all the wrong things. Why does our industry rely on them?
If you’re a digital product designer, chances are high that you’ve put together scores of mockups throughout your career. The trusty mockup has become such a staple in design team workflows that their production and circulation has become synonymous with design itself. At most design crits, the anticipated “thing to get critiqued” is a mockup. The bulk of the design team’s suite of tools is centered around producing, sharing, and iterating on mockups. As designers, we pride ourselves on the ability to get to the true rationale behind decisions, so maybe it’s time to ask: why?
Mockups, ultimately, are only communication tools. Their costs and benefits will vary wildly between organizations, so here are some questions to think about in the context of your team.
- What do mockups communicate?
- How much time is spent creating them?
- Who needs mockups to do their job?
- Why do they need mockups?
- Can that need be solved in another way?
Mockups are very information-rich. They do a decent job of conveying layout, visual, and, in-series, workflow. They tend to be fairly expensive to create — somewhere between prototypes and sketches. Their low bar for interpretation appeals to engineers, managers, and users alike. At the same time, though, many of the problems they solve can be solved more cheaply by other methods. More importantly, a heavy reliance on mockups for understanding design decisions is not only an indicator of but also a creator of organizational dysfunction.
Design is the process of solving problems
The first thing we need to address in order to honestly assess mockups’ efficacy is the false synonymity between “designing” and “mocking.” Design is the process of solving problems. One way you can go about communicating a solution to a problem is with a mockup, but it’s not a necessary feature of doing design. The artifact-agnostic nature of design is especially evident when comparing digital product design to other forms. While the process of organizational design may yield an org chart as a communication tool, the org chart is not the output of the process — it’s exhaust — a byproduct. Process design and system design likewise may yield visual artifacts, but they are again byproducts of the actual “doing design.” In all cases, the organization itself, the process itself, the system itself, and indeed the product itself is the true output of design.
Mockups can be helpful in some specific scenarios, but I contend that these scenarios are highly suboptimal and should be addressed head-on if they exist in your team. When you must get sign-off from a higher up on every detail of a view or interaction, mockups are a great way to communicate those details. When you have long iteration cycles with engineering teams and must completely “spec” the thing to be built, mockups are also great. These two scenarios, though, describe the waterfall model of product development. Even if the rest of your organization is decidedly not operating under this model, these two things should be warning signs that at least the design team is.
So what are the alternatives? For anything that mockups are good at communicating, there is a much cheaper option that every designer should consider. For layout, paper sketches are trivially easy to produce and iterate on. For visual style, hopefully you already have a design system that addresses 95% of cases with consistency. For workflows, a simple diagram mapping between screens (or lo-fi sketches) is much more efficient both to create and digest than a series of mockups showing every stage of a workflow.
Mockups are inherently communicating something that we are not yet certain of
You may be skeptical that other artifacts of design are easier to digest, and I admit there’s some nuance here. Mockups are readily digestible by all sorts of people — up above I referred to this strength as a “low bar for interpretation.” However, it’s easy to digest the wrong things, and simultaneously hard to distill the important things from all of the visual input. If you’ve ever answered a question about a mockup with, “that part isn’t really defined yet,” you’ve experienced the problem. Mockups are inherently communicating something that we are not yet certain of — otherwise, they’d be mockups identical to an existing, successful product, i.e. pointless. However, there’s no good way to express uncertainty in a mockup, so any individual mockup becomes ambiguous at best, and misleading at worst.
The specific risk is that, after engineers learn that not all portions of a mockup are set in stone, it becomes difficult for them to detect which parts are set in stone. Misunderstandings between designers and engineers over what’s fungible and what’s not is a frequent source of tension and bad output. This effect isn’t surprising, either. When people are looking at two proposals, one of high precision and one of low precision, they are likely to assume that the high-precision one gains its precision from information that the proposer has and the recipient does not have. That is, if you show someone a mockup that contains an error and show someone a sketch that contains the same error, they are more likely not to detect or flag the error in the mockup, by virtue of the mockup being more precise. They will assume you have information that justifies the decision.
A good designer should understand the craft as a complicated game of cost-benefit analysis. By far, the steepest cost in product design is the implementation cost. With this in mind, we should work in such a way that engineers’ expertise in particular is leveraged to its fullest extent and as early as possible. A reliance on mockups does precisely the opposite: they cost designers huge amounts of time to produce and iterate on relative to other tools; they ambiguously communicate fungibility to engineers; and they negatively influence a stakeholder’s likelihood of flagging high-cost decisions and generating lower-cost ones.
As designers, we must learn as many tools of communication as we can, and we must honestly assess their strengths and weaknesses so we can choose from our toolbox effectively. Sitting next to an engineer and sketching things out will allow you to devise solutions informed by both of your skillsets. Words and diagrams will help to focus people on the important parts of your ideas and not get distracted by the details of a misleadingly precise mockup. Weening your team off of mockups will make waterfall-y components of your workflows stand out like sore thumbs and necessitate more interactive collaboration between stakeholders.
Learning to surface the relevant expertise from all stakeholders will yield the best results that your team is capable of producing.