How To Maximise Learning Through Rapid Prototyping

One of my latest projects I’ve led at DMI started off with some fuzzy requirements, no clear problem statement and ambiguous concept (which in reality was no concept at all). In addition to that, we were swimming in an overcrowded space with huge competitors. Prototyping played an essential role in our process of discovery and conceptualisation. Through rapid prototyping and rigorous user research, we were able to clearly articulate the problem we wanted to solve and also experiment the solution space by switching from a “let’s build it” to a “let’s test it” approach. Instead of requirements we started with assumptions. After 9 weeks we ended up with a clear problem statement, solid concept and an interactive prototype which helped the client raise a big investment. Here are some things I learnt along the way.

Why should you prototype?

1. Prototyping is a cheap and efficient way to deal with things that are hard to predict.

One of the most famous stories about prototyping is the one with Jeff Hawkins, who was a Palm co-founder and one of the inventors of the Palm Pilot. Before committing to develop the Pilot, he cut a block of wood that would fit into his pocket and “use” it for several weeks pretending it was a real computer. The story says that every time someone was asking him about his availability he would “check” his schedule on his block of wood. It might sound stupid, but this allowed him to understand better how the experience might be like and all the potential challenges that might arise.

2. Prototypes help externalise ideas

Prototypes can do a very good job to externalise ideas to stakeholders and facilitate user evaluation or usability tests.

“A lot of times, people don’t know what they want until you show it to them” — Steve Jobs

I was around London Eye a couple of months ago, asking people to test my prototypes. Loading InVision prototypes using 4G proved to take more time than expected, due to the terrible connection. In many cases I had to fill this loading time with some conversation explaining what this app is about. “Explaining” the app using just words had almost no effect on people (I could tell that by the body language) but after the prototype was loaded, the whole perspective of the user was changed. I often got reactions like “wow… this is pretty cool, actually!”. That’s when I realised the Steve Jobs quote is more valid than ever.

3. Prototypes replace documentation and deliverables

Most of us learned the hard way how complicated it is to work following the old deliverables/documentation based model. Iterating is a pain as you have to update wireframes and flowcharts, explain interactions by showing static presentations containing non-interactive wireframes, information architecture, content maps and mock-ups. A prototype eventually encapsulates all of that. The documentation is the prototype itself. IA is there, wireframe flow-charts are not needed since the flows are in the prototype.

4. Prototypes maximise the amount of learning and minimise the amount of time spent going into the wrong direction

By rapidly prototyping and testing you’ll discover early what is working and what isn’t, in order to minimise risk. You’ll be able to reduce as much as possible the risk of working on things that are not going to be successful. Try to get the prototypes quickly in front of the users. Kill them if you have to (the prototypes, not the users!). Iterate, then repeat.

How should you prototype?

1. Prototypes are questions. Ask many.

Many raw ideas are necessary for innovation and in order to externalise these ideas and show something tangible to stakeholders you’ll need to prototype a lot. Start with low fidelity prototypes that express the core concepts of the ideas you’re trying to communicate. Make one prototype for each and generate as many as you can.

“The best way to have a good idea is to have lots of ideas” — Linus Pauling (Nobel Prize Winner)

Designers often get fixated on one idea and this can lead to missing other good opportunities. Starting off with many ideas not only reduces the chance of missing good opportunities but also helps the designer avoid fixation. When you have only one idea you’re more likely to be attached to it than when you have many.

2. Build quickly

Your goal at this point should be to maximise the amount of learning and minimise the time spent going into the wrong direction. Prototypes shouldn’t be complete, they develop over time, so don’t spend time on visuals, beautiful mockups or trying to finish all the sections in the app. Push non-relevant sections (like settings) as late as possible in the project and spend the time on getting the concept right. You don’t even have to think too much about usability, you can worry about that later. Usability testing can tell you if an interface is usable but cannot tell you if it’s useful.

Right now your goal is to start a conversation and answer some questions, such as “Is this useful? Why/Why not?”, “Is this something desirable? Why/Why not?”, “How does it compare with the other alternatives?”. Answering these questions will make it easier to filter out the bad ideas or things that won’t work.

Prototypes are ways to start a conversation and not options for the user to choose from. I avoid showing multiple options to the same user for several reasons. I don’t want to limit the conversation to the options shown so the user feels like he needs to choose something. Second, a user can be under the impression that he likes one option just due to the fact that he saw that one first. When doing interviews, by laddering and asking a lot of “whys” you can uncover core problems. After you have answers to the questions above you’ll be able to throw to the trash the bad ideas and start another round of prototyping. You can combine prototypes, duplicate and create multi-variants which you can test again. Sketch, prototype, research, critique, test. Do this cyclically and you’ll increase your chances of building something solid, something that solves a real problem.

The essence of innovation is based on hypothesis and experimentation. Designing software is a continuous task and differs a lot from assembling a chair, for example. When we design software we often don’t know how the product it’s going to look like and we need to learn as we move forward. That’s where prototyping plays a crucial role. It’s a mechanism that helps you to move from ambiguity to certainty and to learn quickly what works and what doesn’t in order to reduce risk.