Visual Communication
In technical documentation, visuals often do the heaviest lifting. They can cue the reader for what they are about to read and prevent confusion. Or they can eliminate the need for written instructions altogether. Although an image takes far more time to create than its counterpart block of text, it’s almost always worth the effort.
My process starts with choosing the style of visual to create. I weigh brand aesthetics, audience needs, available source material, and document type before choosing a format. I’m skilled with using computer aided design files (CAD) to create technical illustrations, 3D drawings, and realistic renderings, and in the absence of CAD source material, lightbox photography or image tracing in Adobe Illustrator are often good alternatives.
User Enablement
User enablement is about minimizing friction in the user’s learning process. That learning curve doesn’t look the same for everyone, even when the procedure being described is ostensibly the same. An experienced technician who needs a reminder mid-procedure needs a totally different artifact than a new hire in training. Getting it right requires careful forethought. What information does the audience actually need? (And what don’t they need?) What format delivers that information best; is it a knowledge base article, a quick reference guide, a version-controlled SOP, something else?
There are granular elements too. Intuitive information architecture, searchable content, micro-content that highlights critical information. Good documentation gets evaluated through the lens of how the user will actually meet it, not just how it looks on the page.
Single Sourcing
“Single sourcing” is what it sounds like; it means controlling text and visuals in one location even if they end up being published in multiple places and formats. It is essentially the difference between maintaining one document and maintaining twelve. For example, when an SOP, a quick reference guide, marketing materials, and a language translation all describe the same thing, treating them as separate files is how drift starts. Drift between a controlled SOP and the QRG on the wall ends up in the weekly QA meeting (or worse, in an audit finding).
How is it done? Using a CMS to version control and maintain a “single source of truth” is a good start, though it still relies on manually remembering to implement updates across all published content when the changes are made to the controlled source document. This is remedied with a structured authoring tool like Adobe FrameMaker: content lives in one place, gets tagged for audience and channel, and published to each format on demand. This is called “multi-channel publishing”.
Why does it matter? It’s all about reducing error rates and streamlining publishing. Done well, single sourcing does two things at once: it cuts the work of producing new documentation by leveraging what already exists, and it guarantees a single source of truth so updates can’t slip past one format while reaching the others.
Process Development
Most documentation work happens inside a system someone else built: a templated SOP, a publication pipeline that ensures accuracy and accountability, a style guide that prescribes exactly what font or tone to use. Process development is the work of establishing these systems. The work is invisible and taken for granted when it’s done right, and a deep frustration to fix when it isn’t.
At some point, often in the back half of the startup growth cycle, someone must make these decisions. Ideally these decisions lead to something that is intuitive to everyone, promotes long-term organization, and mitigates product quality failures.
I’ve been the first technical writer hired in several full-time and freelance roles, responsible for developing review processes, version control standards, technical style guide, and other systems. It’s a rare opportunity to be able to contribute in such an important way, to establish the systems that will live on for years. Whenever I’ve been put in a position where I recognize the need for infrastructure, I’ve taken that opportunity and built out systems with engineers, quality members, and technicians.
Quality & Compliance
An internal SOP affects more than the production team. It can be a training artifact for new hires, a source of truth for QA evaluation, evidence for an auditor, and sometimes a marketing claim. So when I author an SOP, I do it with other teams in mind too. Because if I don’t, the specifications that weren’t included in the SOP the first time become a CAPA later, or the workaround the floor invents because the SOP wasn’t specific enough becomes an undocumented deviation eventually.
I’ve worked inside enterprise document control systems where this discipline gets enforced: SolidWorks PDM, Veeva eQMS, Git, and SharePoint. In each one, my job included approval workflows, project managing documentation bundles to deadline ahead of product launches, and acting on change requests from other teams.