Our content team insisted we needed an SEO article on this keyword. So we’ve put together a mega-list of every type of technical documentation you’re likely to encounter in the wild—except the 47-page walkthrough guide to Golden Sun 2 that someone uploaded to GameFAQs in 2002, which is arguably the most thorough technical document ever written.
We’ve tried to make this useful rather than just long. Each type comes with a plain-language description, an honest take on when you actually need it, and the occasional warning about when it becomes a waste of everyone’s time. We’ve grouped them roughly by purpose, because a flat alphabetical list would be cruel.
User-facing documentation
These are the documents your customers, users, and anyone outside your engineering team will actually read. They tend to live on your website, in your product, or in a help centre. They’re also the ones that get written last, updated rarely, and blamed loudest when something goes wrong.
1. User guide (a.k.a. user manual)
The comprehensive reference document for how a product works. It covers features, functions, and how to navigate them. A good user guide assumes the reader is intelligent but unfamiliar with your specific product. A bad one assumes the reader already knows everything and just needs it confirmed in 80 pages of passive voice.
When you need it: Any product with more than one feature and more than one type of user.
2. Quick start guide
The “I just want to get it working” version of a user guide. It covers the most common tasks in the fewest possible steps, skips anything advanced, and ideally fits on a single (two-sided) page or scroll. If your quick start guide is longer than your full manual, something has gone wrong.
When you need it: At launch, for onboarding, and whenever your support team gets the same five questions every week. It’s the ideal resource for “RTFM” (IYKYK).
3. Quick reference guide (QRG)
Less of a guide, more of a cheat sheet. A QRG is designed to sit open next to someone while they work—a condensed reminder of syntax, shortcuts, fields, or steps they already know but don’t want to look up every time. Developers love a good QRG. Most companies don’t bother writing them.
When you need it: Complex software with lots of commands, fields, or workflows that users repeat regularly. You’ve probably seen a few pasted on walls next to someone’s desk.
4. Product manual
The physical product’s equivalent of a user guide. You’ll typically find these for hardware, machinery, or any product that can injure you if used incorrectly. The distinction between “manual” and “guide” has blurred significantly in software, but in regulated industries the word “manual” still carries some weight.
When you need it: Hardware, physical products, anything with safety implications or regulatory requirements.
5. Troubleshooting guide
A document that starts where everything else fails. It’s structured around problems rather than features: “If X happens, try Y.” A good troubleshooting guide is written by someone who has actually watched users break things. A bad one is a list of error codes with no explanation of what to do when you see them.
When you need it: Any product that can produce an error, which is all of them.
6. Knowledge base
Not a document but a system of documents—a searchable, categorised library of articles, FAQs, and troubleshooting content that users can self-serve from. The goal is to answer questions before they become support tickets. The risk is that it becomes a graveyard of outdated articles that erode user trust faster than having no documentation at all.
When you need it: Once you have enough users to generate repetitive support volume. Keep it updated often.
7. FAQ document
The FAQ started as a genuinely useful format on early internet mailing lists, where the same questions really did come up frequently. It’s since been colonised by marketing teams who use it to answer questions nobody asked. A real FAQ is based on actual user questions. An editorial FAQ is a list of softballs your own team wrote.
When you need it: When you have documented evidence of genuinely recurring questions.
8. Tutorial
Where a user guide explains what a feature does, a tutorial walks you through doing something specific from start to finish. Tutorials are goal-oriented: “Build a data pipeline in 20 minutes” rather than “Here is our data pipeline feature.” They’re harder to write than they look, because the writer has to maintain a coherent narrative while also being technically accurate at every step.
When you need it: For onboarding new users, demonstrating advanced capabilities, and developer relations.
9. How-to guide
Shorter and more focused than a tutorial. Where a tutorial might take you from zero to a completed project, a how-to guide answers a single question: “How do I export a CSV?” or “How do I set up SSO?” Think of it as a standalone unit of useful information.
When you need it: For knowledge bases, help centres, and whenever you want content that ranks in search.
10. Video tutorial
The same as a written tutorial but recorded. Video documentation has become genuinely popular—partly because it’s easier to absorb for visual tasks, partly because a lot of users simply won’t read. The downside is that video is costly to update when your product changes, which is why most SaaS companies have a graveyard of outdated screencasts on their YouTube channel.
When you need it: For onboarding flows, complex visual tasks, and product marketing.
11. Embedded assistance / in-app help
Tooltips, walkthroughs, modals, and contextual hints that appear inside the product itself. This is often the most-read documentation a company produces, because it shows up exactly when the user needs it. It’s also one of the least glamorous to write and almost never gets a dedicated owner.
When you need it: Any product with a meaningful onboarding journey or a complex UI.
12. Release notes
The changelog. A record of what changed, what broke, and what got fixed in each version of a product. Good release notes are honest and specific. Bad release notes say “bug fixes and performance improvements” and tell you nothing. They’re also a surprisingly powerful trust signal: users who see that a team ships regularly and communicates clearly are more likely to stick around.
When you need it: Every time you ship a meaningful change to your product.
13. Installation guide
Exactly what it sounds like—a document that walks someone through getting your software or hardware installed and running for the first time. Often underestimated in complexity, especially for developer tools where the setup environment varies wildly between users. A bad installation guide is responsible for more abandoned evaluations than almost any other failure point.
When you need it: Any product that requires setup before it can be used.
14. Support portal documentation
The articles that live inside your customer support system, written specifically to help support agents resolve tickets or help users resolve issues themselves. Overlaps heavily with knowledge base content but is often scoped differently, with more detail on edge cases and escalation paths.
When you need it: Once your support team starts repeating themselves.
Developer documentation
The category with the highest stakes and the least-forgiving audience. Developers will read your documentation with a level of critical attention most people reserve for legal contracts. If it’s wrong, they’ll notice immediately. If it’s missing, they’ll leave.
15. API documentation
The reference document for how to interact with your API: what endpoints exist, what parameters they accept, what they return, and what happens when something goes wrong. This is probably the single most important document a software company produces for a developer audience. A good API reference is complete, accurate, and has working code examples. Most API documentation fails on at least one of these.
When you need it: The moment your API is something another human is expected to use.
16. SDK documentation
Like API documentation, but for the libraries and tools you provide to make integrating with your platform easier. SDK docs typically cover installation, initialisation, and common patterns, with code samples in the languages your SDK supports. The failure mode here is docs that only work for the happy path and leave developers on their own the moment anything goes slightly sideways.
When you need it: When you ship an SDK, which should be around the same time you write this.
17. Source code documentation (code comments)
The explanatory text written directly inside the codebase—inline comments, docstrings, and block explanations that clarify what the code does and, more importantly, why it does it that way. Good code comments explain decisions, not mechanics. “We use a timeout here because the upstream service is unreliable” is useful. “This line sets the timeout” is not.
When you need it: Always, for anything that isn’t immediately self-explanatory.
18. Technical design document (TDD)
Also called a technical specification. This is the low-level blueprint for how a specific feature or system will be built: data structures, API contracts, state transitions, failure modes. It bridges the gap between the architecture document (which is high-level) and the actual code (which is the implementation). Writing a TDD before you build something is one of the cheapest ways to catch design mistakes.
When you need it: Before building anything non-trivial, especially if multiple engineers are involved.
19. Readme
The markdown file (.md) at the root of a code repository that tells you what the project is, how to set it up, and how to contribute to it. The readme is often the first thing a developer sees when they encounter your codebase. It’s also frequently the last thing anyone remembers to update. A good readme is short, honest, and actually runnable.
When you need it: Every repository that a human being will ever look at.
20. Changelog
Similar to release notes but typically more developer-focused and structured around the Keep a Changelog format: Added, Changed, Deprecated, Removed, Fixed, Security. The changelog is the formal record of what has changed between versions and is especially important for libraries and APIs where breaking changes can cascade downstream.
When you need it: Any library, package, or versioned API.
21. Runbook
A documented set of procedures for operating, monitoring, and troubleshooting a system in production. Runbooks live in the space between documentation and incident response. A good runbook tells an on-call engineer exactly what to do at 2am when an alert fires. A bad runbook is either missing entirely or was last updated two product versions ago.
When you need it: Any system that runs in production and has an on-call rotation.
22. OpenAPI / Swagger specification
A machine-readable definition of your REST API in a standardised format that can be used to generate documentation, client libraries, mock servers, and test suites. Worth distinguishing from API documentation proper: the spec is the source of truth, the documentation is the human-readable output. Confusing the two can cause problems.
When you need it: Any REST API where you want to generate documentation or tooling automatically.
Architecture and system documentation
Documentation for the people building and maintaining the systems themselves. Less about “how do I use this” and more about “how does this actually work and why did we make these decisions.”
23. Software architecture document (SAD)
The high-level blueprint for how a system is structured: its major components, how they interact, the decisions that shaped the design, and the constraints those decisions were made under. A good SAD explains the “why” behind architectural choices, not just the “what.”
When you need it: Before significant engineering work begins, and whenever the architecture changes meaningfully.
24. System administration guide
Documentation for the people who install, configure, maintain, and secure your systems. This includes setup procedures, configuration options, backup and restoration processes, security settings, and disaster recovery steps. Often written for IT administrators rather than developers or end users, which means it needs to be both technically rigorous and extremely clear about sequence and consequence.
When you need it: Any software deployed on-premise or in environments managed by third-party IT teams.
25. UI style guide
A reference document that defines how the user interface should look and behave: colour palettes, typography, spacing, component states, interaction patterns. It’s the contract between design and engineering. Without it, every developer interprets the designs slightly differently and the product slowly diverges into visual chaos.
When you need it: The moment more than one person is making UI decisions, or if you expect future handovers.
26. Disaster recovery plan
Documentation for what happens when things go catastrophically wrong: data loss, security breach, infrastructure failure. It specifies roles, procedures, communication protocols, and recovery steps. Most companies don’t have one until they need it, which is the worst possible time to write it.
When you need it: Before you need it, ideally reviewed annually or quarterly.
Requirements and planning documentation
The documents that get written before anyone writes a line of code, and which are frequently ignored the moment coding starts. That said, the act of writing them is often more valuable than the documents themselves—it forces decisions to be made explicitly rather than implicitly.
27. Product requirements document (PRD)
Defines what the product should do, who it’s for, and what success looks like. A good PRD includes user stories, acceptance criteria, and a clear statement of what’s out of scope. A bad PRD is either so vague it’s useless or so detailed it becomes a design document written by committee.
When you need it: Before any significant product work, especially when multiple teams are involved.
28. Business requirements document (BRD)
Similar to a PRD but written from the business perspective rather than the user perspective. Where a PRD asks “what does the user need?”, a BRD asks “what does the business need, and why?” Often produced in enterprise or consulting contexts where the client and the delivery team are different organisations.
When you need it: Enterprise software projects, client engagements, vendor relationships.
29. Software requirements specification (SRS)
The most formal and technically detailed of the requirements documents. An SRS specifies functional and non-functional requirements with enough precision that an engineer can implement them without needing to ask clarifying questions. Common in regulated industries (healthcare, aerospace, finance) where requirements need to be auditable.
When you need it: Regulated industries, safety-critical systems, government contracts.
30. Market requirements document (MRD)
A document that captures what the market needs from a product: who the target customers are, what problems they have, what competitors exist, and what opportunity the product is addressing. Written at the earliest stages of product development, before any design or engineering decisions have been made.
When you need it: When launching a new product or entering a new market.
31. User requirements document (URD)
A document that captures requirements specifically from the perspective of the end user, often derived from research, interviews, or usability testing. Distinct from the BRD (business focus) and the SRS (technical focus): the URD is about what users need to accomplish and experience.
When you need it: User-centred design projects, enterprise software where end users are distinct from the buyers.
32. UX design documentation
A broad category that covers the artefacts produced during the UX design process: user personas, user journey maps, wireframes, mock-ups, interactive prototypes, site maps, usability testing reports, and UI style guides. These documents exist at the boundary between research, design, and engineering, and their quality directly affects the quality of the product.
When you need it: Any product with a user interface and more than one person making design decisions.
Project and process documentation
The administrative layer of software development. These documents are about how work gets done rather than what gets built. They’re often treated as overhead, but teams that skip them tend to discover the hard way why they exist.
33. Project plan
A document that defines the scope, timeline, resources, milestones, and dependencies for a project. It’s the working map of how you get from “we should build this” to “it’s done.” Project plans should be living documents that get updated as reality diverges from expectation, which it always does.
When you need it: Any project with multiple stakeholders, dependencies, or a fixed deadline.
34. Project roadmap
Where a project plan is operational, a roadmap is strategic. It shows the direction of travel over a longer horizon without specifying every task. Roadmaps are communication tools as much as planning tools: they align teams, set expectations with stakeholders, and make priorities legible.
When you need it: Product development, strategy communication, stakeholder management.
35. Product backlog
An ordered list of everything that needs to be done on a product: features, bugs, improvements, research spikes. The backlog is the single authoritative source of what the team is working on and why. In Agile teams it’s constantly maintained, refined, and reprioritised. In non-Agile teams it’s often a spreadsheet that no one looks at.
When you need it: Any team doing iterative product development.
36. Sprint backlog
A subset of the product backlog: the specific tasks the team has committed to completing within a single sprint. Unlike the product backlog, the sprint backlog is fixed for the duration of the sprint (in theory). It’s also the document that makes the daily standup make sense, because without it nobody knows what “in progress” means.
When you need it: Scrum teams and any team running time-boxed development cycles.
37. Standard operating procedure (SOP)
A step-by-step description of how a recurring process should be performed, written clearly enough that someone unfamiliar with it could follow it correctly. SOPs are the backbone of operational consistency. They’re common in manufacturing, healthcare, and compliance-heavy industries, and increasingly valued by any company that wants to scale without everything falling apart. They enable smooth handovers, faster onboarding, and the ability to actually take leave.
When you need it: Any process that multiple people need to perform consistently and correctly.
38. Process map
A visual representation of a workflow—who does what, in what order, with what inputs and outputs at each stage. Where a SOP is prose, a process map is a diagram. Both are useful; which one you reach for depends on whether your process is better understood as a narrative or as a flowchart.
When you need it: Process improvement projects, onboarding documentation, cross-functional workflows.
39. Test plan
A document that defines what will be tested, how it will be tested, who will test it, and what the criteria for success are. A good test plan is written before testing starts, not after. It ensures testing is systematic rather than reactive and gives QA engineers a clear brief to work from.
When you need it: Any software project with a dedicated QA phase.
40. Test case specification
Where the test plan describes the overall testing approach, a test case specification describes individual test cases: the specific conditions, inputs, and expected outputs that determine whether a given feature is working correctly. These are the granular units that QA engineers execute, and they’re what allows testing to be repeatable and auditable.
When you need it: Any project with formalised QA, especially regulated or safety-critical software.
41. Test checklist
The lightweight cousin of the test case specification. A test checklist is a simple list of things to verify before a release, without the full formal structure of test cases. It’s faster to produce and faster to use. It’s also easier to skip items on, which is why proper test case specs exist.
When you need it: Smaller teams, pre-release sanity checks, when you need speed over rigour.
42. Quality assurance (QA) documentation
The umbrella for all documentation produced by a QA function: quality management plans, test strategies, test plans, test cases, bug reports, and QA reports. In regulated industries this documentation is also an audit trail. In most software companies it’s the thing everyone agrees is important and nobody funds properly.
When you need it: Any software that could cause meaningful harm if it’s wrong.
43. User acceptance testing (UAT) documentation
Documentation for the phase of testing where actual end users verify that the software meets their requirements in real-world conditions. UAT documentation includes test plans, test cases, and summary reports from the UAT phase. Unlike internal QA testing, UAT is the customer’s chance to say “this isn’t what we asked for” before the project goes live.
When you need it: Enterprise software, client projects, any product with formal sign-off requirements.
44. Test strategy
A high-level document that defines the organisation’s overall approach to testing across all projects: what types of testing are performed, what tools are used, how defects are tracked, and what the standards for test coverage are. Where a test plan is project-specific, a test strategy is organisation-wide.
When you need it: Engineering teams with more than a handful of developers, or any team that cares about testing consistency.
45. Release checklist
A list of everything that needs to happen before a release goes out: tests passed, documentation updated, stakeholders notified, rollback plan in place. Simple in concept, surprisingly valuable in practice. The release checklist is what stops teams from shipping on a Friday afternoon and discovering on Monday that they forgot to update the API keys.
When you need it: Every release process, without exception.
Business and marketing documentation
Documentation that lives at the boundary of technical and commercial work. Sometimes written by technical writers, sometimes by marketers, sometimes by whoever happens to be available. Quality is variable.
46. Working papers
Documents that exist to show your working. In academia, a working paper is a draft research paper circulated before peer review—substantive enough to be taken seriously, but explicitly open to challenge. In accounting and auditing, working papers are the formal records auditors compile to support their conclusions: evidence gathered, numbers referenced, procedures followed, findings documented. Both exist because someone, at some point, will ask you to justify what you did and why.
When you need it: When your conclusions need to hold up to scrutiny—whether that’s a peer reviewer, a regulator, or a very unhappy client.
47. White paper
A long-form, authoritative document that explores a problem, presents evidence, and argues for a particular approach or solution. In B2B contexts, white papers are as much a marketing tool as an educational one—they demonstrate expertise and generate leads. The best ones say something that isn’t already obvious. The worst ones are rebranded blog posts with a PDF cover.
When you need it: When you have a genuine point of view on an important topic and the research to back it up.
48. Case study
A documented account of how a customer solved a problem using your product or service, including what the situation was, what was done, and what the measurable results were. The most effective case studies are specific: actual numbers, named companies, clear before-and-after comparisons. The least effective are vague testimonials dressed up in a template.
When you need it: Sales enablement, marketing, and any time you want evidence your product works.
49. Request for proposal (RFP)
A formal document issued by an organisation that wants to solicit bids from vendors or service providers. It specifies the project scope, requirements, evaluation criteria, and submission instructions. Responding to RFPs is a significant amount of work, which is why having a well-documented set of capabilities, case studies, and previous responses makes it dramatically less painful.
When you need it: Public sector work, enterprise procurement, regulated industries where competitive bidding is required.
50. Business standards documentation
The internal policies, compliance guidelines, and operational standards that govern how a business runs. This includes codes of conduct, data protection policies, information security standards, and regulatory compliance documentation. Not glamorous. Also not optional in most industries, and increasingly scrutinised by enterprise buyers in their vendor due diligence.
When you need it: Any organisation with employees, clients, or regulatory exposure, which is most of them.
A few closing thoughts
Fifty types is a lot, and nobody needs all of them. The companies that produce the best documentation aren’t the ones with the most document types—they’re the ones that have figured out which documents their specific teams and users actually need, and then kept those documents accurate and useful over time.
The most common failure in technical documentation isn’t that companies skip a type they should have written. It’s that they write something once, never update it, and then wonder why nobody reads it. Good documentation is a maintenance problem as much as a writing problem, and that’s a harder thing to solve than any listicle can fully address.
But this is a start.
If any of the documents on this list are sitting on your backlog, Column can help you write, restructure, or recover them. We work with software companies, DevOps teams, and technical product organisations on everything from API references and SOPs to white papers and user guides. We’ve reduced engineer clarification questions by around 40% on past projects just by getting the documentation right. If that sounds useful, get in touch at team@columncontent.com.
Mo is the founder of Column, a technical research and content agency. Connect with him on LinkedIn.
