Database Reference
In-Depth Information
Existing versus new Design?
Sometimes a debate comes up about whether it's better to test a prototype of the existing design or to
scrap it in favor of a new approach. Neither answer is wrong—a paper prototype can evolve from any
starting point—so here are some factors to consider:
The cost of mistakes is low.
If you try something new and it flops, you haven't wasted much time.
And often you'll learn information that will help you even if you keep the current design. For
example, one team prototyped a wizard to help with a configuration task. They weren't sure
whether their development schedule would allow time to implement the wizard, but they still got
feedback about terms, concepts, and what assistance users needed to make decisions along the
way. All this information was useful even though, as it turned out, they had to stick with a variation
of the current design.
Don't redesign something you haven't tested.
If you don't have consensus on what's wrong
with the current version, you might want to use it for the first couple of tests until you understand
the problems you need to solve and then do your redesign. It's easy to fall into the trap of
reworking and polishing a design before users ever see it, only to have the first usability test reveal
some huge issue that forces you to redesign it. On the other hand, if your customers have already
told you what's wrong and you have ideas about how to fix it, go for it. (As a developer once said to
me, "We know this part is bad—there's no point in getting 10 people in here just to tell us it's bad.")
Limit time, not creativity.
You don't want to spend long stretches of time designing without
getting user feedback—that would defeat the purpose of paper prototyping. One way to manage
this is to establish an upper limit for the amount of time you'll spend creating your prototype. When
you've reached that limit, test what you've got.
One advantage of paper prototyping is that you can prototype something without regard to whether it
can actually be built. This is also one of its drawbacks. The degree to which technical constraints
should be considered depends on whether you're prototyping something you plan to release in 3
months or 3 years— the longer your time frame, the more you can focus on what users need and then
figure out later if and how to build it. There's a similar argument for adherence to interface style guides.
If your company has a corporate style guide and it's not negotiable, it's probably best to have your
paper prototype conform to the style guide. But if you're trying to make a case for changing those
guidelines, you might deliberately do something different to determine whether it will work better.
Search WWH ::
Custom Search