125 What Makes Problems Severe
129 The Scale of Misery
132 Why Users Fail
134 Is It Enough to Focus on the Worst Problems?
Usability can be a matter of life and death. In war a soldier in a fighter plane has a critical edge if his plane's user interface for targeting and firing systems is just one second faster than his enemy's. On the Web, of course, usability does not have such a dramatic role. But it can determine whether your Web site fails or succeeds.
How do you know which usability problems have the most serious consequences for your Web site? Which ones to fix and which to let go? In this chapter, we discuss the issues that create the most trouble for users and the most missed opportunities for businesses. With this information, you can best decide how to allocate your resources.
There is a lot wrong with Web sites today, but to improve usability, we need to prioritize our resources and fix the problems that hurt users the most. To do this, we need a systematic evaluation of the severity of Web usability problems. This chapter provides that.
When we write consulting reports for our clients, we rate usability problems very simply as high, medium, or low. We then base our recommendations on the severity of the problems: Fix everything rated high, if possible; spend some resources on medium problems; and defer fixing low issues to a later date unless they're so trivial that they can be resolved with almost no work.
For the book research, we use a 100-point rating scale for severity because numeric ratings allow us to provide more interesting statistics than a rating scale based on words. We don't recommend that you apply this more complex scale to your own design because it's too detailed for everyday development projects. Simpler ratings allow designers to focus on their priorities, which are to fix the most severe problems. A fancy scale is an open invitation for everyone on the design team to pipe up and quibble over individual points. This is not a fruitful use of time because there is no meaningful difference between something rated 62, say, and something rated 63.
There's another reason that a simple scale is best for practical projects: You need to balance the severity of the problem against the effort required to fix it. Even a high-severity problem can be fixed later if that's going to be extremely costly and time consuming. We all know that estimates of development schedules are little better than numbers drawn out of a hat, and thus overly precise usability ratings have no place opposite rough development estimates.
For every usability problem on your site, you need to balance the severity of the problem against the effort required to fix it.