What Matters Most?

By Gerd Waloszek, User Experience, SAP AG – November 13, 2008 • original article (editorial)

Once, I had to use an application that reminded me of a very basic usability question: What matters most? Based on my experiences, I found the answer quite revealing, especially with respect to the role of usability efforts in the development process. For this article, let me put the initial question slightly differently: Which usability problems annoy me most?

 

Number One: Waiting Times

SnailMy number one problem is waiting times. Waiting times were an important issue in the mainframe era. 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 – users came to expect computers to respond immediately. The Web, however, is one of the reasons that waiting times did not disappear into the shadows of history. With the application that I am referring to, which is based on Web technology, waiting times reached a previously unknown dimension for me: They ranged from a few seconds on "good" days to several minutes (or an endless wait) on "bad" days. I thus had plenty of opportunities to experience the effects of waiting times and learned that they can disrupt your work completely; at worst, they can 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.

 

Number Two: Crashes

CrashThe application I am referring to crashed frequently. As a typical result, I lost my recent work and had to start over. So I tried to avoid crashes and invented counter-strategies. For example, after each minor change I saved my work. This procedure worked in most cases (though sometimes the system crashed when I saved the changes...) but led to an even more disruptive work flow. 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 application's stability will improve over time so that it is no longer necessary to save your work after each small change, when will I realize that I can drop 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 of usability problems.

 

Number Three: Missing Functionality

Missing toolsAfter the first dust had settled with respect to the application, that is, crashes had become rare, and waiting times were no longer in the range of several minutes, my picture got clearer about what ranks next after these two fundamental usability 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 you from achieving your goals, or put simply, you cannot make the application do what you want it 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 out procedures and doesn't allow you the flexibility that you want and need. That is, the system may be effective but it is not efficient.

As a simple example, think of an application that doesn't let you select several items at a time and perform an action on them, such as Delete. As a result, you have to carry out the procedure for each item separately. This is particularly cumbersome if procedures consist of several steps.

 

Number Four: The Rest

And then comes the rest. Are you surprised by this crude simplification? Do you believe that I am wrong? Wouldn't this 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 four categories at my disposal, I would definitely put the remainder of the problems into box four. And also remember that this is just my personal ranking...

 

Conclusion

Returning to the starting point, we find that my two most severe usability problems are basically "technical problems" which typically lie beyond the scope of traditional usability efforts. It's a bit like the old wisdom that your car has to have four wheels before you can drive it. In this metaphor, crashes mean that your car frequently breaks down en route. Thus, it makes little sense to improve an application's further usability until these two problems have been solved. By the way, missing functionality can be compared to driving in first gear only – also not a very pleasant outlook... Nevertheless, item three of my list of usability problems focuses on usability and reminds us how important it is to place the users and their needs at the center of the development process.

 

top top