Database Reference
In-Depth Information
submitting a "minor" change doesn't accidentally break the very thing you're trying to test. This can
have a detrimental effect on schedules, unless the entire development team plans to attend the
usability tests or wouldn't be submitting any changes during that time anyway.
But if you use a paper prototype, usability testing and development are completely separate and can
proceed in parallel without risk of hurting each other. I've known a few development teams who chose
to conduct paper prototype tests late in the project—when a reliable version of the interface was
available—simply to alleviate any risk that the development schedule would be impacted.
You might respond that a good project manager is capable of handling all these circumstances,
especially with decent version control software. That's true, but not all project managers are that
good—when I was a project manager my sanity was fragile enough as it was, and the need to maintain
a stable environment for usability testing would have pushed me right over the edge. If your
development process runs like a Swiss watch, paper prototyping may not offer you any advantages.
But for those who are already logistically challenged, paper prototyping can make life easier.
Test Environment—Hardware and Facility
One way to avoid conflicts with ongoing development is to set up a separate test environment with all
hardware, software, network connections, and so on needed to do the tasks. Maybe you're lucky
enough to have a fully outfitted usability lab. Or your QA department or training facility may have
something like this, although if they use it every day you may not be able to borrow it.
You may be thinking, "What's all the fuss about a test environment? I'll just run it on my laptop." If your
interface runs in a simple and self-contained environment like that, then you're right, you don't really
have this problem. But some test environments require lots of technology—think servers, multiple
computers, hardware devices, and the like. The harder it is to create a good, realistic test environment,
the stronger the argument in favor of using a paper prototype to avoid going to all that trouble (and
possibly expense because hardware isn't free).
Test Environment—Accounts and Databases
For some testing situations, it's easy to set up dummy accounts and databases for users to use when
performing tasks. Other times this isn't as feasible. For example, one financial services Web site didn't
have a test database for usability testing (the developers had one but it wasn't possible to share it), so
for testing purposes we had to use the real Web site, which naturally accessed the real customer
database. For tasks that assumed the user already had an account, we needed a real account. There
was a VP at the company who allowed his account to be used for this purpose (provided we didn't buy
or sell anything!), but this guy was in no way a typical user—he owned dozens of stocks. Thus, users
had to wade through a large amount of unfamiliar data, which made some of the tasks artificially
complex. And since we couldn't transact, we were limited in what we could test.
Search WWH ::
Custom Search