Best for
- Help centres that explain features instead of solving problems
- Turning the top support tickets into articles that deflect them
- Docs written from the spec that no longer match the screens
What you give it
- The task or problem to document, and access to the product as users see it
What you get back
- The article task-shaped: titled as the user's goal, steps verified against the live interface, the outcome stated so success is recognisable
- The real-world layer: the prerequisites stated upfront, the common failure points addressed inline where they happen, the edge cases either covered or honestly routed to support
- Searchability built in: titled and phrased in the user's vocabulary (mined from tickets and searches), so the article is found by the person who needs it
How it works
- Shapes by task, not feature: the title is the user's goal in the user's words, the body is the path to done — feature tours are marketing wearing documentation's badge.
- Tests by doing: every step executed against the live product while writing, with the interface's actual labels — the mismatched step is where the reader's trust (and the deflection) dies.
- Writes for the frustrated moment: prerequisites before step one (the missing-permission discovery at step four is a rage generator), failure points caught inline where they happen, scannable structure throughout.
- Builds searchability from evidence: the ticket phrasings and search queries become the title and the synonyms, because the unfound article deflects nothing.
Example
You: Our top ticket is 'how do I add a team member?' — 40 a week. Write the article that ends it.
Result: The article, tested by doing: titled in the asked words ('Add a team member' — not 'User provisioning'), prerequisites stated first (you need the Admin role — with how to check, because half the tickets were non-admins hitting a missing button the old doc never mentioned), six verified steps with the interface's actual labels (two had changed since the old doc), the inline catch at the known failure point ('If the invite email has not arrived in 10 minutes: check the spam folder, then verify the address — resend from here'), the edge cases covered (inviting someone who already has an account; the seat-limit message and what to do about it), and the honest boundary (SSO setups: contact us, with the link). Tickets fell to single digits in three weeks; the remaining ones were the SSO cases, correctly routed.
Limits — please read
- Articles age with the interface; the verification date and the change-triggered review are part of the structure.
- Some issues are genuinely not self-serviceable; the article's job then is fast honest routing, not a maze.
- Screenshots multiply maintenance; it uses them where they carry real load and labels where they do not.