The starting point

In healthcare software, user guides are not optional. They are part of the medical device: regulation requires them, auditors review them, and every user-visible change in a release must be reflected in them.

At Mylab, around 30 guides covered the whole product family, from laboratory work and blood services to care units, screening, billing and administration. Product specialists wrote them alongside their main job. As the portfolio grew, this led to uneven structure and terminology, PDFs with differing layouts, and no systematic trigger for updating a guide when the software changed. A growing product family needed a more scalable model.

My role

I own user guidance as part of the CX function: the strategy, the process, the partner relationship and the quality standard. A professional partner does the writing, product owners and UX designers provide the content, and I set priorities and remove blockers.

What I did

1. Brought in professional writers. I ran the tender for a technical-writing partner and onboarded their writers into our tools, teams and release rhythm. We meet weekly to track every guide, release by release.

2. Got the urgent releases under control first. With an audit deadline approaching, I prioritised the guides that open directly from the product. I set up a meeting with product owners to find out exactly which guides each release affected, and tracked the status of every guide until the release was done.

3. Made guidance part of the release process. I wrote the work instruction for user manual change control. It defines when guide updates are estimated, how writers learn what changed, who reviews the content, how testing checks that the product opens the right guide version, and who confirms that the right guide ships with the release. It sets clear roles from the technical writer to a role that owns overall guide quality, and a separate path for corrections after release, prioritised by their impact on patient safety. I also designed the supporting Jira process and ticket template, so every guide update is a tracked task linked to the product change behind it. I reviewed it with quality, regulatory, release management, product and team leads, and we now work according to it.

4. Set a quality standard. Together with the writing partner I defined a common structure for every guide (introduction, navigation, tasks, troubleshooting), naming conventions, a terminology baseline, a style guide based on the brand guidelines, and rules for images and tables.

5. Started the move to structured content. We are moving the guides from PDF templates to a structured authoring tool, starting with a few pilot guides. That makes content reusable across guides and versions, prepares for translation and localisation, and opens the way to better in-product help than a PDF can offer. We have also started using AI to support the regulatory check of guide content.

Vision: AI-assisted help in context. The longer-term goal is help that answers the user's question inside the product, in the context of what they are doing. In a regulated product those answers must come only from approved and reviewed guide content, with a clear source. That is why structured content, shared terminology and a reliable review process come first: they are what makes trustworthy AI-assisted guidance possible.

Outcome

• Every release now ships with the user guide updates it requires, with a tracked status for every guide and named reviewers.
• Guidance has a defined place in the release process, rather than depending on individual effort.
• A common structure, terminology and style now apply across the portfolio, and the first guides are moving to structured content.

What I learned

• User guidance fails at the handovers, not in the writing. Once professional writers were in place, the real problems were getting information about changes to the writers in time, and clear ownership of each guide. Process and roles fixed more than editing did.
• In regulated products, guidance is part of the product. Treating guides as a release deliverable with an owner, not as documentation written afterwards, is what makes them reliable.
• Structure first, tools second. Agreeing on structure and terminology before migrating to a new tool made the migration a step forward rather than just a format change.