Database Reference
In-Depth Information
needed to offer the users a refill of their coffee cups, you might be wasting too much time by testing the
real interface. For example, in a usability test of software for network administrators, users were asked
toset up some tests of the network that would take several hours to execute in real life. With the paper
prototype, we just told them, "It's now the next morning, and here's the report." (Sometimes with
software you can do something similar, but other times it's just too much of a pain.)
User-Defined Tasks
In a paper prototype test, it's a given that you know what the tasks are because you came up with them
before creating the prototype. But sometimes it's important to watch users doing their own
tasks—something that they care highly about—rather than tasks you invented. When users work on
their own tasks, they may uncover subtleties that you weren't aware of (or even entire tasks you weren't
aware of). Unless the data and/or functionality of the interface is quite limited, user-defined tasks
usually aren't feasible with paper because you need breadth—you can't predict where users will go. For
example, you may need the entire pet products catalog rather than just the section devoted to ferret
toys.
Search WWH ::




Custom Search