My documentation process
From figuring out what needs documenting to shipping the docs
Figuring out what needs documenting
This sounds like it should be the easy part, but in practice it's often the most difficult. At my current company, the intended process is that PMs tag relevant Jira tickets for documentation. In theory, that means work finds me automatically. In practice, tagging is inconsistent, and if I wait to be found, things slip through.
So I go digging. I attend sprint and planning meetings, check in regularly with product and design, and maintain close relationships with specific PMs who are good at looping me in early. Staying informed is an active job, not a passive one.
Getting up to speed
Before I write anything, I need to understand what I'm writing about, not just technically, but from the user's perspective. I start by reading whatever exists: product specs, existing docs, UX designs. Then I get into the product itself, testing the feature I'm documenting in a QA instance of the software from a user's point of view.
Understanding the user is something I work at regardless of how well I know the domain. Most of my career has been in HR software, which helps — I've been an employee, so I understand the concepts and workflows from my personal experience. But I've also documented web hosting and investor relations software, two industries I came into knowing very little about. In those cases, I leaned on conversations with UX and product to build up a picture of who I was writing for. The domain knowledge catches up; the habit of asking "what is this person trying to do, and where might they get stuck?" is what I bring to every project.
Writing and handling blockers
I do most of my writing independently, working from a rough outline before I commit to a full draft. From the second draft onwards, I'm constantly cross-referencing the style guide and our team process documents to check terminology, formatting, and consistency as I go rather than leaving it all to the end.
The two most common blockers I run into are SMEs who don't have bandwidth to review, and needing access to a feature that isn't quite ready yet. When that happens, I document what I can and flag gaps both in the draft and to the relevant stakeholders. And when I do have good access, I test every step myself. If I can't follow my own instructions, a user certainly won't be able to!
Review and quality bar
I don't consider something done until it's cleared a few distinct gates: an Acrolinx check for style and consistency, SME sign-off on accuracy, and a peer review with another writer. I send drafts with a clear request for written feedback, and I try to keep the process lightweight for busy reviewers.
The bar I hold myself to is, could someone unfamiliar with this feature follow my documentation and get their task done?
Day to day
Not every project is a big feature launch. A lot of my day-to-day is patch release notes, which mostly contain bug fixes, shipped after each 2-week development sprint. It's easy to treat them as a checkbox, but a clear and specific release note lands very differently than a vague one, and users notice. Beyond that, a meaningful chunk of my week goes to style guide questions from the team, process work, and the Jira admin that keeps documentation from falling through the cracks.
I love the thrill of starting on a new documentation project as much as the relief of handing over a completed one.