- Benefits of Prototyping
- Styles of Prototypes
- Prototyping Tools
- Whats Next?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Styles of Prototypes
There are quite a few ways to create a prototype, and each style has its own pros and cons. Following is a breakdown and description of some popular prototyping styles.
Paper Prototypes
A paper prototype is pretty much exactly what it sounds like: It’s a prototype created entirely on paper. According a recent survey I conducted among members of the Interaction Design Association (IxDA), 82% of IxDA members use paper prototypes when in the early stages of design.
They’re actually quite fun to produce. Paper prototypes don’t require any technical skill beyond the ability to draw an interface and use scissors to cut it up. Paper prototypes can be as simple as a drawing on a single sheet of paper, used to find out what someone would click to perform a task in an interface, or as complex as a large set of individual paper widgets used to run usability tests on key interactions within a planned application. They can be used to simulate web applications, mobile device interfaces, kiosks, and even ATMs.
The act of creating a paper prototype is a return to the days of finger painting and paper airplanes back in grade school. And believe me, your third grade teacher would be quite proud to see how far you’ve gone with such basic skills. A quick run to an art supply store should get you everything you need: large pieces of paper (11"x17" or larger), sketch pads, multicolored markers (including black), reusable tape, and anything else you might need to produce the paper equivalent of an interface, complete with menus, form widgets, and buttons. Once you have all that material in hand, a nice big conference room table becomes the best work surface in the world. Spread out all those tools and start drawing pieces of the interface.
It doesn’t matter one bit if you can’t draw a straight line to save your life. In fact, it’s better that way. The more people realize you’ve put very little work into the interface, the better. When people see an interface in its infancy, in raw, hand-drawn form, they have no reason at all to bite their tongues and refrain from telling you exactly what they think. Mockups, on the other hand, can have the drawback of making people think that the interface is nearing completion or already complete, and they may refrain from making a suggestion that could be really helpful.
HTML
HTML is a great tool for prototyping web pages, primarily because it’s a great tool for building web pages. Pretty obvious connection, eh?
Provided that you’re pretty handy with a WYSIWYG editor (Dreamweaver, for example), you can whip up a finished page in very little time and have a shining example of how the final interface might look. At first, though, it’s better to spend less time and refine your design as you go along. Just get the elements on the page—don’t worry about layout, color, typefaces, or anything like that. Just throw something together as quickly as you can. From there, whip up the most basic JavaScript and CSS possible to get the interactions working and looking somewhat organized. As you’re doing this, you’ll immediately start seeing issues with the design that need to be remedied, and you’re in a perfect position to do something about it. Fix it right then and there.
When you have a basic functioning page, decide whether it’s enough to run a usability test, at least using someone in your office. If not, refine it a bit more.
The major advantage of using HTML to create prototypes is that you’ve already got a nice head start on the interface for the final page. All the elements you need are already in a web page. As long as your code is usable (as in, it’s actually good code), keep it. Start morphing the page, piece by piece, into its final appearance. Don’t worry about whether the back end has been built or the database is up and running. None of that matters at this point. Just get the page into the shape it needs to be in. It can be tied into the back end later on. For now, you’ve got an actual page in front of you, and that’s a good thing. You can run usability tests using the page, and you can use the page yourself. You can take great notes about all the problems with the page by simply using it. When you come across those problems, tweak the page some more. Then hand it off to the developers.
With this technique, the developers will have a designed web page in front of them at all times. They’ll know what needs to be done to make it work; they can’t sneak in their pet features without consulting you first; and as the back end code gets closer and closer to its final working state, the page itself will look more and more like its final version as well. At some point, all the loose ends will be tied up and you’ll have a page that has already been in use for quite awhile, so you know it works. You’ve used it yourself many times. And it’s very hard to trap yourself into theoretical, academic conversations about whether solution A is more usable than solution B when you’ve used the page yourself on countless occasions. You’ll have already seen and addressed all the problems with the page.
Flash
Adobe Flash is a fantastic tool for prototyping, as long as you know your way around ActionScript and can whip up interfaces fairly quickly using the UI components that ship with the authoring tool. Personally, I use it to demonstrate interactions that simply demand a visual, interactive demo, and cannot be covered by writing use cases and drawing wireframes.
It’s not at all necessary to create the entire interface for an application. You really only need to create the individual interaction. But if you find that you need to do this several times to illustrate several pieces of an application, it’s sometimes beneficial to just go for it and create a complete prototype with Flash. This prototype is not as reusable as HTML prototypes (unless the final application will be built in Flash), but it does offer some of the same benefits. It shows the developers what to build, shows the marketers what they’ll be marketing, and so on. In this approach, a Flash prototype is really the same as a functional specification, but can be easier to create (as opposed to writing long sets of use cases and 50-page specs), and will do a great job of simulating the final application’s behavior.
Click-Through Mockups
A click-through mockup is composed of a series of comps that illustrate various application states or screens, each of which has triggers (such as a button) to transport the user to the next screen. If you’re working on the purchase path for an eCommerce site, for example, you might use the home page as the first screen and use a button in the screen to send the user to the next step in the process.
Prototypes like this are great for illustrating a single course of action, but aren’t always very efficient to create when trying to simulate multiple interactions within a single interface. In other words, it might be nice to use a click-through mockup to show the progression from one step in a paginated form to the next, but you probably wouldn’t want to use it to demonstrate a page with multiple possible actions, each of which leads to different screens. Stick to showing off a single interaction rather than expecting to be able to create something as dynamic as what you might be able to show with a more robust prototype.
There are a number of ways to create click-through mockups, some of which have already been covered in this article. You can use frames in a Flash timeline, for example, to lay out a sequence of application states, and simply put buttons on the stage that send users to the next frame. If all the screens have been created, this is quick work—no more difficult than creating a simple presentation with Flash.
If you’re more comfortable with HTML than Flash, use HTML instead. HTML versions of each screen can simply contain links that send users to the next page. The key is to keep it simple. If you’re designing an AJAX-style application that will be making use of DHTML to render several application states within a single page, using click-through mockups is not the way to go. What you can do, however, is create a separate HTML page to represent each state, and have the links simply walk through the states in a sequence.
If you won’t have a laptop handy when you need to present these mockups, you can even apply some paper prototyping skill here. Just print a copy of each application state or page, and have users "click" (with their fingers) through the sheets of paper.