A Mockup is Worth a Thousand Words

Use mockups to minimize misunderstandings and avoid new requirements popping up in the middle of the project.

Developers complain that customers don’t know what they want. At the same time, customers complain about having to explain the obvious. Many projects can get stuck in this type of behavior.

Fortunately, there is a loophole. Many of the problems that business people find don’t actually require a fully working application. Often, a simple “picture” is enough.

For example, try to imagine describing all that goes into this page without an actual image:

Below is a text-only description for the above example. Although simplified, it’s already getting too complex to clearly communicate the information:

It’s much easier to communicate the same information with mockups.

You can go further, for example using iterative approach, but with mockups instead of code. Only when the people handling the business side have no further objections, then you start coding.

Mockups are easy to do, and everyone understands them. This doesn’t mean that you’ll be fine no matter what you do. I, for one, have made many costly oversights in the years since adopting this approach. With that in mind, my goal is to help you avoid the same mistakes in your own projects.

What I recommend is that you use a basic proven routine for your projects. However, there are several points I need you to understand first.

Think about it. Mockups can be as simple as paper sketches. While I don’t recommend sticking to pen and paper, this approach proves that you don’t need any technical expertise to create mockups.

Several weeks back, my nine-year-old son talked me into developing a battle-card game together. To explain his idea, he drew an interface for the game, and he was quite adamant about what needed to be where and why.

It’s exactly the same situation with your analysts or subject matter experts. With mockups, they can simply show you what they mean, rather than telling you and relying on and assuming a mutual understanding.

Since mockups can be done many times faster than code, you don’t need to stubbornly defend them. When there are flaws, you simply rework your mockups. It’s so fast, you can even start from scratch when needed.

Therefore, the logical strategy becomes using every shakedown opportunity you can. Instead of shrinking from objections, you actively encourage them until you make your prototype watertight.

Involving a customer early saves a ton of trouble, everyone tells you. That’s all well and good, but it’s far from easy to accomplish.

Instead of spending days writing documents that no one really wants to read, you can sketch the screens in a matter of hours and give your customer something that they will immediately understand.

Also, mockups tend to make communication productive and down-to-earth. Early in a project, this can be a great advantage.

Early on, the mockups are about the only thing that everyone can understand. However, just using the mockups is, by itself, no guarantee of success.

Mockups are just a communication device, so how you actually use your mockups to communicate is what’s important.

The basic procedure of using mockups looks like this:

1. Sketch several related screens.
   A good choice are steps a user takes to accomplish a task.
2. Discuss them with the customer.
   Discuss these sketches with your customer and annotate them. This is best done in live workshops.
3. Flesh out the details.
   Flesh out the details over several quick iterations. Don’t try to get everything correct from the start.
4. Repeat.
   Repeat the same procedure for the next batch of screens.

That being said, each step has its own traps, like creating wrong expectations, or getting the wrong kind of feedback. Let’s get into a little more detail.

Customers have very little time to take away from their everyday tasks. For that reason, lengthy documents terrify them, as well as anything even remotely technical.

On the other hand, three or four mockups at a time won’t scare anyone and your customer will be genuinely curious about what you have come up with.

At this point, your main goal is to get your customers’ attention and cooperation.

One obstacle at the beginning is getting everyone on the same page. It helps if the mockups that you discuss are related. This provides an immediate context for your customers to dive in - no explanations necessary.

The best way to start is with several main screens of the application that you are developing. This way, your context is the big picture. Your customers will therefore share their opinions on the most important matters, for example if they recognize that you are not aware of some part of their business process.

Later on, you will want to switch the context to get more depth.

A good way to proceed is to focus on individual scenarios. This shows your customers how real people will eventually use the application, which will further attract their attention. It will also make their feedback productive and genuine.

Note that I use the word scenario here as a rather loose term. It can be a user story, or a use-case, or a number of other things. It doesn’t really matter.

What does matter is to:

• Get and keep your customers’ attention.
• Start with a big picture, and dive into details later.

You create the mockups, discuss them with your customer and diligently write down anything important that you discover, but where do you write it down?

Right there on the screen!

Four things are especially useful to put on your mockups as on-screen comments, as seen in the above example:

• When a decision is made.
• If there is a dilemma.
• When you have a question.
• Who will investigate an issue and report back.

As simple as it sounds, the implications are huge. When you make your annotations a visual part of the mockup, they become hard to miss and even harder to ignore.

Iterations are a powerful concept. When it’s hard to do the job perfectly in one go, it makes sense to do the first pass quickly, then assess what you have and tweak the results until the job is done.

However, iterations often require doing the same thing twice, or even several times. Can you afford that on software projects?

With mockups, you can. They are exponentially faster than coding, and so is any rework that proves to be required after assessing each iteration’s results.

Thus, work in short iterations and plan them in advance:

• Schedule two workshops for each batch of mockups with your customer.
• Hold several rounds of less formal discussions between those two formal workshops.

The more iterations you make, the better the results will be. Fortunately, many ideas can be discussed by phone or email: “Here is a new version of that screen. Is it better now?” These are your micro-iterations.

You want to have as many of these as you need, so don’t waste time on perfecting mockups for any single micro-iteration. Instead, focus on testing your ideas quickly and getting immediate feedback.

In other words, your iterations for a single batch of screens might look like this:

1. Formal workshop: discussing the initial mockups.
2. Micro-iterations:
   1. Getting feedback on mockups in progress.
   2. Getting feedback on mockups in progress
   3. (…)
3. Formal workshop: presenting and confirming the mockups.

Most times mockups are simple sketches of your application’s screens. They are useful because they are easy to create and everyone can understand them.

Reworking mockups is cheap. You can even afford to start from scratch at any time.

Mockups make it easy to engage your customer, making communication productive and down-to-earth. With mockups, customers can show you precisely what they mean.

The basic procedure of using mockups looks like this:

1. Sketch several related screens.
2. Discuss them with the customer.
3. Flesh out the details.
4. Repeat.

Provide an immediate business context by mocking-up several related screens. One way to do it is to start with main business screens, and later on continue with individual scenarios.

Visually communicate what’s important by using on-screen annotations liberally.

Mockups work well in iterations, because they are exponentially faster than coding. Your mockups should be quick, and your iterations short.