Bill Buxton has worked at both EuroPARC and Xerox PARC, Silicon Graphics, Alias Wavefront and most recently Microsoft Research. He has been lecturing and writing on the human computer interaction for 30 years.

Buxton is passionate about technology products and equally passionate about the role of design in creating successful products which are a pleasure to use. He describes a role for design from the very earliest stages “sketching” new products and what interacting with them might be like. He describes how these sketches can be on paper, on glass, cut out of cardboard, in short videos, photomontages, post-its, games, pantomime, almost anything. He gives detailed examples of how these have been used to develop the user experience in numerous projects, many of which have developed into products.

A core message of the book is that the design process requires experimentation, with the expectation that experiments will fail and that the design team will learn a great deal from that failure. These experiments are often in the form of role playing, where members of the design team try to take on particular roles, trying to achieve particular aims within the limits of the current design experiment.

Buxton puts all of this within the wider context of the commercial success of a product. One of his case studies is Apple and in particular the iPod. Here he charts its history from earliest release in October 2001 through a tipping point in the second half of 2004. To make the commercial point he puts this against the iPod revenues and volume and Apple’s stock price. One key lesson from this case study is that the iPod was no overnight success, but took four generations before it had a dramatic commercial impact on Apple’s fortunes.

A recent article in the Harvard Business Review describes The Innovator’s DNA as being made up of Associating, Questioning, Observing, Experimenting and Networking. There is plenty of evidence here to suggest that Buxton has spent his life doing all of those things and more. Mixing a passion for technology, software engineering, human computer interaction (HCI), music, art, design, mountaineering, the outdoors and more.

For those involved in the design and development of software products, this book has a lot to offer. It offers us ways to experiment with the user experience, refining our approach with each iteration. It gives us ways to perform these experiments and to evaluate them, whether we are drawing user interfaces on paper, or laying them out in a GUI design tool. It also offers many, many examples to help us find new ways of thinking about our products.

Finally, and perhaps most importantly, it offers a strong argument as to why design should be at the heart of product development, from initial concept through to shipping and beyond. I’d recommend it as a resource to anyone involved in technology product design.

Buxton. Bill (2007). Sketching User Experiences: Getting the Design Right and the Right Design. San Francisco: Morgan Kaufmann

Find it on Amazon.com
Find it on Amazon.co.uk

So the lowest of the low-fidelity prototypes are very quick hand sketches while the highest are fully detailed, pixel perfect renditions.

The obvious advantages of low-fidelity prototypes are the speed at which they can be put together and therefore the low cost involved. After all, anyone can quickly scribble designs on a piece of paper.

But one of the things we hear discussed a lot is that prototypes, especially early ones, really have to be low-fidelity. They need to impress upon people that they are obviously mock-ups and not the real thing. Otherwise, if you use high-fidelity prototypes, you may encounter these negative consequences:

1. When trying to elicit feedback on a design, you find that people pick up on irrelevant details like the colours or the choice of image instead of the content and workflow.
    
2. They may be so WOW’d by the beauty of your design that they’re unable to provide constructive critisism or they may be reluctant to do so for fear of undoing all your hard work.
    
3. Stakeholders may think that the “product” looks so finished that they complain bitterly when they can’t see much “progress” after 6 months of development and implementation.

Of course there are many truths to this argument but, for the most part, it depends upon the target audience and their level of understanding of what the prototypes represent.

Project managers, analysts and developers will have no trouble at all in understanding the scope of a user interface prototype and, in may cases, a high-fidelity prototype will help to pinpoint areas of ‘over ambitious’ design that might take many months to implement when a simpler alternative will work just as well.

For everyone else, a straight-forward explanation of the scope of the prototype is usually enough. If the stakeholders really don’t get it then you may be in trouble further down the line!

The irony of point 3 is that although a low-fidelity prototype might be better in lowering expectations that the product will be “finished in no time at all”, higher managers and stakeholders don’t always respond well to them. They’re not impressed by the rough appearance and prefer to see nicely polished, fancy displays – something they can envisage as being a final product they or their customers can use.

With specialised tools like GUI Design Studio now available, high-fidelity prototypes are becoming much easier, faster and cheaper to produce and the once held advantages of low-fidelity prototypes are becoming insignificant.

As far as we know, our customers are all enjoying the ability to create high-fidelity prototypes and designs but we understand the need to use low-fidelity presentations on occassion.

That is why GUI Design Studio provides “Outline” display modes and the ability to easily change the overall font of a design to give it a more hand-drawn, rough and ready feel. And to be able to switch back to normal again.

Here’s our trusty dialog design example in all its XP glory:

And here it is again looking like a quickly drawn mockup after a couple of setting changes:

You can see a quick tutorial video (about 1 minute) of how this transformation took place here.

Of course, if you really want to, you can also work with paper sketches by scanning them in and incorporating them as images. Place navigation boxes over the buttons and other areas then link them together just like any other design element.

The most important thing with prototypes is to define exactly what their purpose is, then to create them with just the right amount of effort and functionality to convey enough information to obtain agreement on what needs to be implemented and what doesn’t.

So what are your experiences with low or high-fidelity prototypes? Do you agree or disagree with what’s been said here? Maybe you can’t see the point of creating prototypes at all?

Leave a comment and let us know your opinions!