Software usability and documentation
In general, good documentation can reduce your support costs. However, you should not expect documentation to fix users' problems that should never occur in the first place. This article shows how a user-centred approach to software design can reduce the requirement for documentation.
General benefits of software usability
Customers are increasingly aware of usability and consider it when making a purchase. They want software that doesn't waste their time or try their patience. Studies have shown that if customers are offered two software products with the same functions at the same price, they choose the product that is easier to use. Companies such as Microsoft, Compaq and Lotus include usability as part of their advertising campaigns. Most product reviews include usability as one of the review criteria.
Creating software with usability in mind can be highly cost-effective, benefiting not only the end user, but also the system developers, support staff, training, and documentation teams. It shortens development time and improves the marketability of the software. IBM has cited a 1:10 to 1:100 cost-benefit ratio for usability. For every pound spent implementing usability methods, the payback is between £10 and £100.
Well-designed software reduces the documentation burden
Documentation is only needed when the software itself cannot supply the information that a user requires. With this in mind, consider the ten best practice heuristics for software design (www.useit.com/papers/heuristic/heuristic_list.html) that have been developed by usability guru Jakob Nielsen.
| Heuristic | Explanation | Effect on documentation |
|---|---|---|
| Visibility of system status | The system keeps users informed about what is going on. | If a user can see on screen what is happening, it's not usually necessary to explain it in documentation. |
| Match between system and the real world | The system uses words and concepts that are familiar to users, rather than system-oriented terms. | Familiar terms don't need explanation. For example, if the interface reads, "Enter an integer", then the documentation might need to explain the term "integer". |
| User control and freedom | Users can easily find "emergency exits" if they choose system functions by mistake, and they can undo and redo operations. | If a user can undo accidental operations, there is less likelihood of requiring documentation that explains how to recover from an unintended system state. |
| Consistency and standards | Each word, phrase or image is used consistently, with a single meaning. | Consistency helps to avoid confusion, and the consequent requirement for documentation to clarify the meaning. |
| Error prevention | Even better than good error messages is a careful design that prevents a problem from occurring in the first place. | If a problem is prevented, there will be no documentation requirement. |
| Recognition rather than recall | Objects, actions, and options are visible. The user does not have to remember information from one part of the dialogue to another. Instructions are visible or easily retrievable. | If information is visible on screen, it's often not necessary to repeat it in supporting documentation. |
| Flexibility and efficiency of use | Accelerators are available to experts, but are unseen by the novice. Users are able to tailor frequent actions. | Novice users could have access to Wizards, which guide them through a process. In many cases, there would be no need for documentation that explains the Wizards. |
| Aesthetic and minimalist design | Dialogues do not contain information that is irrelevant or rarely needed. Extra information competes with the relevant information and diminishes its relative visibility. | This requirement might lead to additional documentation for the rarely needed information. However, since the information must be expressed somewhere, it is better to avoid burdening most users who will never need it, and put it in supporting documentation. |
| Help users to recognise, diagnose, and recover from errors | Error messages are expressed in users' language. They precisely indicate the problem and suggest a solution. | Unclear error messages lead to an additional documentation burden. First, the message must be explained, and then the solution to the problem must be presented. |
| Help and documentation | Help should be easy to search, focused on user tasks, and not be too large. | The more the software conforms to standards, the less will be the requirement for explanations. |
With a new software release in 2004, McAfee had 90% fewer calls to their support desk than they had expected (www.softwareceo.com/com070604.php). This was because they focused on users' perspectives and designed the user interface accordingly.
Resources
This article was written with much help from Chris Rourke of User Vision Ltd (www.uservision.co.uk). Please contact him for professional advice on how you can improve the usability of your software.
Serco Usability Services (www.usability.serco.com) provides usability testing and consultancy. The focus is on new media technologies such as web sites, interactive TV and mobile Internet. There is an extensive research section on the site.
Foviance (www.foviance.com) provides usability testing and consultancy. The site has a resources section from which you can download research, white papers, reports and articles.
Extreme Programming (www.extremeprogramming.org) is a user-centred approach to software design.
See also 
Usability, testing and documentation
RSS feed