Preparing the Prototype - Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces - page 111

Don't Forget the Data
There is likely to be some data associated with the tasks, and you'll need to prepare that too, not just
blank screens. Developers are accustomed to thinking of data in terms of structure (the account
description is a 20-character ASCII string) rather than content (Mike's IRA). But the content is what
users care about. They enter data that is meaningful to them, and they expect the interface to reflect
the information they entered. The interface is really just a means to an end, so users are likely to pay
more attention to the data than they do to the widgets that make up the interface.
Often it's important for users to see how their data will appear elsewhere in the system. If a user is
creating an online classified ad by filling out a form, he or she will probably want to preview that ad in
the same format the system will use to display it. If you ask users to simply imagine something ("It'll let
you preview your ad"), you could miss important feedback, such as, "Oh, wait—it took out those extra
blank lines I wanted it to have."
The data you use should be realistic enough that users can interact with it in a meaningful way. This is
especially important when users are domain experts in the subject matter of the interface. In the
MathWorks cpselect case study described in Chapter 2 , the team initially tried to use hand-drawn
sketches to represent pictures of land masses in their prototype. They quickly learned, however, that
this wasn't good enough for image processing tasks. The users got distracted trying to make sense of
the sketches because image processing was what they did in their work. The team replaced the
sketches in their paper prototype with aerial photographs, which were suitably realistic and worked
much better. Similarly, if your users are accountants and you're testing a financial application, the
numbers had better make sense.
Make sure the data "hangs together" in a consistent manner throughout the task. If you ask users to
find all the three-bedroom houses for sale but you show them search results that include some four-
bedroom ones, users might wonder what they did wrong. (Of course, if you're clever with the removable
tape, perhaps you can cover up the four-bedroom houses, thus solving this problem on the fly.)
You should also include a realistic degree of complexity in your paper prototype. If your online hardware
store sells 37 cordless drills but you pretend there are only 3, you'll design the drill page in a way that
may not scale. This is not to say that you need the product pages for all 37—you might constrain the
task in such a way that the users are likely to look at only 6 of them.
Where do you get realistic data? Some companies have suitably complete databases that are used in
quality assurance testing, or perhaps Marketing has something they use for demos. But if your test
databases contain mostly nonsense filler such as "test1" and "asdfasdf," you're better off creating your
own. If you are having trouble coming up with a realistic scenario, talk to the people in your company
who have contact with users. Just don't use a database that has real people's information in it—that's
too realistic!