Category Archives: Prototyping

Prototypes don’t need to be “finished”

Catching up on some old copies of the Harvard Business Review I was struck by this quote about prototyping in an article by IDEO’s Tim Brown, Design Thinking.

“Prototypes should command only as much time, effort, and investment as are needed to generate useful feedback and evolve an idea. The more “finished” a prototype seems, the less likely its creator will be to pay attention to and profit from feedback. The goal of prototyping isn’t to finish. It is to learn about the strengths and weaknesses of the idea and to identify new directions that further prototypes might take.”

I couldn’t agree with Tim more. As a user experience practitioner, prototyping is just about the most important technique I have up my sleeve. I am amazed when I hear people come up with excuses not to prototype:

  • It will take too much time
  • I need more time to finish the prototype
  • We can’t learn anything from anything that isn’t finished or more representative of the actual product.

What rubbish. All of these are excuses of people stuck in their old ways of doing things. The truth is that you can obtain valuable insights from very low-fidelity prototypes, and also that even when dealing with higher-fidelity prototypes you can get away with a lot of smoke and mirrors to minimise the amount of effort that goes into the creation of something that appears finished.

Tim’s point about “finished” prototypes being of less value is particularly insightful. The amount of time we invest in creating a prototype should be directly proportional to the amount of confidence we have in what we are designing. The less clarity we have about the direction the design will take, the less time we should invest in prototyping.

If we invest too much time in a prototype too early in the process we run the risk of investing too much in its success that we won’t be prepared to listen to, or have time to respond to, the constructive feedback we receive.

This is particularly troublesome if you are working on a project with fixed timescales. The more time invested in “finishing” each design, the less time there is to explore alternate designs, and the less time there is to respond to any insights obtained from user research.

When prototyping we should resist the temptation to cement our thinking around one particular design paradigm for as long as possible. Short prototyping sprints (to use the Agile vernacular) are far more preferable to the prototyping marathon many engage in. By remaining open to radically different concepts deep into the design activity, we remain nimble enough to realign our thinking as insights are revealed from user research.


The secret to Xero’s success

Interesting to read Xero, who Jakob Neilsen decorated as having one of the 10 best application user interfaces, talking about one of the secrets to their success on their blog, One secret to our success. To quote:

In our methodology, the prototype is the specification. It speaks for itself. Our developers use the prototype as their blueprint throughout the development process, all the way through to final QA testing.

It’s important to clarify what I mean by prototypes. We don’t create working prototypes. We create design prototypes called screenflows: click-by-click simulations of the user experience, showing every interaction necessary to complete a given task. A screenflow is based on a scenario of a person completing a common task. We simulate all the screens, all the clicks and all the data entry necessary to start and complete the task. The result is a slideshow that simulates somebody using the software.

Screenflows are an ideal blueprint for developers. They make it obvious what needs to happen, when, where, how and why.

If you haven’t tried out Xero’s accounting application, you can sign up for a free trial and have a look for yourself. Certainly a very impressive experience, even more so for anyone who has ever used MYOB or one of countless other pieces of hard to use accounting software.