Database Reference
In-Depth Information
typically what the doc/help are helping with. When a paper prototype of an interface is being tested, it's
possible to gather useful information about what questions users have, what information is needed to
answer them, and equally important, what doesn't need to be explained. By listening to the terminology
they use, you can glean terms for your index.
If along with the interface prototype you are also testing a prototype of the documentation, its look may
matter because formatting can aid the user's ability to find and use information. But it's usually not
important to duplicate the final appearance of the help system or manual—drafting the content using
your favorite word processor and adding a few headings is sufficient for a paper prototype test.
Requirements/Functionality
Most functionality is expressed in terms of what the interface does, rather than how it looks while it's
doing it or the specific interaction methods used (although there could be exceptions to this rule). But
it's pretty much a no-brainer that if you've built the wrong thing, it's going to fail with its intended
audience. Ideally, you should have a decent understanding of user requirements and functionality
before you begin the design of the interface. But if you've missed a requirement or gotten one wrong, a
paper prototype can help you find it.
Screen Layout
You might think I've mistakenly put this section under paper prototype's strengths because questions
pertaining to screen layout seem like they'd require a prototype with a realistic look. But many questions
don't—a designer first needs to understand what elements should appear on the screen and also
something about their relative priority. For example, if users who sign up for a service wonder whether
there's a cost, you'd want to make sure that the word "free" jumped out at them in the final design. But
until you did some usability tests, you wouldn't realize users had this question.
In essence, the findings from paper prototype tests can provide useful inputs to the process of
designing screens because they will help you determine whether you have the right set of information in
the right order, whether you've forgotten anything, and what elements need to be emphasized. On the
other hand, once you're to the point of trying to determine whether you've used enough white space or
if the Next button stands out enough, then you do need a more realistic visual representation.
Brand
Brand applies to the user's whole experience with the site or product, not just its appearance. A car
may look great in the showroom, but you won't notice a problem with its suspension unless you drive it.
Breadth and depth are often important to the brand, sometimes even more important than the look. If
an interface is tastefully designed but doesn't let users do what they want, ultimately it won't create or
reinforce a good impression in the user's mind. [ 4 ]
Although one can no longer argue, as some usability specialists did back in the mid-1990s, that graphic
design is unimportant, neither can you take a flawed user experience and fix it by adding rainbows and
puppy dogs. (I realize that no self-respecting graphic designer thinks this way, but occasionally I run
across other people who do.)
A rough-looking paper prototype with sufficient breadth and depth can go a surprisingly long way toward
revealing the ways in which the interface will support or interfere with the brand image that the company
would like to convey (see the Of Interest box on p. 276). Once you have a solid foundation in terms of
making the interface do what users need, then the look can build upon it in a way that supports and
enhances the user experience.
[ 4 ] Remember that famous line from the movie 2001: A Space Odyssey where the computer HAL seizes
control of the ship? It didn't matter one iota that HAL politely said, "I'm sorry Dave ..." before dropping
the bombshell"... but I can'let you do that."
Search WWH ::




Custom Search