Database Reference
In-Depth Information
How Much to Prototype—Anticipating Paths and Errors
There are often several correct ways to complete a task, not to mention a seemingly infinite number of
ways for things to go wrong. You should prepare enough of the prototype to accommodate things that
users might reasonably do, but it's not necessary to anticipate everything that might happen in the
usability tests.
For example, on a Web site, some users might use the search engine, whereas others navigate by
clicking links. In this case it's reasonable to prepare both alternatives unless one of them simply isn't
interesting for you to watch. But don't go overboard and try to prepare for every combination of terms
the user might enter. Just pick the few search terms that you think are most likely and don't worry about
those one-in-a-thousand edge cases. This may be inherently difficult for programmers to do because
the exceptions and edge cases are often what make code complicated, and unanticipated edge cases
are a common cause of bugs. But it's usually premature during paper prototyping to worry about making
the code robust—you first need to make sure you have a design that works for users.
What about errors? It's pretty darn likely that some users will step off the path you envisioned for
accomplishing the task. Prepare to handle the errors that seem likely, but don't make yourself crazy. It's
always possible during a usability test to jot down an error message or even just tell the user what it
would say. As explained in
Chapter 9
, there are ways for the test facilitator to respond if a user tries to
do something you haven't prepared for.
Avoid putting too much effort into your initial prototype. A good rule of thumb is that you should feel
about 50% ready before your first internal walkthrough and 80% to 90% ready before your first usability
test. If you feel 100% ready, chances are you've put too much effort into an interface that will need to
be changed anyway.
Search WWH ::
Custom Search