Common Mockup Pitfalls
Mockups are easy to start with, yet I see several questions raised again and again. Here is a post from StackOverflow that summarizes a few of these concerns nicely:
“I’m struggling to convince the team of developers I work with to let me show users mockups to explore ideas and make sure we understand their requirements fully.
Although I swear that I will repeatedly tell users that nothing is guaranteed to actually appear in the final product (…), the team is dubious.”
Those developers seem to have already experienced a similar situation that scared them. The poster also obviously expects a great deal from his users.
With mockups, the results are much better if you know what you’re doing.
I have seen mockups backfire in several different ways. Fortunately, you can avoid these mistakes by being aware of them. It’s the same as with everything else; the results are much better if you know what you’re doing.
What follows are several issues you will encounter that, luckily, have the same solution. Let’s take a look at the problems first.
False Sense of Progress
When your customers have seen your beautiful mockups, it automatically translates into, “There’s only some wiring under-the-hood left” in their minds. After this happens, there is nothing much you can do: they have already seen it with their own eyes.
Your screens may only be mockups, but you need to make this fact painfully obvious.
Your screens may only be mockups, but you need to make this fact painfully obvious. Mockups make it possible to communicate visually, so don’t simply make it clear through words — do it visually. It’s what people see that matters.
Drowned in Design Feedback
When you present realistic mockups, be ready for all kinds of design feedback – the kind that you typically don’t want at this point in the process.
Early on, you are struggling to agree on basic structure and functionality, so you want to avoid discussions on fonts, colors, and visual identity. Those discussions and objections are wasting time that both you and your customer don’t have and can’t afford.
When you present realistic mockups, be ready for all kinds of design feedback.
Mockups are useful because users comment on what they see, so let them see exactly what you need them to comment on. You can switch to realistic screens later.
So far, we are only focusing on users, but you are also communicating with developers, and they will likely present different surprises for you.
Expecting Developers to Understand Mockups
I was working on one project where a spec was needed extra fast. Therefore, low-fidelity mockups were used to pin down the requirements, while a remote development team got the specifications done in time. Mockups were attached as zipped HTML pages, with a note that they were only presented to illustrate the ideas explained in the spec.
In the first internal build, the system worked fine, but the user interface was both sub-standard and a surprise. GUI developers built upon the actual HTML code from the mockups.
Developers are actually your users, too.
The trouble didn’t stop there. When contacted, the developers loudly complained that the HTML they had received was terrible, and that the people creating the mockups should have a better understanding of their framework’s capabilities. The idea that one might produce a code that wasn’t intended for use simply had no place in those developers’ universe. As a result, they disregarded the instructions without a second thought.
Have you noticed the pattern here? Developers acted exactly as users do. Without a dedicated “translator”, they saw what they expected to see.
There are many ways that developers can misuse mockups, but the above example makes one thing painfully clear:
Developers are actually your users, too.
With that in mind, don’t expect mutual understanding to come for free. You have to work on it, just as you do with your customers.
The Easy Way Out
You may have noticed a recurring theme in all the examples above: people “know” what they see. Furthermore, they see what they expect if left to their own conclusions. What’s more, words are no match for images in this type of communication.
Thus, what you do is visually communicate what you want them to see.
First, you don’t do “nice” mockups, at least not in the beginning. You can use pen and paper, or even a drawing board. Realistically though, you’re better off with a specialized mockup tool that will allow you to easily make frequent changes. However, make sure to use a sketch-based appearance or a black-and-white look and feel that clearly shows it as a “work-in-progress”.
You don’t do “nice” mockups, at least not in the beginning. No one will confuse sketches for the “real thing”.
This way, you are communicating that mockups are only that – mockups. No one will confuse sketches for the “real thing”, neither your customers, nor your developers.
This single piece of advice will steer you clear of a whole set of irritating problems. The above situations are clear examples of what can easily happen in an apparently simple project.
Unfortunately, other traps to avoid don’t have such a “one size fits all” solution. For example, getting your customer to talk.
- Check out my book “Mockups 101: Help Your Customers Understand What They Are Going to Get.”
- Leave a comment, I’ll be glad to know what you think.
- You can share this article with others. To do that, just use the social buttons below.