My Favorite Prototyping Techniques
A wide spectrum of activities can be called prototyping. Not all of them involve writing functional code. In fact, none of my favorite prototyping techniques require writing any significant code at all. This makes the prototypes easy to create and change, easy to throw away, easy to focus on specific design problems, and cost-effective. They are also 100 percent vaporware-proof.
Here they are, in my order of preference.
Prototyping by Example
What I call prototyping by example (or by pattern, if you prefer) involves designing a user interface by modeling program features after characteristics of existing programs. This technique is also called competitive analysis. The characteristics of the existing programs allow you to evaluate and test their appearance, behavior, and overall usability in an efficient, cost-effective manner because the working code already exists. Furthermore, testing an existing, fully functional program is more realistic and enlightening than testing a partially functional prototype.
Of course, it is important that any models you choose are appropriate for your program. A user interface from a game is likely to be a poor model for a business application. And an interface from a utility designed for beginners will most likely be a poor model for an application intended for advanced users. In Chapter 7, I point out that Windows Explorer is likely to be a bad design model for utilities since its usage pattern is different from most other utilities.
Suppose you want to design a user interface for an audio CD player utility. There are dozens of such utilities in existence. Instead of designing everything from scratch, you could review as many of these programs as you can and analyze what you like and don't like about them. You might decide you like the convenience of one program, the look of another, and the functionality of another still.
While competitive programs often have the most similar interface ideas to what you need, you can employ user interface ideas from practically any program, even programs from other platforms. Look at other successful programs for guidance. You might choose to model a program's preview functionality after features found in Microsoft Word. You might want to consider using some of the direct manipulation techniques found in Microsoft Outlook. You can even cobble together bits and pieces of existing user interfaces to create a totally new concept.
An example of a user interface model that has been reused in many user interfaces is the classic Macintosh Font/DA Mover utility interface:
Does this look familiar? This is a user interface design pattern that has launched a thousand clones. It allows users to select which fonts and desk accessories they want to use from a list of available choices. Today countless user interfaces are patterned after this utility, such as the Customize Toolbar dialog box (shown below) that is built into Windows.
This prototyping technique allows you to design a user interface based on existing user interfaces that are known to be effective. You don't have to write any code to visualize them, to communicate them, to get feedback about them, or to determine their usability. You just have to say something like "Let's pattern the script editor after the Font/DA Mover, but let's also support drag and drop editing." If everyone agrees, your work is done and you can move on to the next design problem. (Of course, you might also have to give a demo if nobody knows what the Font/DA Mover is.)
This is not a suggestion to steal anyone's copyrighted software. Rather, the goal is to collect, evaluate, analyze, and compare ideas and gather inspiration from the user interface elements of existing programs. The user interface you create should be a result of your own interpretation of these patterns, with your own innovations and improvements. There are plenty of good user interface design models out there. Why reinvent the wheel?
TIP
Use prototyping by example to design new user interfaces by modeling them after appropriate user interface elements of existing programs.
Paper Prototypes
If you need to create a new design, usually the best way to do it is on paper. After all, paper and pencil are the most powerful, efficient design tools available. Paper prototypes are easy to create, easy to modify, and easy to throw away. Paper prototypes are effective in designing window layouts, menus, dialog boxes, and other user interface elements, as well as the navigation between windows. Anyone can create a paper prototype since it doesn't require any special skills. Best of all, paper prototypes force you to focus on high-level design. When using another design tool, you are often focused on using the features of the tool—for example, getting the control sizes exactly right and making sure the buttons are aligned. Design details like precise control sizes and alignment clearly aren't relevant to a paper prototype and receive no unwanted attention.
TIP
Paper and pencil are the most powerful, efficient design tools available. Use paper prototypes to create new designs.
Interestingly, software development is the only engineering field where sketching out design ideas on paper is referred to as prototyping. In all other fields, this activity is just a normal part of design. For example, in architecture, a blueprint design is not considered a prototype. The distinction between a paper design and a paper prototype is that a paper prototype is intended for user testing whereas a regular paper design is not. In fact, paper prototypes intended for user testing try to simulate a working program by having each screen (that is, window, dialog box, menus, combo box, and so on) on a separate piece of paper so that a user can actually perform tasks with the prototype. You have to act as the computer to display the appropriate screen based on user actions.
It is harder to misinterpret a paper prototype than a functional prototype. Nobody expects the controls to line up perfectly or even the text to be spelled correctly. Fonts and colors aren't issues. Nobody can be confused in determining what is intentional and what is arbitrary. Only the core ideas in a paper prototype are intentional—all the concrete details are arbitrary. In fact, the sloppiness of a typical paper prototype is one of its strengths, since it forces you to judge it by its design merits and not by its visual appearance. On the other hand, a poor design created with a good design tool might have an excellent visual appearance, making its usability flaws harder to see.
As I discussed earlier, people are reluctant to change a functional prototype. Just the opposite is true with paper. Even if you come up with something on paper that appears to be a very good design, few people will resist putting it aside, at least momentarily, and looking for alternative designs. After all, you are just dealing with paper. You can try a more spacious layout and then try a more compact one. You can completely rearrange the flow of the window. You can try to eliminate controls that might be unnecessary. You can even try to find ways to eliminate the window altogether. Best of all, you can do all of this in a matter of minutes. Paper prototyping allows you to do whatever you want without fooling around.
The ability to easily change paper prototypes makes user testing more effective as well. You can incorporate user suggestions and make other changes on the spot. Users are more willing to make suggestions because they understand that paper designs, unlike functional prototypes, are preliminary and easy to change. Their feedback is likely to be more honest and direct. And they are more willing to say that they don't like the user interface at all if it is on paper, which is something they might feel reluctant to say about working code.
Scenarios
Another effective technique is to prototype tasks using scenarios. The idea is to describe a specific task and walk through how the user is to perform that task. Depending upon the situation, either you do the walk-through (for a design meeting or a customer presentation) or the user can do the walk-through (for user testing). In either case, the person doing the walking needs to verbalize his thoughts (which is called thinking out loud) so that everyone knows what is going on. You can use whatever means you have at your disposal for walking through the task, including paper prototypes, resource prototypes (as discussed below), functional prototypes, or even whiteboard drawings. The specific media don't matter as long as the prototype is easy to create, change, view, and save. The objective is simply to walk through the important program tasks and make sure that the proposed user interface supports them in an acceptable manner. Such task analysis does not require functional code.
TIP
Use scenarios to prototype specific tasks.
Resource Prototypes
I also really like to create what I call resource prototypes. Using only program resources, you can design windows, menus, toolbars, bitmaps, icons, and dialog boxes. If you want, you can also use a small amount of code to glue everything together to show how the user navigates from window to window. The ability to go back and forth between windows is the prototype's only functionality.
Using resource prototypes has many advantages. They are easy to create and change, since the resource-editing tools in Microsoft Visual C++ and Microsoft Visual Basic are quite productive. They are easy to throw away because nothing of value needs to be thrown away. You can keep the resources, since an acceptable resource is an acceptable resource. Any glue code you create is so simple that it isn't worth keeping. Since you aren't creating a functional prototype, all the focus is on design. And lastly, since the results are nonfunctional, there is no danger of vaporware exposure.
Every screen shot in this book of a dialog box that isn't from an existing program is a resource prototype with absolutely no code behind it. Not one line of code. All the dialog box screen shots were captured while in Test mode in the Visual C++ resource editor. I did have to program the menu screen shots, but only because there isn't a test mode for menus in the Visual C++ resource editor. Although I didn't create any property sheet screen shots, I would have had to write some code for them as well.
TIP
Use resource prototypes to create nonfunctional prototype programs without writing any code.
Are there disadvantages to using resource prototypes? A couple. They are clearly inappropriate if you want to test actual functionality, since they don't have any. To evaluate a resource prototype with users, you pretty much have to talk users through the program, since they can't do anything with the prototype on their own. Because of this, I find that resource prototypes work especially well with scenarios. Lastly, there is a risk of misusing resource prototypes. If you find yourself focusing on minor details such as control sizes and locations and not on more critical design issues like usability, you should probably use paper prototypes instead.
These four prototyping techniques allow you to accomplish the goals of prototyping in a way that steers clear of the hazards of prototyping. They are all nonfunctional and do not require you to write any code, and they are effective in achieving the goals of prototyping in that they are easy to create and change, easy to throw away, focused on specific design problems, and cost-effective. I find them so natural that I don't really consider them to be prototyping at all. I consider them to be part of the normal design process.
Make sure you have the right prototyping goals and are using the right prototyping technique. Time spent building the wrong prototype is still time wasted.
TIP
Prefer nonfunctional prototypes. Avoid writing prototype code.
