Concorde’s engineers made crude prototypes out of paper and tested them outside their workshops during their lunch hours, reports the Guardian’s Jonathan Glancey. Thanks to Andrew Harder for the pointer.
As we design interactive user experiences today, this tried and trusted design technique still applies: make prototypes to help you explore and fine tune design ideas.
Concept sketches – have lots of ideas
As Linus Pauling said, to have a good idea, you need to have lots of ideas. Successful interaction designers avoid just going with the first idea they have – they produce lots of different ideas and let the ideas grow and build before starting to trim them down.
But mocking all those ideas up in slick detail, or expensive code, would slow you down. So it’s best to keep initial concepts cheap and disposable.
Testing the concept
To test a paper aeroplane, you throw it across the air field. To test an interaction design concept you put it in front of target users. After all it can’t interact by itself – you need people for your concept to interact *with*.
Testing several sketch concepts with target users sounds like it might be difficult, pointless or embarrassing. But it’s not. People feel able to give more truthful feedback when they know you haven’t slaved too hard on each concept And there’s solid scientific evidence that asking users to try out and compare several low-fidelity prototypes will get you more useful and trustworthy feedback than any other approach.
(Messing about with sketches is also a genuinely fun way for a respondent to spend an hour.)
Prototypes – perfecting the details
Once you’ve selected a winning concept, you need to start working through the interaction in increasing detail. It’s a different stage in the project and requires a different style of thinking. Bill Buxton’s diagram below shows the key differences.
Imagining an interaction without documenting and testing it is like trying to do long division in your head – painful and easy to lose track. There’s a growing range of powerful tools that can help us mock up, step through and tune interactions in detail – Axure RP Pro, Simunication, iRise, Caretta Gui Design studio for example. (There’s also PowerPoint – Microsoft used it to design Office 2007.)
But there’s a pitfall to watch out for: the constraints of the tool can constrain your thinking. “I want to make a panel pop up here, but I don’t think I can do that using the prototyping tool.” If you catch yourself saying that, you know your prototyping tool is a problem.
Agile – the product is the prototype
But when you’re building really complex interaction (typically a web or desktop application) it becomes almost impossible to mock up the interaction without too much work.
This is where an agile approach is really helpful. Agile methodologies encourage developers to produce working software in short “iterations” that build incrementally towards the finished product. Stakeholders and users can play with each iteration and feed back on it. There’s little or no formal specification at the start of the process, and agile programmers fully expect to have to make some changes of direction along the way.
I’ve found that working on these projects can be tiring and scary – there’s very little time to sit down and think things through before someone has started coding it. But once you get past that, it becomes liberating. Agile projects reject the fiction of the waterfall approach – that someone can deliver a perfect interaction specification up front, without ever really seeing the product working.
Whichever way you go about it, designing and engineering a good interactive experience needs concepts and prototypes. They may look rough and ready to start with. But don’t let that discourage you.
Remember Concorde. The finished product was expensive, ground-breaking and glamorous. Those very first paper planes were not.