 | Level: Introductory Jakob Nielsen (http://www.useit.com), Usability guru, Nielsen Norman Group
01 May 2001 I will return to what does work in terms of my
recommended usability engineering lifecycle.
The common ways of organizing a development project both fail to deliver
sufficient usability:
- The waterfall model that was much beloved in the early
days of software engineering and still dominates some government
procurement projects.
- The let's just throw something out there and see if it
sticks approach has been popular among certain Web sites that
misinterpret the concept of "Internet time" and think it justifies
low-quality projects.
Neither works. I will return to what does work in terms of my
recommended usability engineering lifecycle, but first, let's look at why
the two common lifecycle models fail.
Waterfall doesn't work
The waterfall model fails for the simple reason that most people
cannot read specs. Anything that is based on a linear progression
from one set of specs to the next will fail. It sounds logical that you
first analyze one thing, write down the requirements, and then move on to
design something more detailed based on the now-fixed foundation.
Sorry, the foundation is wrong. Building on specs that tell you to do the wrong thing will result in -
surprise - the wrong thing. It does not matter that you get the
users or the users' management to sign off on the specs and promise that
they form a complete description of their needs. All experience shows that
the final software will fail to meet the users' needs, even if they
themselves signed on the dotted line the year before.
Stuart Burnfield from Gentoo Communications in Australia told me this story
which clearly explains why specification documents are insufficient to
capture user needs:
Years ago I worked in an office that was given funds for a refit. It
being a programming and support group, the project was run somewhat
like a development project -- requirements, analysis, design, and so
on. This part was fairly successful. Draft floor plans were
circulated and revised based on feedback. A final layout was approved
and construction began.
Problems appeared. The support people realized that the four desks
in their cluster were separated by partitions that were below face
height, so they'd each be hearing three other conversation as they
tried to take their own calls. They went straight to management, who
were furious. Hadn't the layout been approved? Didn't the plan clearly say
1200 mm?
The problem was that the 'prototype' was in a form that made it
nearly impossible for the staff to visualize the third dimension,
height. A number next to a line gives the information in a technical
sense, but doesn't say "below face height". The result was a layout
that worked well only in the other two dimensions.
 |
Mud-slinging doesn't work either
Rebelling against the perceived slowness of traditional development
processes, some Internet projects have adapted the approach of
treating their Web sites like mud. The "method" is:
- Throw it at the wall.
- See if it sticks.
Hundreds of millions of dollars get wasted this way. Can you say Boo?
The theory goes that if the initial design is bad, one can always put a new
one out on the server. This does not work because
launching a site that is difficult to use will deprive the business of its
best customers: those that are so eager to use your service that they will
visit the site as soon as they hear about it. If these users get a bad
experience, they will not only be lost to you as customers, they will also
be lost as potential future advocates for the site.
True, you can fix the design on the site, but you can't regain the lost
customers.
What does work? Iterative design
The one thing that works for creating usable systems is a full usability
engineering lifecycle that corrects the quality of the design at every
single step of the way.
Here is the lifecycle I recommend, divided across the three main stages of
a development project:
-
Pre-design phase
- Conduct field studies of the ways your users currently
approach the problem. Not that you have to do exactly that in the software,
but you want to know what people actually do in real life and not
what the procedures manual claims that they do.
- Run a usability test of the old system. If one is in
place, don't just discard it. Much can be learned from seeing its strengths
and weaknesses exposed in a study.
- Conduct competitive studies of any other solutions on
the market. Instead of relying on the hearsay you get from reading industry
analysis, collect real data about what actually happens when real people use
these other systems. You will often find that some of their highly touted
features don't work very well, but that you have opportunities for doing
things in a much easier way.
-
Design phase
- Start with a parallel design exercise: Explore the
design space by making up diverging designs that solve the problem in many
different ways. Collect a small amount of user test data on each approach,
even if it is only "implemented" as a few screen mock-ups or paper
drawings. Decide on the best approach for going forward. (Usually, this will
involve elements from several of the parallel designs.)
-
Iterative design: Evolve the chosen design direction
through several rounds of usability feedback, adjusting it each step of the
way. The more usability data you can incorporate into the design, the
better.
-
Prototyping: Gradually evolving from low-fidelity
prototypes in the early stage of the project to high-fidelity prototypes in
the later stages. Even very low-fi prototypes can be tested with users, and
even if you don't learn quite as much as when testing hi-fi, you can do so
much earlier when:
- It costs less to make changes.
- You are not so emotionally invested in the preliminary solution because you have not worked on it for very long.
- You still have time to act on the findings and change the architecture of the solution.
-
Post-design phase: You may think that once your
project ships, you are done with this pesky usability work. No way. More
steps:
-
Collect statistics and feedback from real use: check
log files in case of a Web site; interview real customers about how they are
actually using the software. (No matter how careful you were in the pre-design phase, there may be some new uses that you did not predict.)
-
Refresh: In case of a Web site, you can take advantage
of having direct control over the running code on the server and fix any
immediate problems your post-design studies reveal. Such changes should be
in the nature of tweaks to the original design and not a full-fledged
redesign.
- And at some point of time you need to start planning for an actual
redesign: remember that your current release is your best
prototype of the next release, and start planning for the next release
while you still have enough time to do a good job.
The model may seem extensive, but many of the steps are only a matter of
one or two days' work.
Doing things right will only add a few percent to the cost of a development
project. You will save many times this cost by not having to make
expensive adjustments and dot releases. Plus, the resulting user interface
will probably be around 50% to 100% easier to use, reducing training
budgets dramatically and increasing user productivity. If you happen to
be running an e-commerce site, you will have the sweetest gains of all:
customers will finally start making purchases now that they can find what
they want on the site. Rule #1 of e-commerce: if you can't find it, you can't buy it.
About the author | | | Jakob Nielsen, Ph.D., is a Web usability guru and a principal of Nielsen Norman Group, which he co-founded with Dr. Donald A. Norman, former Vice President of Apple Research. Before starting his own company, Nielsen was a Sun Microsystems Distinguished Engineer; he has also worked at the IBM T. J. Watson Research Center, Bell Communications Research, and the Technical University of Denmark. Nielsen is the author of several best-selling books; his next book, Designing Web Usability: The Practice of Simplicity , will be published by New Riders on November 29, 1999. Dr. Nielsen has been called "the guru of Web page usability" (The New York Times) and "the smartest person on the Web" (AnchorDesk), and "the next best thing to a true time machine" (USA Today). He holds 50 United States patents, mainly on ways to make the Internet easier to use.
|
Rate this page
| |
