How to get started writing your end user docs

So you’re running a company support team for a few products. You have a few FAQs on your website, but you’ve got to the stage where you need some quality, comprehensive documentation.

Or, maybe you don’t even have any products yet, but want want to be ahead of the game when it comes to documentation for your users.

We’ll walk you through everything you need to know to get started.

Define why you’re writing your documentation

Usually it’s to make your product easier for your customers to use, and answer any questions they may have. End user documentation is focused on helping your customers fulfil a task or get the most out of your product, whereas other technical documentation is aimed at providing comprehensive information about an application or tool.

Subscription software products often require robust user documentation. This is because your customers will be using it over time and have an ongoing relationship with you.

It will reduce the amount of times customers need to contact a human being for support. Good documentation should significantly reduce churn, the chance that your customers will leave you.

End user documentation can also be B2C (business to consumer) rather than exclusively B2B (business to business).

Define your audience

This article works on the assumption that you will be writing your own docs and not contributing to an open source project. You will need to know exactly who your audience is in order to write the best docs for them.

If you don’t know who they are, survey your customers until you have a clear picture of who is using your product. Find out their needs and pain points, so you can help solve them with your docs.

While software developers are also users, they are not typically the end users of most products. They are a special use case not covered here. Write the Docs have a fantastic introduction for writing software documentation.

Model your docs

There should be other products you know of that have really good documentation. A shortcut to writing good docs, without going through all the experience of learning how to do it yourself, is modelling yours against ones you admire.

You can analyze what you like about other people’s docs: their use of language, uses of imagery, naming conventions, tagging, layouts, natural language, emojis. Replicate what you like within your own docs to give yourself a good head start.

We’ve published an article about some of our favourite help docs out there. Screensteps have also published a post with 10 more great examples.

Plan a structure

Businesses often see their products from an operational perspective, and often name categories after team functions. For customers, who have no perspective on the inner workings of your company, this is meaningless.

You should create a model of your product as seen from the point of view of your customer. This includes the times in which they may need your product, what they want to use it for, and potential uses they may have.

Your customers will see your product only in terms of what they want to accomplish, which may even change over time. You have to use empathy and data to guide your customers through the ideal use of your product, on their terms.

Decide on an information architecture

Photo by Davide Cantelli on Unsplash

You will not be able to document everything and nor should you want to. You need to organize your information in such a way that enables your users to navigate successfully through your content.

This includes categorization and linking your articles together, but also content hierarchy. You should begin with top-level content that gradually changes into lower level content that covers more specific topics.

An example of top-level content could be ‘Optimizing your emails for better open rates’.

Lower-level content could be ‘What to do if your email address has been blacklisted’.

Work out the customer journey

If you’re writing your documentation for product users, you need to have a clear idea of your customer journey.

What are the touchpoints where customers are likely to come into contact with your documentation? How will they find it? Will it be easy to use and understand on mobile?

It’s likely that you will have many different customer journeys, and you’ll have to find a way to tie them all together.

You may send out your beginner documentation in an email onboarding sequence. When your customer first signs up, they will receive emails guiding them through correct set up, commonly asked questions, and information about how to get the most out of the product.

Over time, you may also segment your customers into beginner, intermediate and advanced users. You can then send them relevant documentation to upskill them in your product, and keep them getting value from it.

Photo by Nicolas Cool on Unsplash

Define your workflow

You will likely be producing documentation as a team and this requires coordination. Your documentation will require revision, editing and publishing, so there should usually be one gatekeeper that decides when content is ready.

Plan a strategy for communicating with subject matter experts (SMEs). For example, engineers if you are documenting the back end of the product. Perhaps create a template to help SMEs share their knowledge in a way that is most helpful to you.

You do not just create your docs one time and that’s it forever. You should also have a process for updating your docs when they are out of date. As your product evolves, so will your docs. Plan to regularly review your docs for content that is no longer needed or should be changed. You should also maintain an open dialogue with your customers, and encourage them to request updates for your docs.

If you have a lot of documentation and customers, perhaps invest in a ticketing system to help you keep track of requests for your docs.

Create a style guide

Each article in your user docs should follow a similar pattern to create an expectation for your user. This makes comprehending and digesting information easier.

For example, an average article length, length of paragraph, use of subheadings, images and technical terms should all be consistent.

Your documentation should not be corporate or austere, and you should try to write in a way that your audience will easily understand. You want to keep your content short and specific.

Make use of the active voice to keep your users engaged.

Decide on your software

People usually use dedicated software to host their knowledge bases, where they keep their documentation. If you use a customer support ticketing system, it may offer the functionality for your documentation, or you could opt for a dedicated solution.

Check out our guide on how to choose the best knowledge base software for your business needs.

Buying dedication knowledge base software is often cheaper if you don’t require the full functionality of a ticketing system. Or, you may already have a ticketing system you like that doesn’t offer a knowledge base. We reviewed a range of platforms in a previous article.

You can take our own knowledge base software, KnowledgeOwl, for a free spin today.