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.
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.
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.
