Database Reference
In-Depth Information
People who aren't programmers are just looking at the screen and seeing some pixels. And if the pixels
look like they make up a program which does something, they think "oh, gosh, how much harder could
it be to make it actually work?"
The big risk here is that if you mock up the UI first, presumably so you can get some conversations
going with the customer, then everybody's going to think you're almost done. And then when you spend
the next year working "under the covers," so to speak, nobody will really see what you're doing and
they'll think it's nothing.
But with a paper prototype, the effort that went into its creation is measured in minutes or hours, rather
than days or weeks. The feeling of ownership is proportionally less, as is the knee-jerk reaction to
defend the design and resist changing it. If you've spent 15 minutes drafting a screen and the first user
finds a huge problem with it, it's relatively easy to throw it away and try something different.
More Creativity
Veteran usability specialist Mary Beth Rettger describes an interesting phenomenon regarding how
paper prototypes can result in design revolution, not just evolution. The MathWorks makes extensive
use of paper prototypes during development. Mary Beth has noticed that sometimes a developer will
test a paper prototype and find some minor problems—nothing too serious. They'll start to tweak the
interface, then scrap it in favor of an approach that's very different and much better. It's hard to
articulate, but amazing to watch. She says, "It's as if they turn the design inside out and upside down.
Or keep one piece and change everything around it. It's almost organic in nature." Because paper
prototypes are a flexible medium that let you see the strengths and weaknesses of a design early on,
Mary Beth conjectures that they facilitate the kind of quantum design leaps that lead to greatly
improved usability.
Multidisciplinary Teams Can Participate
Interfaces aren't created by interface designers or programmers alone; there's a whole cast of
characters whose insights need to be funneled into the design. Customer support reps often have a
good grasp of what customers find confusing, and so do trainers. Technical writers can provide a
"distant early warning" about usability problems when they run into something that's hard to document.
(When I was a software project manager, I learned that when the tech writer wandered into my office
with a puzzled look asking, "Can you explain to me again how this six-level alarm prioritization thing
works?" it was usually a clue that we'd over-designed something.) And if the people in Sales and
Marketing have done their homework, they'll have a lot of data about what the target market wants, and
why.
Search WWH ::




Custom Search