Why Google Docs Falls Short for Internal Documentation

Teams have dozens of options to choose from for their internal documentation. They often choose the wrong tool to get the job done.

There are tools like Slab, designed explicitly for team documentation. And there are tools like Google Docs, Dropbox Paper and Quip designed primarily for word processing.

Many teams initially gravitate toward these more general purpose document editors for logical reasons:

• These editors are familiar to most people, meaning they can be easier to adopt across an organization
• Most companies already use (and pay for) at least one of these tools
• Teams realize the need for documentation, but aren’t thinking of how their documentation tool will scale alongside their business

But over time, most teams find the issues associated with these tools outweigh their benefits — particularly as these teams scale. These limitations (like poor organization and unreliable search capabilities) frustrate users and slow down productivity. As a result, most internal documentation tools becomes stale, underused, and irrelevant.

Using a tool specifically designed for internal documentation can help. And while not every team needs a dedicated tool for documentation, every team should know the limitations they’ll experience by using document editors like Google Docs, Dropbox Paper, and Quip.

These limitations exist because document editors prioritize personal writing and editing over team reading. In other words, document editors work great for writing blog posts and school essays. They become problematic when multiple teams across a company contribute to and search for shared knowledge.

Below we break down the issues teams inevitably face when they use document editors like Google Docs, Dropbox Paper, and Quip for their internal wiki.

Lack of context

Document editors use a standard folder concept to store and organize content. These folders work fine for someone working alone or in a small group.

But when a growing number of team members contribute more content to your wiki, the lack of context associated with the standard folder structure gets confusing.

Take a look at the image below as an example:

Besides the name of the folder itself, there’s nothing telling team members what type of content belongs there. Teammates make assumptions — or spend time parsing through the folder contents — to get the context they need.

This wastes time and frustrates teammates. And still, without context, there is no surefire way of knowing what type of content belongs in a folder. As a result, it’s not uncommon for teammates to save documents in the wrong place, or unknowingly create a duplicate version of a document they never found.

No clear owner

Once a teammate opens a document, they have no idea who to connect with to ask a question or suggest a change. If an engineer needs clarification in a code-review document, who do they reach out to? Document editors don’t provide that kind of context.

As a result, teammates hesitate to ask for clarification or suggest changes. This stifles collaboration and compromises the accuracy of team wikis.

Duplicated posts

A standard folder structure is also restricting. Not everyone on a team agrees on exactly how and where documents should be stored. Team members conform to an existing structure that may not align with their preferred method of organization.

To get around this, many people duplicate Google docs, for example, and save these duplicates on their own Google Drive space, outside the confines of the team wiki. Yes, this gives these individuals more control over the structure of their documents — but it destroys the intention of your team wiki, which is to be the single source of information for your company.

Now, compare this to the topic structure we use at Slab.

Descriptions

Teams can add a description for each Slab Topic (much like Slack channel descriptions) explaining the purpose of the topic. For example, our team has a topic called Blog. The description for this topic is Discuss new content before it’s published to the official slab blog.

Teams can also pin posts inside Topics, and arrange these pinned posts however they want. Inside our Blog topic, we’ve pinned the essential posts team members should read — and arranged these posts in the order that team members should read them in.

Post Maintainers

Every Slab post has a designated maintainer. Everyone who visits a Slab post can see who is responsible for that post, as well as anyone who has contributed to it. This makes it easy for team members to know who to ask for clarification or follow-up.

Post Maintainers and team members who have contributed to a post are notified of any changes made to that post. This ensures the content of your knowledge base remains accurate.

Customized organization

Slab Topics work like labels. You can assign as many topics as you want to a post.

For example, a Slab Post documenting your postmortem process can be assigned to topics including Engineering, Marketing, Product, and Operations (since each of these departments likely use or reference postmortems).

Going even further, individual teammates can add this document to other topics or subtopics. For example, Jim in Sales can add this postmortem doc to a topic he created for himself, known as “Jim’s Critical Docs.”

Adding a Slab Post to one topic doesn’t remove it from another. That is often not the case with folder structures used by conventional document editors.

Too many formatting options

Being able to align text, change the background color, and move images anywhere across a page are nice features to have. But they’re detrimental to the documentation process.

Humans are easily distracted. If your teammates have the option to format their documents, they will. In fact, they’ll likely spend more time formatting their document than they will focused on the quality of the content.

But distraction isn’t the only issue — excessive formatting options create disorder inside your wiki.

Teams rely on internal documentation to help them make critical decisions fast. A new member of your team should be able to look at any document across your knowledge base and identify the essential information, without stumbling over formatting.

That’s why dedicated documentation tools include only the most essential formatting options, including:

• Headers
• Blockquotes
• Bold/Italicize
• Linking

Anything else is distracting and disorienting.

Search is just a second thought

When you first create a team wiki, search capabilities may not be at the top of your needs. The organizational structure you put into place can handle the few documents you’ve created.

However, as your company grows and more people contribute to your knowledge base, you can no longer rely on this approach. Even if teammates know what folder to go to, that folder may contain dozens of documents. Parsing through these documents to find the right one not only eats up valuable time — it also frustrates your team.

The more frustrated your team is with your wiki, the less likely they’ll use it.

That’s why with Slab teams can search for content using keywords, rather than hunting around different folders.

Plus, we realize critical information lives outside a team’s knowledge base. Slack, for example, is home to some of your team’s most important conversations. Slab Search integrates with tools like Slack, Dropbox, and Google Drive — so teams can easily search for content across all their tools from one dedicated space.

We built Slab’s search function to be fast and scalable while populating results with the most relevant answers, based on how you and your teammates consume your content. This depth of search-result prioritization filters out the noise and helps team members find what they want — fast. In the end, your team will view your knowledge base as a valuable tool rather than just another app.

Make decisions for the long-term

A considerably large number of teams that switch to Slab do so after initially using a document editor tool like Google Docs. Over time, they grow frustrated with the shortcomings of their existing tool.

Fortunately, we make migrating to Slab simple. However, teams can struggle to adapt to another tool when they’ve already adapted software into their workflow.

When searching for a solution for your internal wiki, consider where your team will be one year from now. Will multiple teams contribute to your knowledge base? Will you add new team members who’ll need access to a variety of procedural documents?

If you answered yes, then a document editor is likely not your ideal choice for documentation.