Author: Louise Pryor

One of the criteria for good software is that the software is usable. If it is difficult to use, it will meet one of several fates: either it won’t be used, or it will take much longer to use than it should, or it will be used in the wrong way and will produce invalid results. None of these outcomes is desirable.

When looking at usability, it is important to consider all the possible users, their goals in using the software, and the context in which they use it. For instance, technical terms that are second nature to one group of users might be totally meaningless to others. This is particularly important for user-developed software, such as spreadsheets, where the developers often have a very different outlook to other users.

Usability means making it easy for the user to do the right thing, and difficult for them to do the wrong thing. It can be affected by the physical layout of the interface (whether graphical or text based), the wording of any text, the order in which operations must be performed, and many other factors. One of the trickiest aspects of achieving good usability is that it is often difficult to predict how users will react, especially if you are not a typical user yourself. The only way to get it right is to test the software with real users, and take note of what they say.

There is no point in building a piece of software if it is not going to be used, and it won’t be used unless it is useful to someone. There is often a temptation to build something just because you can: you can see a really nifty way of doing it, and fancy the challenge or think it would be cool. It is a temptation that should usually be resisted.

This applies at all levels of software development, to individual features as well as to entire software systems.

For example, if there is a simple task that is currently performed manually, and you are thinking of automating it, you should look very carefully at what would be gained. Would the new system be easier or quicker to use, would it provide more information, or would it be less likely to result in errors? Unless the answers to these and similar questions are extremely positive, you should be very wary of going ahead.

You should ask similar questions when considering introducing a system or feature that will provide completely new functionality. Is anyone actually interested in this functionality? Will the benefits of using it outweigh the inconvenience? Remember that you, as the developer or designer, may not fully understand the priorities of the users.

There is no point in building a software system unless it is available for use. Availability can be compromised in a number of ways:

• The software doesn’t run on the equipment available to the users
• It often crashes
• The network over which it runs is unreliable
• …

Availability is often an issue with real time systems, but can be significant in other situations too. For example, consider a software system that is used in preparing quarterly financial results, but takes longer than three months to update. If changes are needed, there is a conflict between providing the functionality that is required, and providing any functionality at all. Obviously this example has been exaggerated for effect, but the point is that availability can be affected by maintenance requirements as well as by physical problems.

Performance can affect usability, usefulness and availability.

Software that takes too long to perform its functions rapidly becomes difficult and unpleasant to use, thus making it both less useful and less usable. For real time systems, of course, performance is even more of an issue and is an important aspect of correctness.

The other aspect of performance is the amount of memory and storage that is used. These are less of a problem nowadays than they used to be, but can still be a limiting factor. Even today’s large disks can eventually run out of space, and some systems run very slowly if at all if not enough memory is present. The system then becomes effectively unavailable for use.