userName: ' '
--
# Information Architecture
**[[Let's Start->Intro]]**config.footer.left: "▰▱▱▱▱▱▱▱▱▱ 6%"
--
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!
{embed image: 'https://tgdp-assets.imgix.net/ia-guide/reader_world.png', alt: 'A blue and green globe sitting on top of a book with a red cover'}
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.
This guide is interactive, just click the option you like the most to move on.
Just follow the prompts, and let us guide you into ...
the world of the reader ...
**[[Continue->Before you begin]]**
{back link, label: 'Or go back a step'}userName: 'Type your name here'
config.footer.left: "▰▱▱▱▱▱▱▱ 12%"
--
## Don't start yet!
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.
{embed image: 'https://tgdp-assets.imgix.net/ia-guide/stuck.png', alt: 'A smiling person wearing a blue outfit is in a very big hole, with the words "i am stuck" in red'}
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 don't want to do this using the interactive tool, [[click here->https://thegooddocsproject.dev/ia-guide/]] to go to the static text instead.
[[check out the templates->https://gitlab.com/tgdp/templates/-/blob/main/README.md]]
When you're ready, tell me your name:
{text input for: 'userName'}
and we can [[get started->What are you writing about]]
{back link, label: 'Or go back a step'}config.footer.left: "▰▱▱▱▱▱ 18%"
--
Hi {userName}! I'm so glad you decided to join me!
{embed image: 'https://tgdp-assets.imgix.net/ia-guide/hello_peeps.png', alt: 'A smiling person with their arms in the air, and text reading "Hello my dear peeps".'}
## What are you writing about?
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?
> [[Toaster->Writing about a toaster]]
> [[Car->Writing about a car]]
> [[Nuclear Reactor->Writing about a nuclear reactor]]
{back link, label: 'Or go back a step'}config.footer.left: "▰▰▱▱▱▱▱▱ 25%"
--
## Writing about a toaster
Because the thing you are writing about is pretty simple and straightforward, you might think that you don't need much documentation.
Just because you might not need a lot of docs, you will still need something, and working that out could be tricky.
You're going to need to think a little bit harder about who you're writing for.
{embed image: 'https://tgdp-assets.imgix.net/ia-guide/tooster.png', alt: 'A silver toaster marked "Super Tooster" with a red discount star, and a sign saying "wowzars!!!"'}
**Curse of Knowledge alert!!**
Just because your toaster seems super simple to you, doesn't mean everyone will find it as easy as you do.
What if your reader doesn't speak the same language, or is a new migrant from a place with a totally different culture?
What if they are nine years old?
Or 99 years old?
What if they have a physical or mental disability?
When you are thinking about your readers, make sure you are thinking about everyone, not just people like you.
Now, let's [[move on->Who are you writing for?]]
{back link, label: 'Or go back a step'}config.footer.left: "▰▰▱▱▱▱▱▱ 25%"
--
## Writing about a car
There is a pretty good chance that you needed to learn how to do this thing yourself, and hopefully it wasn't all that long ago, and you can fairly easily cast your mind back to those days when you didn't know what this thing was, or how it worked.
And hopefully there is also someone nearby who has had to learn as well, so go ask them questions!
{embed image: 'https://tgdp-assets.imgix.net/ia-guide/car.png', alt: 'A cheering person in a green outfit driving a red and white striped sports car, with the caption "big red car"'}
**Curse of Knowledge alert!!**
Try to remember that not everyone knows the same stuff, or learns in the same way.
What if your reader doesn't speak the same language, or is a new migrant from a place with a totally different culture?
What if they are nine years old?
Or 99 years old?
What if they have a physical or mental disability?
When you are thinking about your readers, make sure you are thinking about everyone, not just people like you.
Now, let's [[move on->Who are you writing for?]]
{back link, label: 'Or go back a step'}config.footer.left: "▰▰▱▱▱▱▱▱ 25%"
--
## Writing about a nuclear reactor
The first thing to work out if you are writing about a nuclear reactor is what reasonable assumptions can you make?
There's a fair chance that you can assume at least some kind of prior knowledge: a degree, some relevant experience, or perhaps using some other related tools or software.
Put these things right up front in your docs, so your readers can go away and learn something else first if they need to.
And be prepared to be challenged: you might discover in time that your assumptions are incorrect, and if that happens, you'll need to revisit your docs, too.
**Curse of Knowledge alert!!**
Try to remember that not everyone knows the same stuff, or learns in the same way.
What if your reader doesn't speak the same language, or is a new migrant from a place with a totally different culture?
What if they are nine years old?
Or 99 years old?
What if they have a physical or mental disability?
When you are thinking about your readers, make sure you are thinking about everyone, not just people like you.
Now, let's [[move on->Who are you writing for?]]
{back link, label: 'Or go back a step'}readerName1: 'Alex'
readerName2: 'Bobbi'
readerName3: 'Charlie'
config.footer.left: "▰▰▰▱▱▱▱▱▱▱ 30%"
--
## Who are you writing for?
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.
{embed image: 'https://tgdp-assets.imgix.net/ia-guide/wave.png', alt: 'A winking smiling person wearing a purple shirt and pants, with pastel coloured hair, waving'}
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.
To get started with understanding your readers, you should probably give them names.
What would you like to call your first reader?
{text input for: 'readerName1'}
What would you like to call your second reader?
{text input for: 'readerName2'}
What would you like to call your third reader?
{text input for: 'readerName3'}
Let's take a closer look at our readers, and work out [[Why do they read the docs?]]
{back link, label: 'Or go back a step'}config.footer.left: "▰▰▰▱▱▱▱▱▱ 36%"
--
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.
Which one would you like to start with?
> [[{readerName1}->Reader One]]
> [[{readerName2}->Reader Two]]
> [[{readerName3}->Reader Three]]
When you've got tasks for all of your readers, let's put it all together, and think about [[Writing for your readers->Writing for your readers]]
{back link, label: 'Or go back a step'}reader1action1: 'Install the product'
reader1action2: 'Perform initial setup'
reader1action3: 'Start their first project'
config.footer.left: "▰▰▰▰▱▱▱▱▱▱ 42%"
--
To understand {readerName1}, let's start by thinking about how they might begin.
What is the very first thing that {readerName1} might want to do?
{text input for: 'reader1action1'}
Now let's assume that {readerName1} manages to complete {reader1action1} without any trouble.
What would be the second thing that they would want to do?
{text input for: 'reader1action2'}
And now that they've managed to complete {reader1action2} what is the next thing?
{text input for: 'reader1action3'}
{embed image: 'https://tgdp-assets.imgix.net/ia-guide/dog.png', alt: 'A happy red and orange dog sitting up.'}
Great! Now you have the three main things that a reader like {readerName1} might want to do, [[go back->Why do they read the docs?]] and do the same for {readerName2} and {readerName3}.
Or, if you're done, move on to [[Writing for your readers->Writing for your readers]]reader2action1: 'Configure multiple users'
reader2action2: 'Troubleshoot networking problems'
reader2action3: 'Upgrade to a new version'
config.footer.left: "▰▰▰▰▰▱▱▱▱▱ 48%"
--
To understand {readerName2}, let's start by thinking about how they might begin.
What is the very first thing that {readerName2} might want to do?
{text input for: 'reader2action1'}
Now let's assume that {readerName2} manages to complete {reader2action1} without any trouble.
What would be the second thing that they would want to do?
{text input for: 'reader2action2'}
And now that they've managed to complete {reader2action2} what is the next thing?
{text input for: 'reader2action3'}
{embed image: 'https://tgdp-assets.imgix.net/ia-guide/platypus.png', alt: 'A happy platypus with brown fur and yellow bill and feet.'}
Great! Now you have the three main things that a reader like {readerName2} might want to do, [[go back->Why do they read the docs?]] and do the same for {readerName3} and {readerName1}.
Or, if you're done, move on to [[Writing for your readers->Writing for your readers]]reader3action1: 'Understand all the advanced features'
reader3action2: 'Switch from hosted services to local'
reader3action3: 'Shut down the reactor quickly during a meltdown'
config.footer.left: "▰▰▰▰▰▱▱▱▱▱ 54%"
--
To understand {readerName3}, let's start by thinking about how they might begin.
What is the very first thing that {readerName3} might want to do?
{text input for: 'reader3action1'}
Now let's assume that {readerName3} manages to complete {reader3action1} without any trouble.
What would be the second thing that they would want to do?
{text input for: 'reader3action2'}
And now that they've managed to complete {reader3action2} what is the next thing?
{text input for: 'reader3action3'}
{embed image: 'https://tgdp-assets.imgix.net/ia-guide/unirat.png', alt: 'A brown rat with white wings and a colorful unicorn horn.'}
Great! Now you have the three main things that a reader like {readerName3} might want to do, [[go back->Why do they read the docs?]] and do the same for {readerName2} and {readerName1}.
Or, if you're done, move on to [[Writing for your readers->Writing for your readers]]critpath1: ''
critpath2: ''
critpath3: ''
critpath4: ''
critpath5: ''
critpath6: ''
critpath7: ''
critpath8: ''
critpath9: ''
critpath10: ''
critpath11: ''
critpath12: ''
critpath13: ''
critpath14: ''
critpath15: ''
critpath16: ''
critpath17: ''
critpath18: ''
critpath19: ''
critpath20: ''
critpath21: ''
critpath22: ''
critpath23: ''
critpath24: ''
critpath25: ''
critpath26: ''
critpath27: ''
critscore1: ''
critscore2: ''
critscore3: ''
critscore4: ''
critscore5: ''
critscore6: ''
critscore7: ''
critscore8: ''
critscore9: ''
config.footer.left: "▰▰▰▰▰▰▱▱▱▱ 60% "
--
## Writing for your readers
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:
<table>
<tr>
<th>Task</th>
<th>{readerName1}</th>
<th>{readerName2}</th>
<th>{readerName3}</th>
<th>Critical Path Score</th>
</tr>
<tr>
<td>{reader1action1}</td>
<td>{dropdown menu for: 'critpath1', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critpath2', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critpath3', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critscore1', choices: ['', '3 (Very low)', '4 (Low)', '5 (Medium)', '6 (Moderate)', '7 (High)', '8 (Very High)', '9 (Super High)']}</td>
</tr>
<tr>
<td>{reader1action2}</td>
<td>{dropdown menu for: 'critpath4', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critpath5', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critpath6', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critscore2', choices: ['', '3 (Very low)', '4 (Low)', '5 (Medium)', '6 (Moderate)', '7 (High)', '8 (Very High)', '9 (Super High)']}</td>
</tr>
<tr>
<td>{reader1action3}</td>
<td>{dropdown menu for: 'critpath7', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critpath8', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critpath9', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critscore3', choices: ['', '3 (Very low)', '4 (Low)', '5 (Medium)', '6 (Moderate)', '7 (High)', '8 (Very High)', '9 (Super High)']}</td>
</tr>
<tr>
<td>{reader2action1}</td>
<td>{dropdown menu for: 'critpath10', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critpath11', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critpath12', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critscore4', choices: ['', '3 (Very low)', '4 (Low)', '5 (Medium)', '6 (Moderate)', '7 (High)', '8 (Very High)', '9 (Super High)']}</td>
</tr>
<tr>
<td>{reader2action2}</td>
<td>{dropdown menu for: 'critpath13', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critpath14', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critpath15', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critscore5', choices: ['', '3 (Very low)', '4 (Low)', '5 (Medium)', '6 (Moderate)', '7 (High)', '8 (Very High)', '9 (Super High)']}</td>
</tr>
<tr>
<td>{reader2action3}</td>
<td>{dropdown menu for: 'critpath16', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critpath17', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critpath18', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critscore6', choices: ['', '3 (Very low)', '4 (Low)', '5 (Medium)', '6 (Moderate)', '7 (High)', '8 (Very High)', '9 (Super High)']}</td>
</tr>
<tr>
<td>{reader3action1}</td>
<td>{dropdown menu for: 'critpath19', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critpath20', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critpath21', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critscore7', choices: ['', '3 (Very low)', '4 (Low)', '5 (Medium)', '6 (Moderate)', '7 (High)', '8 (Very High)', '9 (Super High)']}</td>
</tr>
<tr>
<td>{reader3action2}</td>
<td>{dropdown menu for: 'critpath22', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critpath23', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critpath24', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critscore8', choices: ['', '3 (Very low)', '4 (Low)', '5 (Medium)', '6 (Moderate)', '7 (High)', '8 (Very High)', '9 (Super High)']}</td>
</tr>
<tr>
<td>{reader3action3}</td>
<td>{dropdown menu for: 'critpath25', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critpath26', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critpath27', choices: ['', '1 (Low)', '2 (Medium)', '3 (High)']}</td>
<td>{dropdown menu for: 'critscore9', choices: ['', '3 (Very low)', '4 (Low)', '5 (Medium)', '6 (Moderate)', '7 (High)', '8 (Very High)', '9 (Super High)']}</td>
</tr>
</table>
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!!**
Remember that this isn't how likely the reader is to do the task.
It's how likely the reader is to *use the documentation* to do the task.
A really experienced reader is not likely to need to the documentation for tasks like installation or setup, but they might need it for more advanced tasks.
When you have the numbers in, add up each row.
The rows that score the highest are what writers like to call *critical paths*.
Now you know what your critical paths are, you are ready to [[Identify the mess]]
{back link, label: 'Or go back a step'}missingcontent1: 'Installation Guide'
missingcontent2: 'Initial setup procedure'
missingcontent3: 'Quick Start Guide'
missingcontent4: 'Users Guide'
missingcontent5: 'Troubleshooting Guide'
missingcontent6: 'Upgrade Guide'
missingcontent7: 'Tuning Guide'
missingcontent8: 'Administration Guide'
missingcontent9: 'Reference Guide'
config.footer.left: "▰▰▰▰▰▱▱▱ 66%"
--
## Identify the mess
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:
* Have you written notes while you've been working?
Even if they're just scratches on a notebook on your desk, that's documentation!
* Have you written any comments in your code?
You really should have! They're documentation, too.
* Have you put a README in your code repository?
That's also documentation!
* Have you given any talks or presentations about your project?
Even if there isn't a recording, any notes or slides you made is documentation too!
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.
## What's missing?
Have a think about each of your critical paths, and identify what content you need to fulfil each one:
* {reader1action1} - {critscore1}: {text input for: 'missingcontent1', required: false}
* {reader1action2} - {critscore2}: {text input for: 'missingcontent2', required: false}
* {reader1action3} - {critscore3}: {text input for: 'missingcontent3', required: false}
* {reader2action1} - {critscore4}: {text input for: 'missingcontent4', required: false}
* {reader2action2} - {critscore5}: {text input for: 'missingcontent5', required: false}
* {reader2action3} - {critscore6}: {text input for: 'missingcontent6', required: false}
* {reader3action1} - {critscore7}: {text input for: 'missingcontent7', required: false}
* {reader3action2} - {critscore8}: {text input for: 'missingcontent8', required: false}
* {reader3action3} - {critscore9}: {text input for: 'missingcontent9', required: false}
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.
To do this, you need to [[State your intent->State your intent]]
{back link, label: 'Or go back a step'}config.footer.left: "▰▰▰▰▰▰▰▱▱▱ 71%"
--
## State your intent
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?
When you've considered these things, and determined the kind of documentation you want to make sure your project has, you're just about ready to [[Face reality->Face reality]]
{back link, label: 'Or go back a step'}config.footer.left: "▰▰▰▰▰▰▰▱▱ 78%"
--
## Face reality
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?
Make sure you're not biting off more than you can chew, and [[Choose a direction->Choose a direction]]
{back link, label: 'Or go back a step'}missingcontent10: 'Anything else?'
config.footer.left: "▰▰▰▰▰▰▰▰▱▱ 83%"
--
## Choose a direction
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?
Delete anything from this list that doesn't make the cut.
* {missingcontent1}
* {missingcontent2}
* {missingcontent3}
* {missingcontent4}
* {missingcontent5}
* {missingcontent6}
* {missingcontent7}
* {missingcontent8}
* {missingcontent9}
* {text input for: 'missingcontent10', required: false}
Now you get to decide how to move forward.
That starts with [[Measuring the distance->Measure the distance]]
{back link, label: 'Or go back a step'}config.footer.left: "▰▰▰▰▰▰▰▰▰▱ 90%"
--
## Measure the distance
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:
* Planning - 20%
* Drafting - 50%
* Reviewing and editing - 20%
* Production - 10%
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.
* Planning - 20 days (4 weeks)
* Drafting - 50 days (10 weeks)
* Review & edit - 20 days (4 weeks)
* Production - 10 days (2 weeks)
There's just one more thing to do: [[Prepare to adjust->Prepare to adjust]]
{back link, label: 'Or go back a step'}config.footer.left: "▰▰▰▰▰▰▰▰▰▱ 99%"
--
## Prepare to adjust
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?
Here's what you want to work on (take a note of these now!):
* {missingcontent1}
* {missingcontent2}
* {missingcontent3}
* {missingcontent4}
* {missingcontent5}
* {missingcontent6}
* {missingcontent7}
* {missingcontent8}
* {missingcontent9}
* {missingcontent10}
And now go [[check out the templates->https://gitlab.com/tgdp/templates/-/blob/main/README.md]]!
Or, if you want to keep reading, you can [[Find out more about information architecture->Further reading]]
{back link, label: 'Or go back a step'}config.footer.left: "▰▰▰▰▰▰▰▰▰▰ 100%"
--
## Further Reading
This document was largely based on the brilliant book by Abby Covert called [[How to Make Sense of Any Mess->http://www.howtomakesenseofanymess.com/]].
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->https://www.oreilly.com/library/view/information-architecture-4th/9781491913529/]].
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.
{embed image: 'https://tgdp-assets.imgix.net/ia-guide/banana.png', alt: 'A reclining smiling banana with red writing saying "lets go banana"'}
## That's it!
You've reached the end of the interactive Information Architecture Guide.
If you're ready to get started, go [[check out the templates->https://gitlab.com/tgdp/templates/-/blob/main/README.md]]
If you want to refer back to this guide later on, visit the [[static version->https://thegooddocsproject.dev/ia-guide/]].
Or, if you want to go back and check something, you can {back link, label: 'go back a step'}, or {restart link, label: 'restart from the beginning'}.