The Assignment: Write 180+ new help articles for a help site relaunch.
Overview
— Project
Write 180+ end user help articles
— Deliverables
180 help articles
User Guides
Style Guide
— Team
Technical Writer (me)
Product Manager
Director of Product
— Client
Emtrain
— Timeline
2024-2025
— Tools
JIRA
Figma
Confluence
G Workspace
Slack
Loom
Zoom
I was embedded with the product team to create 180+ help articles for their eLearning and compliance training platform.
The product was feature-rich but complex, serving administrators who managed training programs for their organizations.
My role was to translate that complexity into clear, actionable documentation that admins could actually use to get their work done.
A key part of the work was standardizing terminology across all documentation. Internal jargon had crept into user-facing content, making articles harder to understand. I cleaned that up, introduced accessible and inclusive language practices, and applied plain language principles throughout. The goal was to make every article as clear and usable as possible, regardless of the reader’s technical background or familiarity with the product.
Selected Docs
I wrote 180+ user docs, a Style Guide, and two Integration Guides. Here are some of those docs:
HRIS Implementation Requirements Guide
Notifications Writing Checklist
Preparing Your User Data for Import
The Workflow
Article development began with research, which formed the basis for outlines I submitted to the Product team for review. Once an outline was approved, I would draft the full article and revise it based on the product manager’s feedback (both written and video) until it was ready for QA and upload to the help site.
Process At-a-Glance
The writing process began in Google Docs and articles moved into ZenDesk once finalized.
Style Guide
The style guide evolved organically as I wrote the first dozen articles. Through trial and error and based on feedback, I identified what voice and tone worked best. This hands-on approach meant the guidelines were grounded in real documentation challenges, not theoretical best practices. As patterns emerged, I captured them in a living style guide that the team could reference going forward.