Not all documentation serves the same purpose. A step-by-step guide that walks someone through a process is doing a completely different job from a reference article that defines a list of parameters. Using the wrong content type for a task is one of the most common reasons documentation fails readers — even when the information itself is accurate.
This article describes five core content types used in a well-structured knowledge base, explains the job each one does, and helps you recognize which type is right for a given need. The first four are based on the widely used Diátaxis framework (tutorials, how-to guides, reference, and explanation); troubleshooting is added here as a fifth, since diagnostic content behaves differently enough from either to deserve its own definition.
The Five Core Content Types
How-to guides
A how-to guide walks a reader through a specific task from start to finish. It assumes the reader has a goal and knows why they want to accomplish it — they just need to know how. The entire article is organized around action steps that produce a concrete outcome.
| The job it does | Enables a reader to complete a real-world task. |
| When to use it | Any time a reader needs to do something specific — set up a feature, configure a setting, complete a workflow. |
| What it is not | A tutorial (which teaches), a reference (which informs), or a conceptual article (which explains). A how-to guide does not teach concepts; it moves a reader through steps. |
| Recognizable by | A task-oriented title ("How to set up two-factor authentication"), numbered steps, a defined starting point, and a defined outcome. |
Tutorials
A tutorial teaches a reader how to do something by having them do it. The goal is learning, not task completion. A reader follows a tutorial to build understanding and skill, not because they have an immediate real-world need. The tutorial controls the environment — it may use sample data, a sandbox, or a simplified scenario specifically designed for learning.
Scoping note: In practice, this category is easy to overuse. If your knowledge base doesn't actually offer a sandbox, sample data set, or dedicated onboarding path, most content that gets labeled "tutorial" is really a how-to guide in disguise — the reader has a real task in mind, not an abstract learning goal. Reserve "tutorial" for content that genuinely teaches in a controlled environment; otherwise, write a how-to guide instead.
| The job it does | Builds competence and confidence in a new user. |
| When to use it | When onboarding new users, introducing a complex feature, or helping readers develop skills they do not yet have — genuinely through a controlled, learning-first environment. |
| What it is not | A how-to guide (which solves a real task), or a conceptual article (which explains without doing). A tutorial always involves action — the reader must do something. |
| Recognizable by | A learning-oriented framing ("In this tutorial, you will learn how to..."), a controlled or sample environment, and an explicit statement of what the reader will be able to do by the end. |
Conceptual articles
A conceptual article explains how something works, what something is, or why something is designed the way it is. It does not instruct — it informs. The reader walks away with understanding, not a completed task.
| The job it does | Builds the mental model a reader needs to use a product effectively. |
| When to use it | When introducing a new concept, explaining the architecture of a system, or helping a reader understand the reasoning behind a design decision before they interact with it. |
| What it is not | A how-to guide or tutorial. A conceptual article never has numbered steps. It explains; it does not instruct. |
| Recognizable by | A concept-oriented title ("Understanding role-based access control"), prose-heavy content, diagrams and examples, and the absence of procedural steps. |
Reference articles
A reference article provides precise, structured information that readers look up, not read sequentially. It is a resource consulted in the middle of a task, not read from beginning to end. Reference articles prioritize completeness and precision over narrative flow.
| The job it does | Gives readers quick access to accurate, complete technical information. |
| When to use it | API documentation, parameter lists, keyboard shortcuts, error code definitions, glossaries, configuration options — anywhere a reader needs to look something up. |
| What it is not | A tutorial or how-to guide. Reference articles do not walk readers through a process. They provide information; the reader decides what to do with it. |
| Recognizable by | A structured, predictable format (tables, definition lists, code blocks), a consistent pattern across entries, and a title that signals lookup behavior ("API reference," "Keyboard shortcuts"). |
Troubleshooting articles
A troubleshooting article helps a reader diagnose and resolve a problem. It is organized around symptoms and their solutions, not around product features. A reader arrives because something is wrong — the article's job is to help them identify what it is and fix it.
Unlike a how-to guide, which starts from a goal ("I want to accomplish X"), a troubleshooting article starts from a symptom ("X isn't working"). That distinction — goal-first versus symptom-first — is why troubleshooting content earns its own category here rather than folding into how-to guides.
| The job it does | Resolves a problem the reader is actively experiencing. |
| When to use it | Error messages, unexpected behavior, failed processes, common support issues. |
| What it is not | A how-to guide (which assumes things are working) or a reference article (which provides information without resolving a specific problem). A troubleshooting article is diagnostic — it starts from a symptom, not a goal. |
| Recognizable by | Symptom-first organization ("If you see... / If you cannot..."), conditional logic, multiple possible causes for a single symptom, and escalation paths when the article's solutions do not resolve the issue. |
Content That Doesn't Fit Neatly
These five types cover the bulk of a knowledge base, but not all of it. Content like FAQs, glossaries, release notes, and product overview or landing pages often borrows from more than one type without fully matching any of them — an FAQ, for instance, behaves like a reference article (looked up, not read start to finish) but is organized around questions rather than a structured schema. Treat these as their own recognized exceptions rather than forcing them into one of the five categories; what matters is that each piece of content has a clear, singular job, whatever you call it.
Mixing Content Types
In practice, a single article may draw on more than one content type. A how-to guide might include a brief conceptual paragraph to explain why a step matters. A troubleshooting article might include a reference table of error codes.
This is fine, as long as the primary purpose of the article remains clear. Readers need to be able to identify immediately what kind of article they are reading and what they will get from it. An article that is simultaneously trying to teach, instruct, explain, and troubleshoot will do none of these things well.
When an article starts to serve too many purposes, split it.
Choosing the Right Content Type
When you sit down to write a new article, ask one question first: what does my reader need to walk away with?
| Reader needs to walk away with... | Write a... |
|---|---|
| A completed task | How-to guide |
| A new skill or understanding, gained by doing | Tutorial |
| A mental model or explanation | Conceptual article |
| A specific piece of information | Reference article |
| A resolved problem | Troubleshooting article |
Getting this right before you start writing saves significant revision time later. A well-chosen content type gives the article its shape; a poorly chosen one means rewriting from scratch.