[Webinar] Docs-as-code without the complexity.→ Save your seat
<- Back to main blog

Mistakes to Avoid When Creating User Documentation

DocumentationUpdated: May 31, 2026
Dragos
Dragos
Founder, robot with feelings. From planet Aiur.

Discover the biggest mistakes to avoid when creating user documentation, along with tips and best practices to ensure effective communication.

Mistakes to Avoid When Creating User Documentation

User documentation comes in various shapes and sizes, but the best examples have one thing in common—they avoid the mistakes we discuss in this article.

When creating such an extensive and complex resource as user documentation, which so many people rely on for information, it’s easy to make an error here and there.

However, there are some major mistakes that can significantly impact the overall quality of your documentation.

Let’s dive right into the first of the most egregious mistakes you could make.

Not Making Documentation Easy to Find#

Most users will look for your documentation when they have a pressing need or problem to solve and need the information quickly.

That’s unsurprising, given that the main purpose of user documentation is to provide an accessible resource of knowledge about a product.

Therefore, users count on the documentation to fulfill that purpose.

So, how can you make access to the documentation as quick and straightforward as possible? Make it easy to find.

As Adam DuVander, a technical content specialist, sums it up, there’s no difference between a document you can’t find and one that doesn’t exist.

Illustration: Archbee / Data: EveryDeveloper

For example, if your users need to scroll up and down your website without any indication of where to find the documentation, that’s not ideal, to put it mildly.

That’s the case with the website of PCCW Global, a big information and communication technology company.

They provide a range of communication, voice, and data solutions, yet the "Resources" tab contains only brochures, case studies, and promotional videos.

Source: PCCW Global

However, although you can’t find it anywhere on their homepage, there is a user guide for PCCW Global.

You can find it with Google’s help.

Source: Google

But that’s not all.

There is a more comprehensive user documentation resource for one of their products, with guides, API documentation, and everything else you need to use the product successfully.

Source: Console Connect

Where is it? On the Console Connect website.

How can you find it? Only if you click around the PCCW Global website and encounter this pop-up notification.

Source: PCCW Global

Sure, Console Connect is also referenced on the PCCW Global homepage, but without any indication that services are moving there, as this notification informs you.

That can easily confuse a user who just wants to find the documentation about PCCW Global and its products.

There are no such resources on the homepage, but you could find some if you Googled them.

Also, there is much more documentation on a different website that you’re more likely to stumble upon than find on purpose.

A situation like that can frustrate users and waste their time.

If you want to keep your users happy, don’t make them search through multiple channels to find what they need.

Not Considering the Ease of Navigation#

Your users shouldn’t take long to find the information they need in your documentation.

Once you ensure your documentation is easy to find, you also want to provide ways to navigate it effortlessly.

One of them is a search function.

A simple search bar can save your users a lot of valuable time; if they want to find information, they only need to type in a few words, and a relevant document will appear on their screen.

Although the search feature in the documentation is already widely accepted, some companies still make the mistake of not including it.

For instance, Telegram, a popular messaging platform, provides detailed user documentation with useful information, both for beginners and the more technically-savvy users.

Source: Telegram

Above, you can see part of Telegram’s API documentation page.

However, no matter how long you focus on that screenshot, you won’t find one thing—a search bar.

There isn’t one on any other documentation pages either, like the FAQ for advanced users.

Source: Telegram

That means Telegram users need to read through the whole webpage to find what they need or use keyboard shortcuts to open a search box in their browser.

In other words, by not including the search bar in your documentation, you’re sending a message to your users that you haven’t created your docs with their convenience in mind.

In addition to the search function, the ease of navigation can be significantly improved by including a table of contents.

Let’s take a look at Basecamp’s user documentation page:

Source: Basecamp

When you land on it, you have everything you need for easy navigation—a search bar and links to every type of content created for users.

If you follow any of the links, it’s clear that easy navigation was among the Basecamp team’s priorities.

For instance, below, you can see the first page of the “Getting started” guide.

Source: Basecamp

On the left-hand side, there’s another search bar and a table of contents showing you which guide you’ve opened.

The main part of the page is essentially a detailed table of contents for this particular guide.

Those elements that make navigation in the documentation easier are essential for user documentation.

Jonathan DeVore, who works with teams that want to provide better customer experience, explains it like this:

Illustration: Archbee / Data: Screensteps

In other words, users want to read the specific pieces of information they need, not every word you and your team wrote.

Making navigation in your documentation easier will allow users to find what they need.

Assuming the Users’ Level of Knowledge#

Do you know who your users are?

Most likely, you can assume the profile of people most interested in your product, but do you know their backgrounds, knowledge levels, interests, and industries they work in?

The range of the users’ knowledge levels can be especially wide in the software industry.

Regardless of the type of software product and its use, the users can come from all kinds of different backgrounds.

Elizabeth Garcia, a product marketing manager at Pandium, points that out:

Illustration: Archbee / Data: Pandium

So, how can you create documentation that will be valuable for such a diverse user base?

The safest way to make your documentation as helpful as possible is to avoid assuming how knowledgeable your users are.

Even if you’ve done your research and know that most of your users are, for example, developers, you still shouldn’t assume what they know and what they don’t know.

For instance, some developers are fresh out of college, and some have 25 years of experience. Naturally, they don’t have the same level of expertise or skill sets.

That’s why you should make sure your documentation is easy to read, using plain language and avoiding technical jargon as much as possible.

Take a look at the part of Amazon Alexa’s Voice Service documentation below. It’s intended for developers, but you can read and understand it without issue even if you’re not one.

Source: Amazon

That’s because the writers started this documentation with a story, providing context instead of immediately jumping into technical details.

Developers can learn how their product can integrate with Alexa and think about some vital questions about their product’s design, interaction, and use.

All of that can help them integrate their product with Amazon’s successfully.

Avoiding technical jargon like in the example above is recommendable, but the reality is that it isn’t always possible.

When there’s a situation where you need to use technical terms, ensure that your users know their meaning.

You can do that with a glossary of important terms, like the one from Daraja, a developer portal of mobile network operator Safaricom.

Source: Safaricom

Providing a glossary of essential terms can ensure that your users can look up an explanation if they encounter something in your documentation that they’re not familiar with.

Keeping the language of your documentation simple and understandable while also providing explanations for technical terms is a great way to account for a wide range of your users’ levels of knowledge.

Neglecting to Include Visual Content#

Creating user documentation doesn’t necessarily mean only focusing on writing clear and concise information.

On the contrary, presenting your documentation only in the form of text is a mistake that can be detrimental to user experience.

Visuals are also a vital part of high-quality user documentation.

They can efficiently illustrate complex concepts, provide straightforward instructions, make it easier for readers to focus on the docs, etc.

That’s only a part of their advantages. The fact is that the human brain is wired to process visuals with ease, and data supports that.

According to research by MIT, it only takes a fraction of a second for a brain to fully process an image—more precisely, between 13 and 80 milliseconds.

Illustration: Archbee / Data: MIT

Therefore, instead of describing something in writing, it’s a good idea to use screenshots, images, graphs, videos, charts, or other types of visuals, depending on your needs.

What can happen if you neglect visuals? Take a look at Cheddar’s documentation below.

Source: Cheddar

There aren’t any visuals in the part of the documentation you can see above, but that might seem like a minor problem because there also isn’t a lot of text.

However, the situation is different when you encounter the wall of text further down the page.

Source: Cheddar

That’s a situation where some sort of visual would break the text up and make it easier for readers to follow.

The situation is the same throughout Cheddar’s entire documentation— there isn’t a single visual in it.

Some might argue that this is an example of API documentation, so it’s more technical and less appropriate for colorful visuals.

The type of documentation doesn’t have to be an excuse to neglect visuals.

Take a look at Spotify’s API documentation below:

Source: Spotify

As you can see, they included a bulleted list, and their code examples are visually attractive and stand out from the rest of the text.

Those two visual elements alone make the documentation much easier on the eyes and more inviting.

There is more. Spotify also includes screenshots in the same API documentation.

Source: Spotify

Screenshots can be particularly useful for providing instructions, as they show the actual screen and the elements on it.

That way, users can know at all times if they are following the instructions correctly.

Neglecting visual content like that isn’t a mistake only for aesthetic reasons.

In addition to making docs more appealing, they also make them more understandable and accurate, and those are essential features of every great user documentation.

Forgetting to Update the Documentation#

One of the biggest mistakes you can make with your user documentation is not updating it.

Why?

Because if you don’t update the documentation, it will turn from a valuable resource to a collection of outdated information that just takes up space and, worse than that, alienates your users.

Your users don’t have endless patience and loyalty, especially when they know they can look for other software solutions for their needs—solutions with relevant documentation.

In other words, your documentation should reflect every change your product goes through.

Incomplete and outdated documentation is a surefire way to annoy your users and risk losing them.

The minimum you should do for your customers is to warn them if some version or part of your documentation isn’t updated.

For example, Medium has detailed developer documentation on GitHub, but before developers dive into it, they are informed that it isn’t supported anymore.

Source: GitHub

However, remembering to update the documentation as soon as the product changes can be challenging.

Other responsibilities that you and your team members have can get in the way, and the documentation could end up forgotten on the pile of to-do tasks.

To prevent that from happening, you can set up reminders.

For example, technical writer Svetlana Novikova described in her blog post how her team used Slackbot as a reminder to update their docs every Monday.

Source: JetBrains

Dedicating a specific time for updating documentation is an excellent way to make updating a process and not just a task you’ll get to when you have the time.

TURN STATIC DOCS INTO INSTANT ANSWERS

Build beautiful knowledge portals that are easy to navigate, search and share

SPRING 2026Easiest SetupENTERPRISE
SPRING 2026Easiest To UseENTERPRISE
SPRING 2026Best UsabilityENTERPRISE
SPRING 2026High PerformerENTERPRISE
UsersLove UsMILESTONE

In addition to dedicating time, another great idea is to dedicate a specific person to updating the documentation.

For instance, if you use Archbee for your user documentation needs, you can select a member of your team, and they’ll get recurrent notifications to check the documents.

Source: Archbee on YouTube

That way, you know that someone is responsible for updating the docs and that, even if they forget to do it, Archbee will remind them.

Conclusion#

When it comes to user documentation, it’s important to get it right.

After all, user documentation is a resource that aims to help, teach, and inform every one of your users, from a beginner to an expert, about every facet of your product.

That’s quite a task, however you look at it.

Luckily, now you know which crucial mistakes you should avoid to create documentation that is up to the task. Your users will be thankful for it.

Try Archbee's full range of features with our free 14-day trial.

Frequently Asked Questions

The top pitfall is poor discoverability—if users can’t find your docs fast, they’ll assume they don’t exist and head to support (or a competitor).

Do this to make your docs instantly findable:

  • Put docs where users look: a persistent link in the top nav and footer, links from product and pricing pages, onboarding emails, release notes, and in‑app help icons that deep‑link to the right article.
  • Keep one home: use a single subdomain or subfolder (for example, docs.example.com or example.com/docs), set canonical URLs, submit a sitemap, and allow indexing. Avoid scattering content across marketing sites, GitHub wikis, PDFs, and community threads.
  • Make the docs homepage obvious: prominent search, clear categories, top tasks, and quick links for API, tutorials, and FAQs.
  • Short paths to answers: aim for the two‑click rule from homepage to task. Add a "Start here" path for new users and surface popular tasks.
  • Measure findability: track entry pages, internal search queries (and zero‑result terms), 404s, and time to first successful click. Run quick findability tests with real users.
  • Avoid fragmentation: if content must live in different systems (community, PDFs), provide a unified index or portal and strong cross‑links.
  • Reinforce in‑product: use context‑aware tooltips and help icons that link to the exact section, not just the docs homepage.

If users can land on the right page quickly, they’ll trust and use your docs. If not, they’ll file a ticket—or churn.

Navigation is about fast, predictable paths to answers. Build it in layers:

  • Powerful search: support typos, synonyms, and filters (product, version, role). Offer query suggestions and keyboard‑first search (for example, / to focus search).
  • Clear structure: add a sticky table of contents with anchored headings on long pages. Use a consistent page template: overview, prerequisites, steps, examples, troubleshooting, next steps.
  • Wayfinding aids: include breadcrumbs, previous/next links, related articles, and a visible version switcher.
  • Information architecture: organize by jobs‑to‑be‑done and user role, not only product hierarchy. Cap depth to three levels and keep URLs short and stable.
  • Mobile first: surface search and the TOC, use collapsible sections, and ensure large tap targets.
  • Naming: title pages by the task users are trying to complete. Avoid clever names.
  • For big libraries: create "Start here" hubs and curated collections that guide common journeys.

Example page outline:

# Task title
What this solves (1–2 sentences)

## Before you begin
Prereqs, access, version

## Steps
1. Do X
2. Do Y

## Example
Code or payload

## Troubleshooting
Common errors and fixes

## Related
Links to next tasks

Tip: keep pages scannable—use descriptive headings, short paragraphs, and callouts for warnings, tips, and notes.

Assumptions create blockers. Your audience spans newcomers to experts, so write for clarity and offer layers of depth.

  • Use plain language: define acronyms and terms on first use and link to a glossary.
  • Set context early: add a "Before you begin" section with prerequisites, required access, supported versions, and scope.
  • Offer layered paths:
    • Quick start for newcomers (a working result in 10–15 minutes)
    • Concepts for mental models and key ideas
    • How‑to guides for step‑by‑step tasks
    • Reference for specs and exhaustive details
  • Progressive disclosure: keep pages scannable with expandable advanced sections and callouts for deeper detail.
  • Show, don’t just tell: example‑driven steps, copy‑ready code snippets, and samples in multiple languages where relevant.
  • Role and version cues: clearly call out differences for admins vs. end users and for product versions.
  • Validate with real users: run reviews or quick tests with a mix of skill levels, watch where they stall, and iterate. Use support tickets and feedback widgets to spot gaps.

Write so beginners can succeed without hand‑holding experts, and give experts fast paths to the specifics they need.

Yes—visuals speed comprehension, reduce errors, and lower support load. Choose the right format for the job:

  • Screenshots for UI steps: annotate with numbers and highlights. Keep them current and legible in light and dark modes.
  • Short GIFs or videos for multi‑step flows: keep under 90 seconds, add captions and a text alternative, and show keyboard shortcuts when helpful.
  • Diagrams for systems and flows: architecture, data flow, auth sequences, and state charts. Pair with example payloads or code so readers can act.
  • Code and payloads: formatted code blocks with copy buttons; combine with small diagrams to explain relationships.

Best practices:

  • Accessibility first: alt text, captions, and transcripts. Avoid embedding essential text inside images.
  • Performance: compress assets, lazy‑load where appropriate, and serve via a CDN.
  • Maintenance: store source files, standardize styles, and track visuals that must be updated when the UI changes.
  • Localization and privacy: avoid text baked into images and remove any personal or sensitive data.

Rule of thumb: if a picture can replace a paragraph or prevent a mistake, use it.

Update docs whenever the product changes. Treat documentation as part of the release, not a follow‑up task.

Make it a process:

  • Ownership: assign a doc lead per product area. Add "last updated" timestamps and keep a changelog.
  • Versioning: maintain versioned docs, add deprecation banners, and redirect or clearly archive obsolete pages.
  • Cadence: include docs in your Definition of Done for every change. Add a monthly checkpoint and a quarterly content audit to catch drift.
  • Automation: set reminders in your workflow or chat tool; run link checkers and linters; validate code samples in CI; use screenshot‑diff tools to catch UI changes.
  • Triggers beyond releases: spikes in support tickets, zero‑result search terms, or SEO drops often signal gaps or stale content.
  • Communication: link release notes to updated docs and add a feedback widget to capture fixes fast.

Why it matters: fresh docs build trust, accelerate adoption, and prevent avoidable support tickets.

Documentation, technical writing tips and trends Blog

Join 5000+ people from around the world that receive a monthly edition of the Archbee Blog Newsletter.