Nielsen, J. (1993). Chapter 1: Executive Summary - Usability. In Usability Engineering. [my response]

Usability can show us what is wrong with a design as well as what is unneccesary. Unfortunately, this information is often ignored or misunderstood. One of the most encouraging statements in this chapter is that software is often recommended on the basis of usability. I think we are reaching a stage where the general public are becoming more aware of their choices and less in awe of the technology. As a result they are also becoming less tolerant of 'crap'. Nielsen's statement that time is in our favour would tend to support this as well.

It is generally accepted that in any given software endeavour, only 30% of the code (measured in number of lines) is actually written to accomplish the task at hand. Fully 70%, by volume, deals with error detection and recovery. If we now add to that the code involved in GUI support, the percentage of code actually doing the work drops even further. Given that such a high percentage of the lines of code written will relate to things like error detection, recovery, and GUI's, it would stand to reason that efforts to make this part of the task more efficient, robust, and usable will ultimately pay off in reduced production and maintenance costs.

Video games are often used as an example of sound user interface design. I suggest that this is a fallacy. The history of interface design for games has its roots in console games, which in turn had its roots in mechanical games such as pinball. The development of the interfaces were not the result of conscious usability engineering. It evolved out of what users were accustomed to. The current situation in interface design for games is extremely limited. There is virtually no flexibility for the interaction elements. These are driven by established expectations. Gamers expect the interface to behave in a particular way and rarely accept variations. Users of computer games are VERY unforgiving, and the games market is one of the most competitive markets in existence today. Customer satisfaction is essential, and designers have a very small window of opportunity to 'hook' the player into their game. If the user needs to spend too much time learning how to play the game, they will simply discard it and try another.

The "Ten Commandments" of Usability Engineering:

We don't need ten. They are not distinct, in that several amount to the same thing, so I propose 4:

1. Less is More
2. Watch Users
3. Try Stuff
4. Pay Attention

The explanation for the commandment, "The user is always right" seems quite sound, but the explanation for the next one, "The user is not always right" does not actually support the statement. It is true that in the example, the users said 'no'. However, upon testing, they ended up indicating 'yes'. They may not have said it, but the test results (i.e. the users) showed 'yes'. The message I get from this is simply that just asking people is insufficient - they have to be allowed to try it. Also, it would be foolish and naive to ignore what we already know about populations in general - people are not all the same. We need to decide if we are striving to meet everyone's needs exactly, or some of the people some of the time, all of the people all of the time,...

Much was said in the article about what amounts to inattentiveness on the part of the designer. Perhaps one solution would be to find a designer who rates high in Interpersonal Intelligence. Still on the same vein, I take issue with Nielsen's statement that "knowing about a system is a one-way street". While there is some truth to this, much of it has to do with an individual's ability to consider another's perspective and whether they can demonstrate some empathy. If a designer cannot remember at least some of what it was like to be a novice, then they should be made to learn something new and told to remember how that feels.

A Final Comment:

Nielsen comments that he has found through testing that Computer Scientists can learn to use "thinking out loud" methods. This will come as no surprise to anyone who has learned to program. Anyone who has learned to write programs that work, has also learned to debug code. This technique (thinking out loud), whether audible or not is used by virtually all programmers when they are testing and debugging their code.