Technical writing: an industrial process

Note

Technical writing is based on rational processes. Too often associated with a strong literary aspect, it is frequently left to the improvisation and inspiration of the technical writer. Technical writers, like other company employees, must meet their objectives in a predictable and reproducible manner.

This page maps the seven stages of the methodology, how they connect, and the production chain that supports them.

This process is based on a rigorous methodology and a reliable production chain.

Technical writing process

To create and promote content with high added value for the company, technical writers are in constant dialogue not only with all internal stakeholders, but also with the company’s ecosystem: partners, journalists, users, etc. In this way, they provide different audiences with the information they need. This strengthens the company’s brand image, improves customer satisfaction, and makes it easier for prospects to perceive the product’s benefits.

The seven stages

Each stage has its own article.

1. Project definition. As with R&D or marketing projects, defining the project is key to estimating the budget and benefits: audience, scope, deliverables, and success criteria.
2. Information gathering. The technical writer collects information from sources inside and outside the company: product specifications, issues, interviews with R&D, and handling the product.
3. Product testing. The writer is the users’ first representative and tests the product in conditions similar to theirs, rather than merely compiling what stakeholders say.
4. Content creation. The technical writer creates the content in continuous communication with R&D, marketing, and other stakeholders, within the constraints of the documentation life cycle.
5. Validation and quality control. Content is validated before delivery, and every change request is tracked, through a CMSCMS (Content Management System)A tool that adds workflow and file-locking to content management, at the cost of reliability trade-offs compared to plain version control.View in glossary → workflow or a ticketing system.
6. Translation. Translation affects both the editorial style and the organization of repositories, so it must be planned from the start.
7. Delivery. Validated content reaches its audiences in the format and through the channel chosen at project definition.

How the stages connect

The stages follow one another, but they are not a strict relay:

• Validation runs alongside writing. Ideally, validation takes place in parallel with content creation: early modifications are less costly.
• Translation branches off validation, but is planned from the outset. Modular content can be translated in parallel with writing.
• Testing checks what gathering collects. Information from stakeholders is partial; testing the product fills the gaps.
• Delivery honors project definition. The deliverables’ format and channel are decided in the first stage and delivered in the last.

The production chain

Technical writers rely on a production chain that is as automated as possible. By implementing an industrial and reproducible process, they reduce production costs and provide a consistent level of quality that is tailored to the company’s goals.

Content creation feeds the chain, and the chain feeds delivery:

Source formatThe format in which the technical writer creates content: the recipe, distinct from the dish.

RepositoryWhere the sources are stored, protected, and shared by the team.

Target formatThe deliverables the audience reads, such as PDF or HTML, generated from a single source.

The production chain today

In a docs-as-code setup, the production chain is concrete rather than notional: sources are text files in Git, each change is reviewed as a pull requestPull requestA request to merge a branch's changes into the main line, presented as a reviewable set of differences: reviewers comment, automated checks run, and approval is recorded before publication. GitLab calls it a merge request.View in glossary →, automated checks (build, links, metadata) run before anything is merged, and a CI/CDCI/CD (continuous integration and continuous delivery)Automation that checks every change as soon as it is submitted (continuous integration) and publishes the result once the checks pass (continuous delivery). In docs-as-code, a CI/CD pipeline builds the documentation, runs tests such as link and schema checks, and deploys the site.View in glossary → pipeline publishes the result. The steps above do not change; what changes is how much of their bookkeeping a machine can take over. AI-assisted drafting can fit into the same chain, as one more input that goes through the same review and validation as any other contribution.

For a single change traced through this chain, see the docs-as-code workflow example.

Related articles

• Integrating documentation into development processes
• Managing a project from start to finish