Documentation

  |  
37 Min Read

How to create a documentation system: Start with a personal system

Congratulations on starting your business process documentation! 👏👏👏

Sometimes starting can be the hardest part of any big project or new behavior, and documentation is really a habit or behavior.

Now the next hardest part is… continuing the habit!

In order to help convince other people to use or be involved in documentation, you’ll want to have a proven documentation system for yourself first. You’re the beta tester to make sure this system works before adding other people into the system.


There are a few reasons why I recommend setting up your personal documentation system first.

So when you add other people into the system, they: 

  • Have someone to model the behavior and expectations on
  • Can trust that the documentation is up-to-date and useful
  • Can see proven benefits for using it – after seeing you use it 

 

Elements of a documentation system in this blog:

 

If you'd rather learn this material in a live course format, this blog content is from my documentation systems workshop and the full documentation course. Many of these topics are also included in this guide to documentation.

 

Top 5 tips for creating a process documentation system:


What is a system?

So let’s back up for a minute and talk about what I mean by 'system.'

A lot of readers may be in the tech industry and immediately think about software as the system...

What I mean by system is similar to the Oxford Dictionary's definition: 

  • a set of things working together as parts of a mechanism or an interconnecting network.
  • a set of principles or procedures according to which something is done; an organized framework or method.
A system of documentation is not one specific tool, such as Google Docs, Guru, or Notion. 

It's the people and processes working together, and then finding the right tools to help connect the parts of the system.

If you skip all this people & process system work and go straight into choosing a tool and expecting the tool to work miracles all by itself, that is likely to fail. I don’t want you to fail!

Yes, it would be nice if a magic bullet tool did 100% of this work for you. One where you just buy it, and now there is a whole knowledge base of documentation that is automatically updated all the time...but we’re working with human behavior, so it's not realistic to think a tool can solve all the problems.

The major elements of a documentation system to set up BEFORE choosing a documentation storage tool are:

  • Time management
  • Project management
  • Communication
Let's dive in.

 

Documentation time and task management

You'll want to first set up a system to help you avoid procrastination since documentation is rarely urgent, though it’s an ongoing activity that is important for its long-term benefits.

Time management

Start creating your systems by reserving time – making time to create, use, and improve documentation.

Think about:

  • What are some of the current ways you reserve time to work on other types of…never-ending…work?
  • How do you remind yourself to do these tasks or work on a regular basis?
When I say never-ending and ongoing work that is because documentation is not a set-it-and-forget-it, one-time project. Think of it as living documentation, which is constantly evolving.

A few ways you could reserve time for this work:

  • Calendar blocking – with email or popup notification reminders
  • Project management recurring tasks – with email, Slack, or other type of notification

Having a system of reminders is very important. Don't just have this task sitting on your calendar or in your project management system, but think about how it is going to get in front of you to remind you to do it.
Some kind of popup or time-delayed notification could work well.

Task management

So you’ve got the time reserved, and you have reminders to actually spend that time doing the work, yay!

But when you arrive at that time on that day…you’re overwhelmed and don’t know what documentation tasks to work on. 

You spend that whole time block trying to figure out what to do first.

Does that sound familiar?

 

To solve that problem:

  • Add the specific details of what you are going to work on into your time blocks or tasks for documentation
  • Add details to at least one recurrence at a time, if not a month or more at a time

A good example of being specific with tasks/time block:

“Complete the drafted document about creating a marketing email.” 

(Add a link so you’re not searching for the draft.)

 

A bad example of a time block or task name:

“Documentation” – unless it links to your list of what to do next


Interlinking everything is a big part of creating a good system.

Make it easy to find what you need to work on, and spend less time searching around in all your tools.

 

Common roadblocks

Here is some advice on overcoming common roadblocks:

  • Add in reminders such as adding documentation links into any project management task lists/templates you use repeatedly
  • Remind yourself WHY you are doing this work, your larger goal of creating documentation
  • Remind yourself that other people will see you doing or not doing this work, because of the communication processes you'll set up, which can also hold you accountable

 

Additional documentation project management

In the first session of my course, class members finish a top ten list of documentation to create or improve.
That will guide the documentation project management to prioritize what to work on first.

 But what happens when you’ve completed the first version for all the documents on your initial to-do list?

When you get to that point, here are three project management tactics I suggest using in your documentation system:

  1. Current tasks for building and/or improving documentation
    • This is your top priority work to do
    • Ideally, the smaller edits happen in real time when you notice a change needs to be made to a document. This reserved current task time is for larger improvements and additions to your documentation.
  2. Wishlist
    • This is a list of “nice to have” documentation for the future
    • This could be brand-new documentation or large improvements to existing documentation
    • These are not top-priority tasks right now
      • In my last role, my definition of 'future' was 3 months. If you don’t think it needs to happen, or realistically can happen, within the next 3 months, put it on the wishlist so it doesn’t distract you from priority work.
    • A wishlist also 'documents' all your ideas and notes in one place for the future, so you don't forget them
    • It makes other people feel seen and heard by capturing their ideas because they can see it on the wishlist and know that you didn’t dismiss their idea
    • Make this list easy to find but don’t put it somewhere it will distract you. A separate document outside your project management system, or using a separate part of your project management system, may be a good choice.
  3. Quarterly review & updates 
    • Set aside time to go through whole categories of documentation, to perform maintenance and improvement 
      • Complete any necessary edits that were not made in real-time
      • Identify larger improvements, make tasks for those to complete later after your full category review (such as any edits that would take more than a few minutes, or new documents needed)
      • Make sure everything is standardized
    • These reviews should be set up as recurring tasks in your project management system
    • You’ll need clear instructions for how to complete a quarterly review (documented)
    • At this point, you'll also need clear categories of documents, and to know who is or will be responsible for each category (explained in the next blog about expanding your system to other people)

Every person and/or every company does project management differently, so think about how best to make these tactics work for you.

 

Documentation communication tools and habits

After you have your personal documentation project/time management system set up, and you’re feeling confident you’ll actually keep doing the new and updating documentation, then it’s time to start getting into the habit of good communication about documentation.

This also is a start of your change management, getting people used to seeing you talk about documentation before you ask them to be involved in it.

Eventually, you’ll have many interlinking methods of communicating about new or improved documentation.

But start small.

Pick one channel to start this communication while you’re building your own documentation system. Examples of channels could be a messaging system, a recurring email, or adding it into a live meeting that already occurs.

Test it and see what people respond to. Then expand.

 

What do I mean by communicating about documentation?

When you're focusing on your personal system, think about documentation communication as informing other people about what you are doing. The only action they may need to take is to read what you are sharing.

Here is an example:

 “The marketing email process document (link it) was updated with a new approval process. Marketing team members should review it and reply to me with questions.” 

Which could be added to:

  • A Slack channel JUST for questions or updates about processes, templates, and documents.
    • Make the information seem important by having its own channel
    • Having its own channel also makes the information less likely to be lost in the noise of Slack
    • A benefit of using Slack or another messaging tool is you can tell people, “Add a checkmark emoji if you have read the document”
  • A regular item about documents/processes in a weekly internal newsletter
  • A recurring section of a team meeting agenda

These were the three channels I used at my last job, but I didn’t start using them all at once, 

Choose one channel to start with.

Then one channel will always be the source of truth that you’ll use to pull/copy and paste the information to put onto the other channels.

After testing one communication channel and getting into the communication habit, when you start involving more people in your system, it will be very important to repeat the information/communication in several places.

So if we're using the three channels that were on the last slide, we'd be using Slack in real time to first send the communication, then copying that information into a newsletter, and into a meeting agenda.

It’s not realistic for people to remember something they were told once in one format. 

Announcing that you finished a piece of documentation one time is not going to help people remember it exists.

There is a rule of 7 in marketing which explains that people need to hear or see things 7 times to start to remember them. Seven is a lot, but three times can be manageable for each piece of documentation news.

This is also important since not everyone on your team is going to pay the most attention to the same channel or the same method of communication - verbal, written, etc.

It may be annoying for you, as the announcer, to repeat yourself. But eventually, other people will be doing the documentation communicating, too. You may not be the one doing all the communicating yourself forever.

But remember -- Poor communication about documentation is a big reason why people don’t use it. They simply don’t remember it exists.

 

Documentation Storage & Organization Tools & Habits

This tool topic was probably what many of you were waiting for, because this is the 'system' most people think about when they see a mention of a documentation system.

But remember that the tool will not be very useful without doing the people & process work to make it useful – such as setting up your time accountability & communication methods!


So once you’ve figured out when to do it, what to do, how to communication about it...

Now where are you going to put the documentation? What tool will you use?

 

In that first stage of creating your version 1.0 documentation, use the tool easiest for you.

The habit is more important than the tool, especially in the early stages. 

Though you can hire someone later to migrate your documentation from one system to another, or delegate that task to someone on your team later on, it is very difficult to hire someone to write your processes for you. I would be very hard for someone to extract that information from your brain. 

Write version 1 first.

Don't spend weeks researching documentation tools when it's a better use of time to spend those weeks completing your version 1.0 of documentation in whatever tool is easiest for you, a tool you have now. Though tool research can be much more fun (and distracting) than doing the documentation! 😀

 

Once you're finished with your first version of writing your top-priority documentation, using the tool that was easiest for you to get started writing, then you will start to think about a tool easiest for your team to use. This may or may not be different than the tool you’re currently using for yourself.

My #1 tip is to use a tool your team is already using daily so you don't have to teach them a new tool IN ADDITION to teaching them new habits about creating, using, and updating documentation. 

 

This is my top tip because new tool adoption is hard, even when people are using one tool to replace another tool that does the same work (in a different way or different UI). For an example of replacing a tool to do the same work, in a Salesforce to HubSpot migration, your work isn’t fundamentally changing, but the way you do the work within the tool is changing.

So unlike simply migrating tools for your team's current work, documentation may be an entirely new area of work or new habit, especially for the people responsible for creating and editing it. 

Building new habits is hard.

It is extra difficult if you’re adding tool adoption on top of that new habit. 

We want to make documentation as easy as possible to get other people to use, create, and update it, so using a current tool is a great place to start creating those habits!

 

But what do I mean by a tool your team is already using? 

You may be thinking, "My team isn't using documentation, that’s why I am reading this blog!"

When thinking of what current tool to use, consider:

  • What is the team’s current “Home base” for their work? Where do they currently spend most of their day? 
    • Examples: 
      • Project management system 
      • Google Docs or other shared document drive
      • Slack, Microsoft Teams, other messaging tool
  • Can you use that tool for documentation, or can you integrate a documentation tool into it?
    • If your team is on Slack all day, for example, consider a tool like Notion or Guru that integrates with messaging

 

Choosing a documentation storage tool for knowledge management

Here are a few factors to consider, especially if you DO have to choose a new tool, 

Does the documentation tool have the ability to:

  • Have separate categories or folders so people can easily find what they need? 
    • These things will be very important for the second phase of creating a system, so you can clearly note which categories different people are responsible for. Ideally, the tool has at least 2 levels of folders, subfolders or subcategories, so you can break up the responsibility of documentation within each department, One level of categorization is better than zero!
  • Can the tool Interlink within the article (using anchors), link to other articles, link to external URLs, and use article links in other places? (Pasting a link to a document into an email or Slack message – is that possible?) 
  • Embed videos and graphics?
  • Viewing permissions and editing permissions for internal and external company users (this is more important with confidential info)? 
  • Measure the use of documentation - does the tool let you see who or how many people viewed it and for how long? 
  • Can you see who edited it last and when?  
  • Is there an archiving feature? 
    • Is there a native function that stores the file in an archive but removes it from use/view/search, or do you have to make a “hack” folder called 'Archive' to put older documents into, and rename them with 'Archive' in the naming convention? 
  • Do you need to purchase individual licenses to give people viewing or editing permissions? (Some tools could get expensive. if so)

Documentation storage tool examples

Here are a few tools you can look into when you’re ready. (Remember, this is not step 1 of building a system!)

Keep in mind that screenshots, videos, and other media may also need a file storage location & strategy.

 

A few more documentation storage tool tips:

Google Docs is an easy place to start documentation, but in order to have the individual documents not feel so lost and floaty, it requires setting up a good drive/folder navigation system and onboarding/training the team about using folder navigation instead of searching the whole drive in the search bar...and that takes work and habit building. 

You can also make it a practice to link those Google documents or folders into other places the team members would be looking first, like pinning them in Slack channels or linking them in a project management task template for a related task. 

Keep that bigger 'system"' thinking in mind, linking everything together so people can easily find it when they need it, in the place they are looking for it.

Eventually, you may want to consider Wiki tools like Notion, Guru, or another knowledge base, 

Knowledge bases are nice since you can refer to documentation as a 'wiki' which is easier and friendly language, and it may be easier to find information compared to using documents in a Drive, You'll also have more formatting choices and potential integrations with Slack or another 'home base' tool.

 

It’s time for you to take action!

Start documenting what you will use for your documentation system:

  • Time management
  • Task management
  • Communication
  • Storage

In my classes, I have a template that helps document these decisions, which you can also purchase separately in this documentation systems workbook if you wish.

 

Good luck in starting your documentation system!

Next: Learn how to add other people to your system.

Documentation system workshop

More resources:

Topics:   Documentation