Iterative Mockup Prototyping

Sometimes, product development is straightforward. The client tells you what they want, you produce it, they’re happy with it, they pay you, and everything is fine. This is known as the waterfall model of product development; once the client has signed off on the requirements, the process then moves irrevocably onwards, like a river going over a cliff.

But sometimes things don’t work that way. Common problems include:

•the client changing their mind part-way through development

•the client being unhappy with what you produced

•communication problems – you can’t understand exactly what the client wants.

Iterative non-functional prototyping is simpler than it sounds, and is a fast, cheap, efficient way of getting to the heart of what the client wants, particularly when the client doesn’t actually know exactly what they want at the start.

It entails looping through mockups systematically until the client requirements become clear.

The process

The core process is simple:

•Build a mockup

•Show it to the client and get feedback

•Revise the mockup in line with the feedback

•Show the client the revised version and get feedback

•Revise again in line with the client’s feedback

•Repeat this process until the client is happy with the mockup

•Build the actual product, based on the final mockup.

Because the mockup is non-functional (i.e. it’s just a mockup, without any working parts or working software) it’s cheap and simple to produce, and easy to modify. You will usually catch the key requirements, including the major unexpected ones, within a couple of iterations (i.e. repetitions of the design/feedback loop).

When and why use this approach?

In brief: You can use this approach with clients who are unlikely to know what they want, but who’ll recognise it when they see it.

When a client doesn’t have any previous experience of a product, they can’t know what they don’t know.  This means that finding out their requirements isn’t a straightforward case of asking them to tell you what they want. Instead, you have to help the client discover what they want.

A key factor in this process is recognition. People are better at passive memory (recognition) than at active memory (recall). In the context of product requirements, a particularly important form of recognition is recognition of affordances. This involves someone realising a particular product allows them to do useful things that can be completely unexpected and that open up attractive possibility spaces.

Your prototype mockups show the client what’s possible, and allow them to spot affordances before any actual product build has begun.  This reduces the risk of the client changing their mind part-way through the build, and increased the likelihood of producing something significantly better than the client had anticipated.

There’s also a good chance that the client or other stakeholders will spot important features you’ve missed. Often, these features are so familiar that the client or stakeholders will have taken them for granted, and not thought to mention them.

This method is fast and cheap. If you’re designing software, you can produce surprisingly good mockups using PowerPoint slides with action buttons.

What do you need to measure?

You can use methods such as think-aloud, observation, card sorts and laddering to find out the key features of the product.

Show the mockup to the client and relevant stakeholders, and get them to think aloud while they’re trying it out. This will tell you which features they notice. There’ll be other important features they don’t mention, which is why you’ll need to observe what they’re doing (for instance, when they look puzzled, or when they swear).

To make sense of why they’re mentioning particular features, you’ll need to use upward laddering. To make sense of subjective or technical terms that they mention, you’ll need downward laddering. You can discover some requirements by laddering upwards on the client’s goals and values, then laddering downwards on ways of including them in the product design.

At the end of this process, you’ll know which are the key aspects of the product to focus on improving through subsequent versions of the mockup.  To cross-check your mockup against market competitors, or against other mockups you’ve created, you could use card sorts.

This sounds complicated when described, but it’s pretty self-evident once you start doing it, and is a lot easier to work with than the traditional feedback approach if the client wants the product changed, but can’t explain how.

How do you know when you’ve got there?

When the results from your measurements show diminishing returns.

What we’ve found is that major changes usually emerge between the first and the second mockup. This is when the client is most likely to spot unexpected affordances, and where you’re most likely to catch key requirements that the client forgot or didn’t bother to mention.

After the second mockup, it’s usually a case of fine-tuning the design until everyone’s happy with it. This often happens by the third mockup.

At this point, you can proceed to do a more detailed project plan, with a clearer idea of what the final product will be, and with reasonable confidence that there won’t be any major changes in requirements from now on.