Are All Problems Serious?

Did someone ever approach you with a usability problem that was categorized as “serious”, and needed to be fixed asap? Other people might chime in, and now the issue is “very serious”. But more often than not, there are no real metrics to determine the real severity of an issue. A lot of times it is based on gut feelings, and more often than not, it becomes a personal and/or political too.

It turns out, as we probably instinctively know, that one mans serious is another mans benign. According to Rolf Molich,

The CUE-2 teams reported 310 different usability problems. The most frequently reported problem was reported by seven of the nine teams. Only six problems were reported by more than half of the teams, while 232 problems (75 percent) were reported only once. Many of the problems that were classified as “serious” were only reported by a single team. Even the tasks used by most or all teams produced very different results—around 70 percent of the findings for each of these common tasks were unique.

*Emphasis is mine.

I speculate that this has something to do with group dynamics. Frequently you will see that an alpha-male (or female) will emerge in the group, and what he/she deems important is considered serious by everyone else. The group might exaggerate issues to appease the alpha, making things appear worse than they really are. The alpha might try to assert his dominance by elevating his observations too.

In real life, problems are often relayed through a long series of people; The end user tells his manager, the manager tells his manager, he then tells his integrator, who tells the distributor, who talks to the rep, who tells his manager, who then takes it up on a meeting with the CTO, who then tells the team-lead or dept. manager and then – finally – it lands with some programmer, in a completely different shape.

A List Apart has the full story


Author: prescienta

Prescientas ruler

2 thoughts on “Are All Problems Serious?”

  1. You are absolutely right, that you need to define a set of personas and a list of realistic use cases before implementation of the UI can begin. We tried to use a 90/90 paradigm in our client – we wanted to design for what 90% of the users do 90% of the time, and make those functions real easy, while perhaps “sacrificing” the last 10/10.

    But naturally we made mistakes along the way. Even with a pretty good understanding of the various users capability (some want scripting ability, others want BIG, inviting buttons) we DID screw up some things. But given that A, B and C present problems to our users, which issue do we fix first?

    There are a lot of parameters when deciding what to do, some objectively rational, others less so – perhaps the client with problem A is VERY annoyed (but he is just one out of thousands of users), perhaps B affects 90% of our users, but only few complain because they chose to “just live with the issue”, or perhaps C because a large account depends on it.

    Ultimately, it also depends on our technical abilities – look at how mapping (google and microsoft), they both evolved as technology and knowhow matured, and navigating the maps at street level is now extremely simple. Hopefully we will reach that level of maturity soon 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s