If No One Reads The Manual Then Why Bother

Writen by Ellis Pratt

Introduction

Joel Spolsky and Ron Jeffries argue in articles:

Users don't read the manual, so why bother

Their argument

Joel says the reasons for this are

"They actually don't have the manual

Users are trying to get something done, and they see reading the manual as a waste of time, or at the very least, as a distraction that keeps them from getting their task done.

In fact, users don't read anything."

And he argues

"You probably have no choice but to design your software so that it does not need a manual in the first place.

The only exception I can think of is if your users do not have any domain knowledge -- they don't really understand what the program is intended to do, but they know that they better learn."

Ron argues:

"Web apps don't come with manuals, and they're kicking butt. Some of them have a couple of help pages. Many have nothing but the instructions on the page and the flow of the buttons. "

They are right – and – wrong

People 'muddle through'

I would argue that

Users rarely read the paper manual, because in most cases they can "muddle through".

It has been assumed that everyone makes considered and rational decisions based on the evidence and risks in front of them. This is based largely on research into how fire fighters and similar professionals make decisions.

But most people are not in a similar environment to fire fighters. They don't need to assess all the options and risks. In other words, they don't need to sit down and read through the manual: they can muddle through.

In life, we can get things done even if we do things imperfectly. We can still record TV programmes even if we can't use the timer: we can just stick in a 6-hour tape and start recording. This means we are unlikely to use user assistance to work out the optimal way of doing something. But:

When things go wrong and it matters to the user, they will seek assistance.

They will look for the easiest way to get to the information they need to do the task. If this is the manual, then they will use it.

At that moment, they have a strong emotional view of your product or service. They become one of your most important customers because they soon might become an ex-customer.

There are lots of people without "domain knowledge"

The rise of individualism and increasing specialisation in the workplace means that few people even in the same broad field have a full understanding of what others are doing.

The "Windows for Dummies" books, which are manuals for a specific type of audience, are phenomenally successful because there are many people that need this type of information.

Web applications are NOT kicking butt

Let's take e commerce applications as an example. How can they be kicking butt when a high percentage of all sales transactions are not completed (source Accenture)?

Sometimes, people do stupid and dangerous things

So you need to warn people, in detail, about what they are doing.

You may not be able to make software simple enough for people to use it without assistance

According to "Complicated Lives: Sophisticated consumers, intricate lifestyles, simple solutions" by Willmott and Nelson, new products often suffer from "Feature overload". They are designed with so many extras that they are rendered almost impossible to use.

Life is not getting simpler, and we need all the help we can get.

Conclusion

If users never or rarely use the manual, then it is wrong to say "don't bother".

When things go wrong and it matters to the user, they will seek assistance. They will look for the easiest way to get to the information they need to do the task. If this is the manual, then they will use it.

Life is not getting simpler, and we do need all the help we can get.

The challenge is to:

Make it easy for users to access information when they need it.

Provide different ways to "access" information to suit different types of users.

So maybe we need something better than the traditional paper manual. It might mean a new type of manual - online or embedded into the application. We should look to provide something better, rather than provide nothing at all.

(c) Cherryleaf Technical Authors and Documentation Specialists 2006.

Ellis Pratt co-owns a technical writing consultancy called Cherryleaf Ltd. We work with developers of software who are afraid of losing their customers and frustrated with the cost of supporting them. See Cherryleaf Technical Authors and Documentation Specialists.