RTFM: Why People Don’t “R” Your “FM”

7 Tips to get people to read your manuals, guides, and policies

If you work in IT or have manned a support desk, you have probably muttered – or at least thought to yourself – RTFM. If you’re someone who has called a helpdesk as your first step to solving a problem, without looking for the policy or procedure on your own, you may have been asked (politely or otherwise), “Did you try RTFM?”

RTFM = Read The F*cking Manual. It’s the “bless your heart” of support people. It conveys the gospel of policy and manual makers everywhere: support helps those who help themselves (or at least try to).

This article is meant for every software tech writer, HR policy creator, operations documentation expert, MBA-totin’ manager, or franchise support team who thinks just because you wrote it, someone (anyone) will read it (or even find it, or know that it exists).

RTFM = Read The F*cking Manual. It’s the “bless your heart” of support people.

No One Cares Like You Do

People read a manual, policy, or guide at one of two times in their daily routines: when the policy, process, or products are new to them (they’ve just started in a new position, for example), and when they’re stuck and need an answer (reference for a little-used policy, process, or product).

In the first case – new to the job, or a new product introduced to an existing job – you have a chance to introduce your material to someone who will never remember what they read. They’re drinking from a firehose, information overload. They might have the enthusiasm to read it – it’s all so new to me! – but there’s little chance it will stick (the training that accompanies it might stick, but not the words in the manual).

Under this scenario, they will either:

• never need this information again, their memories discarding it in favor of stuff that they do need, or
• need it again in the distant future, meaning they’ll have to be able to find it.

Which puts them into the second case – someone needs information in order to do their job or solve a problem, and they need it in a hurry.

Not knowing where to find information or, just as commonly, not even knowing the answers have been written down somewhere are two huge reasons people don’t read your manuals. You care about those topics FAR more than they do at any given time.

So while you can say, “Just go to intranet>policies>HR>code%20of%20conduct>marketing_department>2018>Employee-policies>pto%20for%20all%20new%20hires-updated-FINAL.pdf.”

…That isn’t going to cut it. Help them help you. 

A good system will:

1. Consider the users’ needs first – when will they access it (new, or in a hurry?), what information are they looking for (full context, or just the answer they need?). Make it reference-able.
2. Be “findable”. You may work in this every day, but some information is just a small sliver of what users need during the course of theirs. Make it searchable.

Not knowing where to find information or, just as commonly, not even knowing the answers have been written down somewhere are two huge reasons people don’t read your manuals.

You’re Not Preaching to the Choir

A close cousin to No One Cares Like You Do is not fully understanding your audience. Tell me what I need to know so I can get on with my day.

If I need to quickly set up a new sub-domain for a marketing campaign, a 15-page document telling me all about DNS entries and SEO ramifications is not nearly as important as giving me the name of the department which handles such requests. Not only does that stuff not matter to a marketing intern, they might not even be able to spell DNS, let alone understand the intricacies of ANAME and CNAME records.

Again, consider your audience. In a large company where roles are broken down, your job is not to educate the end-user – who is executing a one-time need to set up a subdomain – on how to be an expert. And in a small company, any documentation would be accompanied by training (so you need both – full documentation and reference material, one doc for each use).

Not knowing your audience is like me giving you a Calculus textbook and saying, “Read that, let me know if you have any questions.” If you’re not even familiar with the building blocks, no amount of reading will get you there.

A good system will:

1. Create content for different users – different uses, different backgrounds. Technical vs. Business. Beginner vs. Advanced. You need more than one version.
2. Write efficiently – this is not the time to break out the Thesaurus, or bestow your flowery prose upon the world. Get to the point. Tell the best way to solve a problem without pontificating on all the ways to solve a problem.

Not knowing your audience is like me giving you a Calculus textbook and saying, “Read that, let me know if you have any questions.”

Buried in Obscurity

It’s on the intranet.
Have you checked the wiki?
Have you read the readme.txt?
Check Slack. If it’s not there, try Sharepoint. But the latest version might be on Confluence. 

The good thing about unlimited cloud storage is that it’s unlimited – you can keep adding forever, and storage is cheap. The bad thing is that it becomes the world’s largest storage shed, a place where things go in, never to be heard from again.

This is important. Collaborative directories very often simply take one person’s messy folder structure and make it available to everyone. Worse, they democratize information creation – where every expert can write their own Great American Manual – leaving users to wander through a forest of bad information architecture, looking for a needle in not one, but multiple haystacks.

One way around the interminably deep directory structures of Sharepoint and others is to make everything flat. That is, no directory structure. All topics floating together in a sea of content. The only way to find anything is via search. Smart, eh?

No. This is a fallacy that comes up, mainly, in large companies and ones where they feel like “everyone has a voice, something important to say.” The problem? When everyone can create content, when it’s all flat, and when the only way to get to it is by search, users are now in a world where a search for “how to create a subdomain” presents them with more than 1,000 search results, ranging from a blog post of someone telling their story to the DNS admin procedures for setting one up.

Collaborative directories very often simply take one person’s messy folder structure and make it available to everyone.

You get every doc ever created by any role at any time in the company. A product manager might have to look through hundreds of technical specs from 8 years ago. It’s not likely that an RFP to build a new data facility in Australia from six years ago will be helpful to someone running a marketing campaign on Instagram, but here we are – wading through a historical deluge of mentions of the word “subdomains.”

Information can be hidden in plain sight just as well as buried deep within the bowels of a company’s archives.

Just because you wrote it doesn’t mean people know where to find it, or that it even exists at all. Search engines don’t always handle PDFs well, and even if they did, a 55-page PDF that has the answer buried on page 27 is a frustrating way to find a quick answer.

A good system will:

1. Break info into its smallest parts. Topic-based authoring makes topics separate, severable, and useful.
2. Make search simple. Plain text – HTML – is much easier to search and will deliver better results.
3. Govern the categories of topics by audience. Technical people need technical specs, marketing people need summaries.
4. Govern creation of new topics. New documents are welcome. Your particular spin on an old topic may be counter productive.

You’ve Lost Credibility

I hate to be the one to break this to you, you being the subject matter expert and all, but it’s possible you’ve lost the trust of your readers. 

If your version of “How to request a subdomain” contains seven bullet points and ends with “Contact Network Planning for details” is different than another document – from 4 years ago, but still available on Sharepoint – the user now has two experts giving conflicting details about how to accomplish a task. Takeaway from the user: the intranet isn’t up to date. I’ll just call someone.

One section of Company Holiday Calendar mentions PTO for merit employees is six days per year, which conflicts with “12 days, after the first twelve months of employment” in another document. Which is different than Company Holiday Schedule (which is the old name of Holiday Calendar, but is still available on the shared drive). 

If your documentation doesn’t answer questions authoritatively, but rather raises more questions (or worse, causes someone to file a grievance with their boss), then your documentation has not only been a waste of time and money, it’s also made things worse for the people it was supposed to support.

A good system will:

1. Be authoritative. One author, one voice.
2. Be fresh. All content put on a review cycle, with a designated owner.
3. Be discrete. What are you even doing, putting specific PTO policies into the text of three, 4, or 8 different documents? Are you trying to make things difficult?

Solution = Process + Technology

For years, keepers of policy have looked for a better way to make their documents more accessible. And for years the answer has been more technology: file sharing systems, PDFs (they’re electronic!) instead of print, wikis, collaboration software, etc.

All were supposed to solve the problem, but here we are: a tangled mess that confuses users and frustrates authors. “Why doesn’t anyone RTFM?!”

Technology is good. Search is good. Visibility is good. But without proper process – that of creating and managing content – technology just makes bad content worse by calling attention to it. Users are no closer to getting the right information at the right time than they were when we were still sending out Word files by email.

7 Tips to Encourage People to “R” Your “FM”:

1. Plan your architecture first. Deciding things like what you name and tag certain things (subdomain, or tertiary? dress code, or uniform policy?) and defining the authoritative platform will decrease confusion.
2. Get a good technical writer. Audience and objective, writing to their level of knowledge, and naming and search best practices make the documents you create more useful and more likely to be read.
3. Author governance. Not everyone should have a voice, but your manual should have a cohesive one. Those who do should go through an editorial person to make sure the content is well written, useful, and in a common tone and voice.
4. New topic governance. It’s easy to overlap topics, especially as you create more manuals, guides, or playbooks for specific audiences. Do you write a new topic, or modify an existing one? Are they for the same audience, or different takes for different users?
5. Key indicators. Search results should tell you up front if you are reading an old manual or topic instead of checking the date on one you’ve clicked through to. Who is the author, who can you ask if something doesn’t seem right?
6. Regular audits. Every manual and playbook should be reviewed at least yearly, but some topics need more frequent review (healthcare provider info, for example). But also: should this document even exist anymore? Old information is rampant on file sharing services. Version control – in print and electronically – is critical to credibility and findability.
7. Robust search. If your internal search produces thousands of results, your garden is probably overgrown. Just as bad, if it produces results that you don’t think fit (“subdomain” is listed in passing on page 187 of a PDF about Data Center Disaster Recovery), you need a system good enough to present the right information to the right people at the right time.

Advertising and marketing copy are getting shorter because “no one reads anymore.” And yet, companies everywhere document their procedures, policies, and guidelines in manuals and playbooks as if their readers eagerly anticipate the next volume, a page turner to be enjoyed by a fire with a glass of wine.

If teams are not reading your information, if they call first and read second, then you need to consider the root cause. It might be with how you wrote things in the first place.