Types of Documentation
Some writers focus on user guides for customers, while others handle internal documents. Each type has a different audience and purpose, so a writer’s work depends on their role and industry.
Like the name says, external (or client-facing) documentation is aimed at customers of a product or the general public.
The tone is generally more formal than in internal documentation, and the content focuses on usability and practical applications rather than implementation details.
As the target audience is outside the company, this kind of documentation does not disclose sensitive or proprietary details and must comply with various legal and regulatory requirements to protect the company and the users.
Some examples of public knowledge portals:
- Stripe Payments API documentation - explains how to integrate Stripe's Payment API into your products
- Epson printer documentation - user guides and data sheets for an Epson printer (in PDF format - a documentation portal is not necessarily HTML-only!)
- Installation and configuration guides - instructions for setting up a product, software, or hardware, and making it available for end-users.
- Administration guides - documentation for maintaining the product post-installation.
- User guides - end-user instructions for using a product, software, or hardware.
- API documentation - instructions for developers on how to use an API.
- Quick start guides - concise, easy-to-follow instructions for getting started with a product.
- Integration guides - instructions for connecting software or hardware with other systems or components.
- FAQs (frequently asked questions) - answers to common user queries in a structured format.
- Troubleshooting guides - solutions to common issues users may encounter.
- Knowledge base articles - concise documents that help users self-solve problems.
- Release notes - short summaries of bug fixes and new features added in a product release.
- Product specifications - detailed technical information about the hardware’s features, dimensions, and performance.
- Warranty and support documents - information on warranty coverage and service policies for a physical product.
- Safety and compliance documents - warnings, precautions, and regulatory compliance details for safe usage.
- Datasheets - technical summaries of a product’s specifications, including electrical, mechanical, and thermal properties.
- Service manuals - technical documents for technicians repairing and maintaining hardware.
- Regulatory compliance documents - certifications and compliance details ensuring the product meets industry standards.
Some types of documents, such as knowledge articles or release notes, can be both internal and external. For example, a company may publish a full changelog internally, but select specific issues to highlight in the public release notes.
Internal documentation is only available to employees of the company, so it is more relaxed in tone and does not need to comply with the same requirements as external documentation.
Often, internal documentation includes detailed technical or proprietary information and may describe processes specific to the company.
- SOPs (standard operating procedures) - step-by-step guides for internal workflows and processes.
- Developer guidelines - instructions on coding standards, infrastructure setup, and development workflows.
- Playbooks - structured manuals for handling specific tasks or incidents.
- Onboarding guides - training materials to help new employees learn tools and workflows specific to their roles.
- Architecture diagrams - explanations of the interactions between system components.
- Training guides - training materials for internal skill development.
- Product requirement documents (PRDs) or business requirement documents (BRDs) - detailed documentation outlining product features that should be implemented.
- Technical design documents (TDDs) - detailed technical documentation for product development.
- Style guides & branding guidelines - rules for consistent writing, design, and messaging.
Many of these documents are often written by non-technical writers, such as developers, architects, or business analysts.
