Glossary · 1 · Documentation models
Technical documentation model
Also known as: Documentation model, Documentation approach
In technical communication, a technical documentation model is a set of principles for dividing, organizing and expressing technical content so that readers can find and use it. A model answers questions such as how large a unit of content should be, what each unit is about, how units connect, how content is marked up and how much prose a reader needs. The term is an umbrella label rather than a standardized one: no standard defines "technical documentation model", and the individual models come from technical communication literature and from publishing practice. Models are design principles, not deliverables, and they say nothing by themselves about whether a documentation set meets a legal or contractual requirement.
- technical documentation
- documentation models
- information design
- structured authoring
- topic-based
In one sentence
Umbrella term for the principles that divide, organize and express technical content — and how the six documentation models combine.
Example
Before migrating its machine manuals to DITA, a documentation team wrote down the documentation model it wanted: topic-based units, task-first sequencing, minimalist procedures and a metadata profile for delivery.
A technical documentation model describes how content is shaped, not what a product manual must contain. Requirements on content come from regulation, contracts and standards for information for use; models come from technical communication practice and research, and teams adopt them to make content findable, reusable and translatable.
The encyclopedia subject area Technical documentation models describes six of them:
- Topic-based documentation — content is written as self-contained units instead of chapters of a book.
- Task-based documentation — content is organized around what users do, derived from task analysis.
- Every Page is Page One — each unit assumes the reader arrived from search and therefore carries its own context (Mark Baker, Every Page is Page One, XML Press, 2013).
- Semantic documentation — meaning is encoded in markup, metadata and vocabularies so that machines can select, filter and deliver content.
- Minimalism — prose is reduced to what supports action, with the user's task rather than the system description as the anchor.
- Structured authoring — content follows a formal content model enforced by a schema, so structure is validated rather than merely styled.
These six are not alternatives. A real documentation set usually combines them: topics that are also tasks, written minimally, structured against a schema, tagged semantically, and each one readable as page one. The models overlap and occasionally pull in different directions — for example a strict "page one" stance adds context that a minimalist stance would cut — and resolving that tension is a design decision for the team.
How it applies
- Write the model down. Record the chosen unit size, the information types, the mandatory and optional elements, and the metadata profile. The result is the documentation set's information model; the models above are the principles behind it.
- Implementation is a separate choice. DITA with information typing, a lightweight XML or Markdown setup with a custom content model, or an iiRDS topic package can all express the same model; the model does not dictate a tool.
- Machinery documentation. Safety information, residual-risk statements and maintenance procedures are usually easiest to keep consistent as typed, task-oriented topics that can be reused per machine variant — which is the topic-based and structured models working together.
- Software documentation. Release-driven content favors small units with their own context, because readers enter through search engines and in-product help rather than a table of contents.
- Make the model checkable. Structural rules can be enforced through schema validation; editorial rules (step length, wording, required warnings) need review checklists, because a schema cannot judge them.
- Compliance stays separate. Following a documentation model does not make a documentation set compliant with IEC/IEEE 82079-1:2019 or any product regulation, and it does not make a product safe. The standard gives principles and general requirements for information for use; conformity is assessed against those requirements, not against an authoring approach.
Documentation model vs. information model
A documentation model is a set of principles — prose-level guidance on how to divide, organize and express content. An information model is the concrete specification for one documentation set: element names, allowed nesting, required metadata, taxonomy values. The documentation model explains the intent; the information model is what authors and tooling actually enforce. Two teams can share the same model and still have very different information models.