Get hands-on practice in all the key areas of UX and prepare for the BCS Foundation Certificate.
Reading user instructions continues to rank high on people’s lists of ‘activities-to-be-avoided-at-all-possible-costs’. We’ve worked with a number of clients to improve their user support materials and we frequently encounter five common mistakes made by development teams. This work has given us some insight into how best to avoid these problems occurring in the first place.
‘Help!’ cried John, Paul, George and Ringo, in a moment of despair (even going so far as to spell it out in semaphore on an album cover). Yes, they needed somebody, and not just anybody. When they were younger (so much younger than today) they never needed anybody's help in any way. But now those days are gone, and we live in a world where complicated products are accompanied by spectacularly awful user instructions — so now they are not feeling so self-assured.
I know the feeling. My heart always sinks if I have to read a user manual. I know I’m in for a bumpy ride.
What’s your experience with user instructions? If you’re like most people, you read instructions only as a last resort, or maybe never. “We just want to take things out of the box, turn them on and see them leap into action without having to read anything,” admits Rory Cellan-Jones, BBC’s technology correspondent. He’s not alone — in a survey of 75,000 technology users, conducted by Gadget Helpline, 64% of men and 24% of women admitted that they did not read instructions before phoning support.
As it turns out, it’s not true that people don’t want to read instructions. As Kathy Sierra has pointed out, they just don’t want to read yours. Paradoxically, users seem quite happy to turn for help to third-party technical support manuals. From ‘Guides for Dummies’ to ‘Missing Manuals’, there are shelf-loads of them in every bookstore. And increasingly people are turning to user-generated content, blogs and online discussions for support with the latest application or device. ‘RTFM’ has been usurped by ‘just Google it’.
But why do user manuals and other support materials have such a bad reputation, and why are they often so useless? I’ve written previously about how to write better instructions but the real problems go deeper than issues of technical writing. And these problems are amazingly consistent. For example, I’ve sat through hundreds of hours of usability tests of help systems and carried out dozens of expert reviews of support materials on systems as wide ranging as medical devices, banking software, mobile phones, e-commerce sites, intranets and even large manufacturing systems. A handful of common mistakes occur time and time again.
Here are 5 guidelines for avoiding these mistakes:
In this article we’ll take a look at each of these mistakes and suggest ways to avoid making them.
But first a note about terminology: user instructions and help systems come in a range of formats. So in addition to the traditional user or operator manuals (aka user guides) or instruction sheets, we can include installation guides, video instructions, interactive demonstrations, online instructions, built-in help systems, quick-start reference cards, pop-up user tips, trouble-shooting guides, FAQs, instructions printed on packaging, training materials, and support-center crib sheets. Because the format is not the issue here, in this article I’m going to take a lead from the Fab Four and refer to any and all of the aforementioned simply as Help!
At the risk of stating the obvious, the main reason for creating ‘Help!’ is to help the end-user to get things done, to help them learn the system, to help them get past tricky obstacles and to help them build confidence.
It’s about helping the user. The clue’s in the name.
Rather like a safety net, a lifeboat, or an insurance policy, people would prefer not to use ‘Help!’ but when it’s needed it must do its job effectively and efficiently, be accessible and easy to understand. The last thing anyone wants when grappling with a frustrating interface is a set of instructions that makes things worse, or instructions that need other instructions to explain them. I once usability tested a system that had eleven ‘Help!’ resources, some of them propping up the application and some of them propping up each other.
In spite of this self-evident fact, most ‘Help!’ projects I’ve consulted on turned out not to be focused on the goal of improving the users’ experience. The clients who commissioned me said this was the goal but when we got down to brass tacks the real problem the teams were trying to solve was how to reduce the costs of the support materials. The real problems were more like: ‘How can we redesign the materials without using color?’ ‘How can we put these instructions online?’ And most frequently: ‘How can we reduce the page count?’
Similarly, I’ve also encountered ‘Help!’ that is really a litany of obligatory cautions and warnings, or a place to dump stuff previously overlooked — a last minute attempt to write the product out of trouble.
When I’m reviewing a client’s ‘Help!’ system, I often find that the product or system itself has never undergone any kind of usability testing. This sets off alarm bells.
How can you give your users help if you don’t know where they struggle?
You can’t, of course. That’s why the default approach is to instruct the user on everything — every step of every function and every feature — and to assign everything equal weight. It is as though the writers are telling the user: “Look, we’ve designed a really complicated product here. Frankly, you’re not going to be able to figure it out on your own so you’re going to need all the help you can get.”
This often happens when the writing team doesn’t know the system interface well enough to know what to focus on. So they play safe and cover everything.
This ‘throw everything at them’ approach is akin to a cavalry charge: really impressive to look at but disastrously ineffective at accomplishing anything. It typically results in an overwhelming ‘Help!’ system that is difficult to navigate, with the really important things lost in the noise. The net outcome tends to be ‘Help!’ that ironically makes things worse and creates a negative first impression. Needless to say, it also increases development time and costs.
‘Help!’ should be commensurate with the ease of use of the user interface. A well designed user interface that has had most of its usability problems fixed will require only minimal ‘Help!’ — witness the Apple iPhone which comes with no ‘Help!’ at all. It also means that you can make a much more encouraging first impression: “This is a such an easy product to use we’ve given you a simple user guide just to cover one or two potentially tricky actions”.
Another reason why many writing teams are hesitant to leave anything out is because they don’t know the typical user’s skill level. Many document writers have never met a real end user, and have never seen people using the product or application for which they’re writing support.
This is rarely the fault of the technical writers — often the product design team has never met a real user either. Many development teams know the user only through high level demographic data handed down by marketing. But knowing someone’s age, gender, household income, and number of kids tells you nothing about their comfort level with technology, their domain knowledge or their experience with similar products. Are your readers going to be total novices, intermediates or experts?
Knowing your audience is mission critical for a writer. But a default approach I often see can be characterized as: ‘Play safe. Assume everyone using the product will be clueless. Cover all the bases. More is better than less.’ As a result, you’ll often see ‘Help!’ that gives step-by-step instructions on how to plug a battery charger into a wall socket, or describes every step in a sequence required to access a menu of options — only to describe exactly the same steps all over again for every option in the menu.
Even more frustrating is ‘Help!’ with a split personality. It explains easy operations in excessive detail but then glosses over advanced operations, as though the user has suddenly morphed from a dunce to an MIT computer scientist. This misses the mark in both cases. When I’ve come across this on client projects I sometimes discover that the reason the advanced operations were poorly described is because the writers themselves didn’t understand these functions — and made up for the lack of content by expounding at great length on the more basic features. Other times, it’s often a sign that ‘Help!’ was written before the complex elements were actually finished.
Understanding the skill level of your user is critical because it helps you prioritize instructions. It tells you what to spend more time on or what to explain using a different technique. It also gives you the confidence to know what to leave out. For example, anyone who uses a mobile phone every day does not need half-a-page of painstaking instructions explaining how to adjust the volume on an application.
Most ‘Help!’ tends to describe the product’s features. This is a mistake. Typically, the user is not thinking about your product or system at the level of features: they are trying to accomplish a task, and tasks usually consist of actions strung together like beads on a string. Think why someone has turned to support and you quickly realize that ‘Help!’ should focus on helping users achieve their goals. This means structuring ‘Help!’ around the main user journeys or red routes.
When you don’t structure ‘Help!’ around red routes, functions and features tend to get presented piecemeal and out of sync. Users then need to pogo-stick around the ‘Help!’ materials to solve their problem.
Just as it’s important for the design team to know the red routes, its essential for the technical writers to know them too so that ‘Help!’ instructions can form a coherent end-to-end flow through the task.
In over 20 years of consulting, I’ve only ever once attended a product development meeting with a technical writer present. I’ve had meetings with technical writers separately from design teams, usually in some other building, or even in another city, and often just prior to product launch, but only once in an actual core team meeting.
One reason for this, of course, is that many companies, especially smaller ones, don’t have dedicated technical writers and have chosen not to employ people who are experts in creating effective user documentation, instead assigning the job to a software programmer, an engineer, a designer — or even to an intern.
There are lots of reasons why it is a good idea to hire expert writers, but the most important one is that the people creating ‘Help!’ must be able to see the system through the eyes of the end user. It’s true that a software programmer or an engineer may well understand the system far better than a technical writer — but that’s often a handicap, not an asset.
It gets worse. I’ve also met technical writers who have never actually used the product they are writing about — even some who haven’t even seen the product. These poor souls have to work by changing a few instructions in documents from an earlier release. I think this is a bit like a blind date where you only ever communicate with your partner by text message. This scenario defies logic and common sense.
First and foremost, technical writers are problem solvers, and they should be an integral part of the core design team from the outset. If you don’t have a technical writer you need to hire one and put the product in his or her hands. Introduce your technical writers to your user experience and user interface designers so that they can work closely together. And insist that they attend design meetings. The person who writes your ‘Help!’ needs to be part of the design team’s thinking and decision making, not someone you bring in late in the game to rehash old user guides.
So… What can The Beatles teach us about writing support material?
It turns out The Beatles weren’t really signaling ‘Help!’ on their eponymous album cover. I was lying. What they were signaling was that well known phrase, ‘NUJV’. It turns out that the semaphore arm positions for ‘Help!’ didn’t look aesthetically pleasing to the photographer so he rearranged them to form a nonsense phrase.
Don’t make the same mistake. Create useful ‘Help!’, not useless nonsense.
Dr. Philip Hodgson (@bpusability on Twitter) has been a UX researcher for over 25 years. His work has influenced design for the US, European and Asian markets, for everything from banking software and medical devices to store displays, packaging and even baby care products. His book, Think Like a UX Researcher, was published in January 2019.
Gain hands-on practice in all the key areas of UX while you prepare for the BCS Foundation Certificate in User Experience. More details
Our most recent videos
Our most recent articles
copyright © Userfocus 2021.
Get hands-on practice in all the key areas of UX and prepare for the BCS Foundation Certificate.
We can tailor our user research and design courses to address the specific issues facing your development team.
Users don't always know what they want and their opinions can be unreliable — so we help you get behind your users' behaviour.