What Matters Most?

By Gerd Waloszek

Experience with a dissatisfying software application brought me back to one of the most basic usability questions: What matters most? Let me put this question slightly differently: Which three usability problems annoy most? Please, stop for a minute and reflect on this question. Then, I will tell you which three usability problems annoy me most.

Waiting Times

Waiting times were an important issue in the mainframe area: You hit "Enter," that is, sent a command to the host computer and had to wait for the system's reaction. Depending on the duration of the waiting time, you could work more or less uninterrupted. As far as I can remember, waiting times beyond half a second were regarded as detrimental. With the advent of personal computers, waiting times no longer seemed to be an issue, and we came to expect computers to react immediately. The Web, however, is one of the reasons that waiting times did not disappear into the shadows of history. With the above-mentioned software, which is based on Web technology, waiting times reached a previously unknown dimension: They ranged from a few seconds on "good" days to minutes (or endless) on "bad" days. I had time enough to study the effects of waiting times and learned that they can disrupt your work completely. At worst they prevent you from making any progress. On the other hand, I also learned that you can cope with bad usability, provided that waiting times are short, and you can "muddle" your way through an application and achieve your goals. That is the reason why waiting times come first on my list of usability problems.

Crashes

Computer rage In the introductory phase of the above-mentioned software, its editor crashed frequently. As a typical result, I lost my recent work and had to start over. Obviously, this fact alone would be reason enough for a high rank in my problem list. But there is another effect of crashes, which led me to rank crashes second: As crashes made me lose my work, I tried to avoid them and invented counter-strategies. For example, after each minor change, I applied my changes in the editor and saved the page. This procedure worked in most cases (sometimes, however, the editor crashed when I applied the changes...) but led to an even more disruptive work flow: After a "Save" command, the editor refreshes the page and loses the work context, i.e., the current selection and, of course, the edit mode. Finding the correct selection point was often cumbersome due to the node concept used by the editor, took times, and caused annoying screen refreshes. Seen in retrospect, the crashes led me to invent an inefficient "bypass" procedure, which was only partially effective. Now, if we rightly assume that the editor's stability will improve over time so that it is no longer necessary to save the page after each small change, when will I realize that I can stop using this inefficient procedure? Probably never, because eventually it will be deeply engrained in my work practices. Thus, crashes make us inefficient in two ways: We may lose our work and we adopt inefficient strategies to circumvent the losses – reason enough to rank them second on my list.

By the way, don't we all use such inefficient procedures because we adopted them at some point in time and never considered to abandon them in favor of more efficient ones?

The Rest

And then comes the rest. Are you surprised by this crude simplification? Do you believe that I am wrong? Wouldn't it mean that we can throw away all our usability efforts? Of course not, why should I bite the hand that feeds me... I know there are zillions of awful usability problems in today's software. But if I had only three categories at my disposal, I would definitely put the remainder into box three.

Update: I found A Number Three!

After the first dust has settled with respect to the abovementioned software, that is, the crashes have become rare, and the waiting times were no longer in the range of several minutes, my picture got clearer about what ranks after these two fundamental problems: In my opinion, it is missing functionality.

The lack of functionality can constrict you in several ways:

In its severest form, it can prevent that you can achieve your goals with an application, or put simply, you cannot do what you want to do.
That is, the system is not effective.
In a "milder" but nonetheless annoying form, the system let's you achieve your goals but only in a very cumbersome fashion, which may drive you crazy. Here, the system dictates how you have to carry our procedures and doesn't grant you the flexibility that you want and need.
That is, the system may be effective but it is not efficient.

If you want an example for the second case, please go to my list of "Golden Rules for Bad User Interfaces" and take a look at example 13. See also the SAP Design Guild editorial What Matters Most? (which is similar but not quite identical to this story).

Originally Published: 11/10/2005 - Last Revision 02/01/2009