Design Technique 16: Rapid Prototyping
There are always going to be constraints upon any system you develop whether its a tool for uploading content or a marketing website. That ultimate constraint is the user. How is the user going to respond to and interact with the interface you put to them? Will the processes involved be logical – let’s face it we can’t just twist their arms. We’re in the business of enticing volunteerism on the part of our subjects and most often they owe us nothing. Rapid Prototyping is a good way of getting user input into the problem space early when its cheaper to fix. It involves performing a number of relatively fast iterations of a prototyping regime so we can make rapid changes and retest our assumptions. But how do we go about achieving that process?
Iterative High Fidelity Prototypes
The first step is to very early in the design process put together a reasonably high fidelity prototype. Whereas a low fidelity prototype would be paper based a high fidelity one would be created in software. It would have the ability for users to interact and possibly represent a vertical part of the system. Higher functionality means prototypes will be more likely to cover only a smaller part of the system (as opposed to horizontal prototypes which have lower fidelity and offer a broader brush approach with less detail and probably no interaction at all). What you are looking for in Rapid Prototyping is something, possibly in the middle of these extremes, which can be developed relatively fast but also provide the means for us to get direct feedback from user testing. Your Scenarios might come in handy at that stage.
How to Create Rapid Prototypes
What do you use to create Rapid Prototypes? They could be achieved by simply building them in clickable PDF documents or as general templates built with markup language. Often system prototypes are not developed with the programming language you are going to use and simply represent the system interface or other features which will be built for real later in the process. For example you may be developing an application in C++ but build your prototypes in Java or something you happen to be more proficient with, perhaps a software application purpose built to enhance the prototyping methodology. What you are looking for with Rapid Prototyping is relatively rapid feedback from users so you can achieve a series of positive design changes. The prototype could provide the interaction for navigation of the website and offer some ideas on search functionality. Its not at the visual design stage yet so those decisions are still on the backburner.
Improvement by Design
Because Rapid Prototypes can be easily changed they offer the ability to be altered and be retested. The iterative cycle of design, test and improve moves your product through a series of stages which enhance its value. The idea is relatively easy to grasp and can lead to some crucial discoveries particularly very early when it is least expensive to fix errors. Also it can lead to innovative thinking when you see something doesn’t work and have to ask yourself why. Perhaps no-one is even finding your shopping cart.
The Drawbacks – Money and Time
In the end the drawback of this method might be that in actuality Rapid Prototyping may take longer due to the expense and high cost involved in creating higher fidelity artefacts and user testing. But if you can afford it in the budget its not a bad idea to consider. Maybe its worth providing clients with a series of three relatively fast website prototypes of a critical area so they can just give you limited feedback.
Accept Some Ideas Are Bad
The main thing with any type of prototyping is to accept the possibility something you just made is crap. If users say it is crap you need to be prepared to bite the bullet and scrap ideas you personally want to go with. God knows I’ve sunk on a few battleships of bad taste and assumption, too.
Its important in this process to measure the outcomes of these testing cycles. Make some questionnaires, observe and measure times it took users to achieve tasks. These will give you the comparative data you can use later to assess features – 9 out of 10 people might be saying the proposed search feature is CRAP. Great stuff. How crap would it have been if you hadn’t fielded them questions during Rapid Prototyping and avoided that whole mistake? How expensive?
