RTFM! Users Won’t Read Your Documentation, Here’s A Better Approach

Reading Time: 3 mins

It’s easy to be optimistic when writing detailed documentation for your product. You want to make sure there’s a wealth of knowledge in your user manual anyone can search for and find.

The sad reality is that nobody reads the user guides.

Instead of putting all your effort into perfect user guides, you should reduce the need for a user to refer to the documentation in the first place.

Here’s the why and the how:

The Pros Of Documentation:

Online documentation is easily searchable.
When organized right, it’s easy to find what you’re looking for.
Something like Apple’s HIG is a fascinating resource to learn from.

The Cons Of Documentation:

It takes you away from using the product.
The act of searching for a solution to your problem is too much friction for most users.
If a user can’t solve their problem they’ll leave your product and find another one.

How To Reduce Dependency On Documentation:

Promote Learning By Doing

Users prefer to start using something without reading the manual. This is referred to as the paradox of the active user.

To work around this, you should break up a long sequence of actions required to complete a task into smaller chunks.

By doing this, users won’t have to wait until they’ve completed their task to see the expected results.

Allow for errors

Users will make mistakes when using your product so it’s important to account for this in your design.

Use clear error messages written in plain language, that state the problem, and offer a solution. I wrote about how to write effective error messages in this article: UI Design Patterns - How To Write Effective Error Messages.

Provide ways for the user to skip ahead or step back easily. Make sure to include things like a back, forward, and home button to allow the user to navigate through your product.

If the user has trouble completing their current task, they’ll often go back to the start and try again.

Even better than good error messages is a careful design that prevents a problem from occurring in the first place.

Take the time to test your product before releasing it to a wider audience. There will always be some use case or scenario you hadn’t accounted for in your initial designs.

Add context to actions and components

Use in-context learning cues like tooltips on buttons or other components.

These can contain a helpful hint for carrying out a task or describing what a feature does.

Be careful when using tooltips that they don’t act as a replacement for your user guides.

I often see tooltips crammed with paragraphs of text describing in great detail how a feature works. This is not how tooltips were designed to be used.

I recommend reading this article from NNGroup.com to learn how to use tooltips correctly: Tooltip Guidelines

Reduce visual clutter

To avoid overloading the user, reduce any visual clutter or information that isn’t necessary from the interface.

More components on the screen means more visual load for the user to try and process.

Too much load and the user can’t effectively process what’s on the screen which means they won’t be able to find what they’re looking for.

A great way to overcome visual clutter is with progressive disclosure. This is where you show relevant info to the user only when they need it.

A good example is when you’re filling out a form. A well-designed form is broken up into several steps with each step only containing the most relevant information.

Include documentation if it’s needed

A link to your documentation is still important in case the user needs it.

This information should be easily accessible and structured in a logical way with the ability to search.

Documentation does matter but it shouldn’t be at the expense of a well-designed and highly usable product.

RTFM! Users Won't Read Your Documentation, Here's A Better Approach