Visual Communication
In technical documentation, visuals often do the heaviest lifting. They transmit knowledge to the user faster than prose can, and a well-designed diagram or technical drawing shows users what to do instantly and more clearly than a wall of text.
My process starts with deciding on 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 Strategy
User enablement is about minimizing friction in a user’s learning process. That learning curve doesn’t look the same for everyone, even when the process is ostensibly the same. An experienced technician mid-procedure needs a different artifact than a new hire in training.
Getting it right takes careful forethought. What information does the audience actually need? (And what don’t they need?) What format hands them that information best — a knowledge base article, a quick reference guide, a version-controlled SOP?
The work doesn’t stop once those questions are answered. User enablement also lives in the smaller decisions: intuitive information architecture, searchable content, callouts and warnings that land where the user is looking, micro-content built to be reused across documents. Good documentation gets evaluated through the lens of how the user will actually meet it, not just how it looks on the page.
Quality & Compliance
An SOP for a manufacturing process affects more than the manufacturing team. It can be a training artifact for new hires, a source of truth for QA, evidence for an auditor, and sometimes a claim that marketing repeats back to a customer. So when I author that SOP, I’ll do it with all those 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.
Content Reuse & Single Sourcing
“Single sourcing” is the difference between maintaining one document and maintaining twelve. When an SOP, a quick reference guide, a training deck, and a Spanish-language translation all describe the same procedure, 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.
A structured authoring tool like Adobe FrameMaker makes this possible: content lives in one place, gets tagged for audience and channel, and publishes to each format on demand.
Remember the contrast in the User Enablement Strategy section between the experienced technician and the new hire in training? Single sourcing is what makes it economical to maintain a separate artifact for each.
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 standard operating procedure, 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.