Recognising self-explanatory software

Nobody reads the manual

Suppose a company introduces a new piece of software. The vendor supplies a thick manual, and HR books two days of training. What happens next is something usability research has been observing since the 1980s: staff simply start using it. In 1987, John Carroll and Mary Beth Rosson called this the paradox of the active user. Learning the basics would save time in the long run, but users want to get a task done, not attend a course.

Jakob Nielsen, one of the best-known usability researchers, summed up three decades of observations in 2013: users do not read manuals, they do not explore the interface, and they stick with the first route that works. Learning is work, and nobody wants to do it voluntarily. When Microsoft Office 2007 was redesigned, the features users asked for most were ones that had existed for years and that they had never found.

The modern form of the manual does not help much either. The Nielsen Norman Group, a research and consulting firm specialising in usability, has tested introductory tutorials and pop-up hints shown on first launch. Users dismiss them quickly, because they cannot process instructions and the application at the same time, and they forget the hints within about 20 seconds.

What self-explanatory software means

The international standard on the design of interactive systems, ISO 9241-110, sets out seven principles. One of them is self-descriptiveness: at any point, users can tell where they are in the programme, which actions are available and how to carry them out. Alongside it are principles such as conformity with user expectations, learnability and robustness against user errors. The standard asks the interface to do what a manual otherwise explains after the fact.

In 1994, Nielsen published ten rules of thumb for interfaces that still hold today, unchanged. The tenth says, in essence: it is best if the system needs no additional explanation. Documentation may exist, but it comes last on the list, behind feedback, consistency, error prevention and recognition rather than recall.

Don Norman coined an image for this: the door with the sign saying “Push”. A door with a flat plate on one side and a handle on the other needs no sign. If one is stuck on, the design has failed. Unlabelled icons and buttons that do not look like buttons are the software equivalent of doors without handles, and the explanatory tooltip is the sign.

Consistency saves learning

The fourth rule of thumb is consistency: users should not have to wonder whether different words, situations or actions mean the same thing. Internally, this means the same thing always works the same way within the product, like the ribbon in Word, Excel and PowerPoint. Externally, it means the programme follows conventions users know from other programmes, such as the magnifying glass for search or the shopping trolley in an online shop.

Behind this sits Jakob's Law: users spend most of their time in other applications and bring those expectations with them. If there is nothing new to learn, they can concentrate fully on the task. Software that puts the same button in a different place on every page creates exactly the need for learning that the manual is later supposed to absorb.

Feedback and recognition

The first rule of thumb requires the system to keep users informed about what is going on. A button that changes when clicked, a progress bar, a confirmation after saving. Without feedback, users do not know whether the action registered and repeat it just to be safe. Missing information means missing control, as the Nielsen Norman Group puts it. An instruction advising users to wait after clicking is a substitute for a loading bar.

The sixth rule is recognition rather than recall. It comes from the psychology of memory: recognising something is easier than retrieving it without cues. Menus are the classic example. They show the available commands instead of requiring them to be memorised, as a command line does. If users have to keep codes, abbreviations or paths in their heads, the manual is doing the interface's job.

Preventing errors instead of explaining them

The fifth rule: better than a good error message is not allowing the error in the first place. Researchers distinguish between slips and mistakes. Slips happen when someone does something other than what they intended, for instance on autopilot. Constraints that rule out nonsense help here: a return flight cannot be booked before the outbound flight, a phone number is formatted as it is typed, sensible default values are pre-filled. Anyone who puts “Delete” right next to “Save” has made it too easy for users to get it wrong, and bears the blame themselves, as the researchers put it.

Mistakes arise when users have a false picture of how the programme works and act on it. A preview before consequential actions, an undo button and warnings at the right moment catch these. A manual explaining what you must never click on, by contrast, describes a trap instead of defusing it.

What learning effort costs

For companies, this is a question of cost. With internal software, Nielsen writes, usability is a matter of staff productivity: time employees spend searching or puzzling over difficult instructions is paid for without any work being produced. His rule of thumb: double the usability and you halve the training budget and double the transactions per hour.

In intranet studies by the Nielsen Norman Group, employees at 14 companies worked through 16 typical tasks. At the worst 25 per cent of intranets, the working time involved cost around 3,000 dollars per employee per year; at the best 25 per cent, around 1,600 dollars. The figures are old and American, but the mechanism is the same: every minute of searching, looking things up and asking around is incurred by every employee, every day.

That does not make help superfluous. The Nielsen Norman Group recommends short hints exactly where users need them, rather than a tutorial up front. Complex specialist applications need several attempts anyway: with backup software for administrators, task completion times only levelled off after four runs. The warning sign is a different one. If training is the only way to find the basic functions, it is standing in for design the vendor has failed to deliver. Whether an employee with no prior knowledge can complete the first typical task during the demonstration says more than the manual.

Conclusion

You can tell self-explanatory software by the fact that it works without instructions: it follows familiar conventions, reports back what is happening, shows options instead of asking users to recall them, and does not allow errors in the first place. These are not matters of taste, but rules of thumb documented since 1994 and principles of an international standard.

A thick manual and a fixed training budget are therefore a warning sign: nobody reads the manual anyway, and the training pays for time that a better interface would never have cost in the first place.