Tactic - "Let your readers be the guide"

Let’s go on an adventure into another world. This world is not entirely different to our own, but it might have some unexpected treasures - and pitfalls - to find. It’s an adventure into the mind of your reader. They live in our world, but they don’t always think like we do. And learning to think like a reader can be tricky!

If you want to try the interactive "Choose Your Own Adventure" version of this guide, visit the Interactive Information Architecture Guide.

Have you ever been really good at something, and tried to show someone else how to do it? It’s frustrating when they just don’t seem to get it, even though it seems easy to you. Science tells us that the more you know about a topic, the less you are able to imagine what it’s like to not know it. The technical name for this is the Curse of Knowledge, and it can make writing documentation hard.

Writers combat the Curse of Knowledge by putting themselves in the shoes of the reader. And while this guide won’t teach you to be a professional technical writer, it will definitely help you think about your reader, so that you can write better documentation.

Let’s dive into the world of the reader …​

When you’re excited about a new project, it’s super-tempting to just start writing the docs without thinking too hard about it.

DON’T DO THIS!

This guide is designed to get you thinking about your readers in such a way that you’ll end up knowing what docs you need to write. It won’t take very long for you to get through it, and it will save you time in the long run.

When you’re done, you should have a good idea of who your main readers are, the kinds of things they are using your docs for, and what kinds of docs they might be expecting. This will help you know which templates to use from the Good Docs Project, and give you the basics to start completing them.

If you want to do this using the interactive tool, go here instead: Interactive IA Guide. The interactive version is the same as this static version, so you can use this version to check back on later on if you need to.

The first thing to do is think about what you’re writing about.

Are you writing about something pretty simple, that people can use without having any experience? Like a toaster?

Or are you writing about something a bit complicated, that people can start to use only after they’ve done a bit of reading, and might need to ask some questions as they go along? More like a car?

Or are you writing about something really tricky? Something that requires training, a whole lot of background knowledge, and possibly a friend to help them the whole way? Like a nuclear reactor?

Curse of Knowledge alert!!

Now that you know what you’re writing about, consider who you’re writing for. Remember that people come in all shapes and sizes, so let’s think up three different people, to try and make sure we’re covering all the options.

The way you categorize your three readers is up to you, but sometimes the best way to start is by thinking of a beginner, an intermediate reader, and an expert. Or, depending on the kind of product you have, you might think of an ordinary user, a system administrator, and a support person.

Your three readers should probably be interested in different parts of your product. They will be trying to do different tasks, and they will need different levels of help from your docs. Don’t be afraid to let them overlap a little bit, but try and make sure you’ve covered most of the options.

Let’s take a closer look at our readers, and work out why they read the docs.

I’m going to tell you a secret:

No one curls up at night with a warm drink and a great technical manual.

If that’s the case, why do people read docs? Generally speaking, it’s because they want to achieve something.

To put that in less abstract terms, you need to work out what problem your reader is trying to solve. If Dusty wants to put their degree up on the wall, they might want to consult some documentation about how to do it. The documentation Dusty needs to do this would probably not be called "How to Choose a Drill". The documentation Dusty needs is "How to Hang a Picture".

This is an important distinction, because if you get it wrong, your readers won’t know if the content is right for them or, worse, they won’t find your content at all.

So let’s think about what our readers are trying to achieve.

For each of your readers, start by thinking about how they might begin. What is the very first thing they might want to do? Let’s assume that they manage to complete that without any trouble. What would be the second thing that they would want to do? And now that they’ve managed to complete that what is the next thing?

When you’ve got tasks for all of your readers, let’s put it all together.

Now that you know who your readers are, and the kinds of things they might be using your documentation for, you can display them in a table like this:

Now you just need to fill in the blank spaces. Consider how likely the reader is to use the documentation to complete each task. Score a 1 for a low likelihood, 2 for a medium likelihood, and 3 for a high likelihood.

Curse of Knowledge alert!!

When you have the numbers in, add up each row. The rows that score the highest are what writers like to call critical paths. The items with the highest critical path score is the content that is most important for you to write.

It’s time to turn our attention to what you already have. If you have already made a start on the docs, that’s great! But even if you think you’re starting from scratch, there’s a reasonable chance you actually already have something.

Have a think about it:

Get all of these things together and look at them with your critical paths in mind. Do you have content here that fits all those critical paths?

You will probably start to notice the gaps pretty quickly. It could be that you have a whole lot of content that describes how to do it, but not a lot that explains what it is. Or, you could have a lot of stuff aimed at beginners, and not a lot that works for experts. Sometimes, you might find that you have a lot of descriptions of things, but not a lot of step-by-step instructions.

Have a think about each of your critical paths, and identify what content you need to fulfil each one.

At this stage, it’s normal to be feeling a little overwhelmed. Now you can work out what you actually need, so you can cut some things from the list.

If you wanted to build a house, you wouldn’t start laying bricks until you’d had a think about what kind of house you want to build. How big is it going to be? What materials are you going to use? What layout and design is it going to have?

You also need to think about what you intend for your documentation. Is it going to be comprehensive and detailed, or simple and sparse? Is it going to use simple language, designed for people who have never done this before, or more technical language, for people who know what they’re doing and just need the basics? Is it going to start from the very beginning, or are you going to assume that your readers already have some knowledge?

By now, you should have a good idea of what your ideal documentation looks like. It will be a shining beacon of docs goodness, hitting all the critical paths for all your readers, and people will talk about it for years to come!

It’s a grim reality that project documentation needs to be maintained. Have a think about how many writers your project might be able to access. Are you likely to have writers on the project over time? What skill level are they likely to have? Is there any content that already exists elsewhere that you can point to, rather than writing it yourself? Is there any way you can automate any part of the documentation, such as using code comments to generate API documentation?

Now is when you really get to start making decisions. You’ve thought about your readers, and the kinds of things they might want to do. You’ve thought about the kind of content you already have, and what’s missing. Then you faced reality and realized that you might not be able to create perfect docs, but you can certainly improve what you already have.

So, which docs are you going to write?

Now you get to decide how to move forward.

Don’t let your docs project be like your New Year resolutions, forgotten and lonely by the end of the year. The best way to make sure you stick to your docs goals, is to work out how much you can do, and set a deadline for each step in the process.

The templates will help you understand how much work is involved in each of the docs you want to write. Have a read through the information for each template you want to use, and work out how much time you are going to need to work on it.

Then you can split up docs work like this:

So, if you want to write a How To, and you have five months to do it, you can work out how much time to spend on each task like this:

Three months = Around 100 working days, not counting weekends, and allowing for a few holidays. You can adjust this however you like, if you’re only working on weekends, for example, or if you have other projects to work on as well.

There’s just one more thing to do.

The most important thing you need to do is to be flexible. Things don’t always work out, and that’s OK!

Perhaps you get a new job and end up with no time to work on things. If you’ve written down your plan, and spoken to others in your project about what you were going to do, others can pick up the work, and when you’re able to, you can come back to it.

Perhaps you get an injection of cash and can hire some writers. Go back to the critical paths, expand your scope, and hand that planning to them, so that they have somewhere to start, and understand your vision for the docs.

Or maybe things just don’t work out, and the project ends up being abandoned entirely. That’s sad, but it’s OK. At least you’ve finished up with some valuable knowledge, so you’ll be even better for your next idea.

So, are you ready to get started?

Go check out the templates!

This document was largely based on the brilliant book by Abby Covert called How to Make Sense of Any Mess. It’s a quick read, and it doesn’t just apply to technical documentation, you can use the principles in that book to help you organize anything at all.

If you want to delve further into information architecture for technical documentation, the most important text you need is the O’Reilly book Information Architecture. It has everything you need to know, including answers to questions you didn’t know you needed to ask. It has a polar bear on the cover.

You’ve reached the end of the static Information Architecture Guide. If you’re ready to get started, go check out the templates.