Labyrinth of Good and Bad Decisions

Common Mockup Pitfalls

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

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.

Use Black & White Mockups

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.


What now:

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone


  • Stephanie Cracknell

    Great article, and great point about not being misunderstood by developers. The developers are such an important audience and it is all too common to nail the mock ups with the users, with one understanding, and then the developers look at the same mock up and have an entirely different understanding.

    Can’t wait for the finished book to come out!

  • Robin Bonenfant

    I love the fact that you stress that these are mockups and not actually what the finished product will look like. Do you feel that you need to have page design standards for colors, fonts, etc to back up the mockups? Unfortunately at the company we don’t have any written standards and I always get questions from the QA team that the end product isn’t an exact replica of the mockup.

  • Swavek Kublin

    I am a strong proponent of using mock-ups during business analysis. I’m trying to answer myself the following questions:

    * When using mock-ups can be a waste of time? (e.g. wrong stage of the project, insufficient prior knowledge, not right type of project).
    * What are the threats of using mock-ups? (e.g. sub-optimal solution proposed too early, users’ perspective skewed by presented mock-ups).
    * Can you use mock-ups to uncover hidden requirements or requirements that are not reflected in UI?

    I’m wondering what is your opinion.

  • Jose Coronado

    One thing may be missing – understanding of the problem, even before the mockups start.
    – Are all stakeholders on the same page?
    – Do all of them have the same understanding of the problem?
    In general, I have observed that the assumption is that they understand the problem but rarely are on the same page. I address this by spending between 1-2 hours in the workshop session on problem definition. It is not clear if you do this in the process described.

  • Igor


    Very good questions indeed, and your potential answers are at least as good as mine. Let me share what I think on these topics, and I hope to hear other people’s experiences, too.

    Waste of time – Several situations come to mind: too late (late in a project when coding is already half-way through), too soon (when it’s not yet clear whether we are solving the right problem, or even what the problem is), too rigid process (hundred trivial change requests formally require hundred mockups to be developed, confirmed and signed off), technical problem (there is no “business process” as such; or there are no changes at all in workflow or in user interface). Also arguably: too heavy process not suitable for quick mockup turnarounds (dozens of pages describing each scenario or feature, with mockups being there only to “confirm the spec”) – in this particular situation mockups will admittedly have *some* results, but they won’t be nearly as useful as in short-iteration approaches.

    Threats of using mockups – Apart from the threats described in the article, one big problem I can see is that mockups by themselves don’t help you to establish whether you are solving the right problem. Often you can see people diving right in and “starting from the middle” (i.e. sketching the system before they understand the overall problem). Especially when a customer explicitly proposes a solution, as opposed to explaining the problem – which some customers tend to do. The alarm sounds in my head when I don’t understand why something needs to be done (after being explained repeatedly). What usually uncovers the missing information is going a level up and discussing actual business processes, or even the whole value-chain interaction of process groups (for example when I simply cannot be made to understand why some departments need to have access to new system at all)

    Uncovering hidden requirements – I’m not sure whether this is a right emphasis, perhaps the main question is about requirements that are not reflected in UI? I’ll share my mind on both.

    With mockups you uncover hidden requirements all the time. So much, that I’m tempted to say that’s the best thing about using mockups in capturing/testing functional requirements. Just one everyday situation, for example, is finding that a paper document cannot be processed because “one field is missing on the screen” and then uncovering whole new set of business rules and procedures related to that particular piece of information.

    Another (and more hidden, i.e. more relevant for the question) example is asking where does the piece of information comes from – and then finding out that it comes from an external system. Which automatically opens a whole new ally of investigation (uncovering security or connectivity or even organizational requirements). Similar is with finding out that heavy “under-the-hood” processing is required. In both situations some other techniques (not mockups) have to take the ball and identify and define these interactions, but mockups were still useful in explicitly identifying the spots that need to be investigated in more depth.

    But this other part of your question intrigues me – uncovering requirements not reflected in UI. Except for non-functional requirements, could you elaborate or give an example?

    When speaking of non-functional requirements: while I have found that mockups help to visualise the workflow and thus one is more likely to ask the right questions (e.g. timeframe to process an average customer, or response times of queries, etc), but still in my opinion mockups can’t be relied upon as the main technique for discovering the non-functional requirements.

  • Igor


    Indeed I do hold a 1-2 hour workshop before starting with each new group of screens (sometimes even creating basic sketches right there in the workshop, when e.g. we have developed together several groups of mockups already, so I know enough about the customer and the problem, and the customer understands the mockups). The point is to learn something before diving in as well as setting expectations, and at the very least validate that the right problem is being solved.

    Thanks for this question. Indeed, when re-reading both this article and the one on “Basic Mockup Routine” I can see that I really wasn’t very clear on that :)

  • Igor


    Requiring mockups to serve as UI specification is a problem designers or UX specialists would be more qualified to talk about. Most of my experience comes from the functional-requirements perspective.

    Since I don’t do UI specifications, I tend to stick to black&white mockups as long as I can, to avoid confusing anyone. And if later on other work items (e.g. user guide or even a final spec) are derived from mockups then I replace the mockups with actual screenshots (when they become available) for the same reason. On the other hand, if I decide (or am required) to use real-looking mockups, then established design standards do help a lot, and an UX specialists is almost a necessity.

  • Emilio Vasco

    With every UI review that I go through with the business i always include the developer to make sure that nothing being suggested is unrealistic. It also gives them a good sense of what they will be working on. One thing that has made a world of a difference in working with developers is having acceptance criteria from the start. That is truly invaluable.

  • Jeff Rayment

    You rightly say “Developers are actually your users, too.” I would go one step further and also say testers. Many development environments include dedicated testers.
    Similarly users need to do their testing and scenarios/mock ups can be part of their UAT planning too.

  • Cecilia Pearce

    A very insightful document. I have used a similar concept in the past, using MS Word. I believe that if folk can get out of the detail long enough, they will start seeing the benefit of this concept.

    Prototyping is in use on the project I’m on, however, they don’t understand the additional benefits explained in you book.

    I believe that if the design principles are defined upfront, to give business confidence that you are aware of their design principles, it may facilitate your workshops better, business folk do tend to cling to that.

    Design principles also facilitate your mock-ups better, e.g. location of a fields to be constant on subsequent screens together with the name of the field. I’ve just experienced this inconsistence on this project, and if put me off the mock-ups immediately. It just happened to be the User Experience folk who designed the mock-ups using a tool designed for this purpose, and by getting the basics wrong, may just result in their mock-ups being rejected by business. I also found that they got into too much detail too soon.

    Once a mock-up is completed, business should run the various scenario’s through each screen, remembering to test the screens with, what I refer to as the “what if” scenario, (I use to test systems :-).)

    Waiting for the final product
    Well done

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>