Shortening the build-measure-learn cycle with clickable mockups

I’ve been working with a startup for the past three weeks. We just finished a round of product design work, so we knew what features we wanted to build. Most of the time, teams in this situation jump to mockups and start coding features right away. Once the features are launched, you can start to measure and learn if they work.

It’s a good process, but we wanted to go even faster. We needed to tighten that loop. So this time we created a clickable mockup prototype, showed it to eight users, and in just one week we had learned what parts of our design were working, what parts were broken, and how to fix them.

I use this method all the time and find that it speeds up product development tremendously. Here are the steps I go through to create effective clickable mockups and race through the build-measure-learn cycle:

1. Set a deadline

Teams make design decisions slowly when they’re aiming for perfection and consensus. Break the habit by setting a hard deadline: Schedule a date to show users the finished clickable mockups. Yep, start recruiting users even before the design is finished! When you know that users are going to show up on Friday to see the new designs, there’s no time for big debates — you make decisions fast.

Everyone wants the best design possible, and teams can debate over the right way to build something for weeks. But the reality is that you probably don’t have the data you need to actually make the right decision. So it’s much better to just decide on something quickly, and then test to find out which parts of your design were right. That’s the beauty of prototypes: the risk is so low that you don’t need to be perfect. As long as you’re learning fast, you’ll converge on a good solution.

2. Design a flow (1–2 days)

Create sketches for all the screens and states that you want to show to users. Since you’ll show what happens at each click, this can get pretty big: between 20–40 sketches for larger projects. Start at the end — think about what you want to learn and craft a scenario that enables you to demonstrate each part of the design to users.

When designing these flows, I find it extremely helpful to focus on the transitions: What happens before each step? Why would someone click there? Is the feedback clear after the click? It’s also helpful to write the UI copy: How does the product communicate what is happening at each step?

It can be painful to move fast and cast aside so many ideas that seem promising. So as we’re working, I like to have an area on a whiteboard called “forks in the road” where we can save ideas we chose not to follow. And if we’re deadlocked between two significantly different and reasonable options, we’ll sometimes decide to create two different clickable mockup flows and show them both to users.

3. Mock up each step in high fidelity (1–2 days)

It’s time to move to the computer. In order to create the illusion of a working product, you’ll need to create image files for each of 20–40 screens. Any image editor will work, but my favorite tool for this work is Adobe Fireworks. I use it because it supports multiple pages, shared symbols, and has sophisticated visual tools. These features make it possible to design large flows in high-fidelity while still remaining flexible.

It also helps to start with a rough draft — get through drawing all the screens first, and then go back and add polish. This works well because one person can start wiring up the prototype once all the screens are ready, and another person can keep improving the designs. If you’re running behind schedule, it’s far better to show users a fully finished flow that’s rough, than a partially finished flow that’s polished.

4. Wire up a prototype (<1 day)

This step is easy. All you really need are hotspots on each image that lead to the next image. If you want to make the screens more interactive, you can layer on form elements like checkboxes and text input fields. To navigate around longer flows, it can be helpful to build a table of contents (either in text or a flow chart) that links to each of the screens.

There are a bunch of tools you can use to build clickable mockups: InVision is inexpensive and is a good fit for most small projects. There are more sophisticated tools like Justinmind, ProtoShare, and Axure. Or you can even use Apple Keynote in a pinch (here’s a quick video how).

Even with all these tools, I still sometimes code up these prototypes by hand with a bit of JavaScript. I like this because I can always add more capability to the prototype if needed, and I can easily bulk-import an updated set of screens if something changes with the underlying designs. If you choose this route, just make sure not to break the browser back button. (I did that once and it was a disaster!)

5. Show it to people (2 days)

Yep, it’s time for a user study. And like any other user study, you’ll need to recruit the right people to talk with, craft an interview guide, have each person think aloud as they use the prototype, and then make sense of the data. There are many ways to make mistakes along the way and get misleading data from a user study. So if you’ve never done something like this before, consider hiring an expert to run the study and show you how they do each step.

I can’t cover everything about how to run a user study (and I’m no expert either). But here are a few tips I’ve found helpful for these types of studies:

• Explain to the person that they’ll be using a prototype, and that they might click on some things that don’t work because they’re not wired up yet. It’s always amazing to me how much people believe these prototypes are real, when they’re really just a string of clickable mockups.
• Start wide by asking about the person’s needs in your product area. This helps develop rapport and validate that you’re on the right track with the design. You can usually transition from their needs to a plausible scenario about how they’d use the prototype.
• When designing new features, it’s tempting to ask, “How likely would you be to use this?”. But phrasing the question like that is somewhat leading, and you might not learn a lot from the answer. Instead, ask “How does this compare to X… or to the way you’ve done it before?”. Or ask, “In what circumstances would you use this? Why?”
• Sometimes people just don’t find the thing you’ve designed to be useful. They wouldn’t use it. That’s OK — you’ve learned something! If you still want them to get through the prototype to see if it’s usable, just let them know you’ve heard their objections. Say, “I understand you wouldn’t use this normally. But let’s give it a try anyway.”
• At the end of these sessions I like asking, “How would you describe this to a friend?” It reveals how well the person understood your design. I also like asking, “If you had three wishes, what would you change?” When people request major changes, it’s a sign that we need to go back to the drawing board.

Watching people use the prototype will generate a ton of data about your design. Just get the team together to watch the sessions, agree on the top issues, and decide what you want to change in the next iteration. I’m always impressed at how dramatically priorities shift when all this data is available. And that’s a great indicator that we’re moving through the build-measure-learn cycle efficiently.

Why this works: It’s a short-circuit

The common way to get through the build-measure-learn cycle is to have an idea, build it, ship it, and then watch usage metrics. But if the metrics don’t pan out (or if you want to improve them), you still need to understand why it’s not working. And to do that, you need to watch people use your product.

Clickable mockups help by short-circuiting the process. They allow us to start with an idea and then jump to the end and see why it works or doesn’t work. That’s possible because clickable mockups seem almost-real in user studies, so we can get great data with a fraction of the work.

This short-circuiting creates a huge speed boost, and that speed leads to other unexpected benefits. It’s easy to get excited about a product idea, and then later discover no one would actually use it. I’ve had a few of these, and it sucks. When you’ve only spent a few days developing the idea, it’s so much easier to hear that you’re wrong, throw out the work, and start over. And because this whole process fits within a week, it’s easier to try bolder ideas. When those bold ideas work, you’ll have data, and that gives you confidence to execute larger product changes.

Time to ship

You can learn a lot by listening to people use your product. But there are just as many things that you can only learn by launching, watching the metrics, and seeing what people actually do (versus what they say they’d do). This method of clickable mockups is good for one or two iterations, but you can’t short-circuit forever — you still need to ship and test the design in the real world.

Still skeptical?

That’s OK, I was too. When I first started designing, it seemed like a waste of time to build a prototype instead of just building the real thing. And it seemed useless to spend time talking to users when I just knew the design was going to be great.

Thankfully I was forced through this process a few times and found it to be both incredibly helpful and truly humbling. I now realize that in any design project you’ll make some good decisions, and some bad ones, but you won’t know which is which until you talk to actual customers. And that’s why the best designers demand to work with talented user researchers — because they know what they don’t know.

I’m curious about what experience you’ve had with quick prototyping and user research? What other ways have you found to speed up the build-measure-learn cycle?