Published: Mar 01, 2000
Wed like to respond to some of the questions weve heard recently at our courses on prototyping, and provide tips on how to make this technique work well for you.
Prototyping is a quick way to incorporate direct feedback from real users into a design. Paper-based prototyping bypasses the time and effort required to create a working, coded user interface. Instead, it relies on very simple tools like paper, scissors, and stickies. Even in applications where new technologies are deployed, paper provides maximum speed and flexibility.
Equally important is that everyone on the development team can stay closely involved and productive in the process of creating a paper-based design. Because everyone on the team is a witness to direct user feedback, designers, developers, and writers can confidently implement a solid design that really works for its intended audience.
Certainly, you can use HTML (or Visual Basic, SuperCard, or other rapid development tools) to create mockups, but you may want to consider whether you have enough people who are proficient with the tool youve selected. Another issue to consider is how well your design team can stay involved in the prototyping process.
The reality is that its very difficult to keep the entire team involved in the process if each person is creating her own HTML pages at her desk. Weve seen that most usability problems stem from someone with key information not being involved in the design process. With paper, everyone can gather around one table with their eyes on the same design and each team member can contribute as the design unfolds.
Another advantage of using paper over HTML is that changes can be made on the fly during a test. If a design doesnt work the first time out, designers can scrap it and quickly try another with the same user. For example, if a user is stuck and needs additional information, a Hints button can be added on the fly.
Finally, users feel more comfortable being critical of a paper prototype because it doesnt have a polished look. When something doesnt work well in a crisp looking prototype, users are more likely to blame themselves or their lack of experience. The goal in prototyping is to measure the function and flow of the interface, not the look. HTML and other tools will create a polished look but wont change how quickly and easily a user can accomplish a task.
After youve done several iterations of testing and design on paper, putting together a web site will not take long. You will have saved time by making the big conceptual changes early on in the design process.
The goal in testing a prototype is to create a usable site. The inability to prototype a fancy effect on paper may be a warning that the effect is not usable. Our data with rollovers indicates that users cant distinguish a rollover from a static graphic. (A rollover is a graphic that changes, reveals text, or otherwise affects the screen when the mouse pointer is placed on it.) Users often choose a link to click on before seeing the associated content in a rollover.
Sometimes designers will use a new technology not necessarily to create a more usable site but because it looks cool. As long as the coolness of the site doesnt interfere with its usability, go for it. The goal of the paper mockup is not to test how cool looking a site isits to assess if users can get stuff done.
Paper mockups dont need to incorporate all the frills of technologythey only need to capture the sites functionality and convey the right information. For example, rollovers only need appear when a user goes looking for them. When users are clearly looking for a rollover, we provide any that exist by using a paper sticky.
With prototyping, the key is to create an interface quickly. To test out a completely new design creating a paper prototype is the fastest way to go. If we want to test out an existing product with no changes, then we just test the product.
When changing only parts of an existing interface, we start by printing out existing screen shots. We then make any small changes on those screens using sticky paper, whiteout and other handy prototyping supplies. If there are significant changes for one screen we sketch the entire screen on paper. Its fine to mix screen shots with hand-drawn interfaces.
However, when making a small change we do so with care. If that small change is handwritten on an otherwise clean screen shot it may artificially draw users to that part of the screen. For example, do users see an added button because of the button itselfwhat it says, where it is locatedor because it looks distinct and separate from the rest of the design? One idea weve played with is to create dummy changes on other parts of the screen. That way a single design change doesnt stand out so much.
When users are doing tasks with data, you want the data to be as real as possible, but its often impractical to have lots of data available. Using data that isnt real can work, but it makes the test less realistic for users and can make their tasks unrealistically difficult. All else being equal, using real data will make test results more reliable.
In cases where users must look up data that is not provided in a prototype, we create tasks in such a way that we can predict the data. For example, when we tested inventory tracking software, we designed tasks that had the user track specific items in inventory and we had the data ready for each item involved in the tasks.
When a user enters real data into a field and the data needs to appear somewhere else later, we rely on sticky paper; this saves lots of time. Each field has a piece of the sticky paper, and when the user enters data we can easily transpose that data to another sheet. For example, in testing online ordering for a web site, address information entered on one page is easily moved to the order confirmation page by moving the sticky paper on which the data is written.
On Internet sites we see users try to click elements that arent links and miss links theyre looking for because they dont look like links. When we see this in paper prototyping, we create the incredibly intelligent mousea fancy way to say we let the user decide whats a link simply by following their behavior.
When users click something that isnt a link, the incredibly intelligent mouse works and makes the non-link a link, bringing up the page the computer thinks the user wants. If we see users click something time and again that isnt a link, its clear whats neededmake it a link.
Sometimes a design will include icons and other detailed graphical links that cant be easily duplicated with paper. In this case, we write that graphical link out in text. Do whats quickest. If its important to have a picture with the link (or as the link), we may provide a basic sketch, or copy the graphic from some existing product and print it out on paper. •
Read related articles: