At the J. Boye 2010 Philadelphia conference, veteran user experience consultant Jim Hobart of Classic System Solutions gave a detailed workshop on rapid prototyping–a way to model systems and products before they’re built, saving time and trouble before expensive production starts.
What is a Rapid Prototype?
Simply put, rapid prototypes are models of a system or product that are, well, rapid. You can make them in a few different ways. Throw-away prototypes are intended to give high-level views of what something will include, how it will work, and maybe a little what it will look like. As the name implies, they’re meant to be thrown away and replaced with something a little better, so they may even be paper or whiteboard sketches that get increasingly detailed. Evolutionary prototypes may one day be a final product. They also change over time, but usually include actual working elements of the finished product that are refined and developed as you go. Many Agile prototypes are evolutionary from the beginning, for instance. So where does the rapid part come in? In both cases, speed is important. The prototype is created, tested and reviewed, and then changed, repeating quickly. This may happen as often as twice a week, and as seldom as every two weeks for large or complex projects. A good rule of thumb might be, just a little faster than feels comfortable. This tends to focus a team on making decisions and nailing down problems quickly, which makes actual production much easier.
The Rapid Prototyping Process
Ideally, the rapid prototyping process has the following steps:
-
Identify users. Who are the people who are going to use your product? What are they like, how do they work, and what will they be trying to accomplish? This can and should include actual user research, if possible.
Gather requirements. From a business standpoint, what will your system have to do? How does this relate to what you learned about your users?
Model the interface. Decide which of the two styles of prototype you’d like to make, and then make one. Usually it’s good to start with a presentation layer (an idea of the ‘look and feel’), a navigation model (a map of how the user will get around the application), and various screens she’ll see when she uses it. What tools do you use to do this? It’s up to you. Many famous designers begin with pencil and paper–sketching activates both sides of your brain, which is especially important at the beginning. You can then move to more sophisticated tools like Visio, Balsamiq, Omnigraffle, or Axure to make more detailed changes as you go along.
Prototype the system. Now model the system itself, just as you did for the interface. What is it going to do?
Test. Now test your work with actual users. See how they react to the model and think about the ways they get things done. You can do this in a fancy lab, but with a little effort you can also get good results using paper prototypes in which one person ‘plays the role of the computer.’ (Carolyn Snyder’s Paper Prototyping and Steve Krug’s Don’t Make Me Think are great for this.)
Repeat. Now, using what you learned, make changes to your prototype and repeat the process. Keep going a few rounds until things start to ‘feel right’ about what works and what doesn’t. Usually you’ll know when this happens. Just make sure you don’t quit too early.
So Why Prototype?
So why prototype in the first place? Isn’t it just easier to start building something? (This is usually what your developer will want to do.)
Save time and money. By prototyping, you uncover big problems fast–sometimes when they’re only marks on paper. You need an eraser to fix those, not two months, five engineers, and $300,000. This saves time and money, and sometimes a career. Just think…would you just go out and start building a car? Lots of useful systems are at least that complicated. Prototype first and reduce the hassle.
Get famous. ‘Buy-in’ isn’t always the right term…the right prototype can not only convince people you’re going in the right direction, it can win you their admiration and undying support. It’s always a good idea to make sure that what’s in the CEO’s head resembles what your team is building…and you might even be able to show her something better than she thought of in the first place. Besides, if she sees how the product is growing from step to step and approves each piece, she’s going to get personally invested in its success whether she knows that or not.
Build a killer team. Prototypes work best when a group of people is dedicated and focused on one thing: a great model of what will be a great product. The very process of prototyping can bring a team closer together…or reveal problem areas that should be fixed. Either way, a tightly-knit team makes things a lot better, and a lot more fun.
Make the right thing. By studying real users and what they want, you’re much, much more likely to build a product that will succeed. Even better, you’ll know that your assumptions about how people use the product will be pretty solid. For most interactive products, that is literally a million-dollar advantage.
Rapid prototyping is common at the biggest, savviest companies, but not necessarily as common elsewhere. But it’s worth a try, at the very least to get agendas and assumptions on the table. In a time of tight budgets and tighter schedules, it can be the difference between success and failure. What do you think? Any questions about how it works? Any stories about your use of prototyping? Or do you want some tips about your specific situation? Let us know below!
