What good help is worth
A user opens the export dialog, reads the tooltip, and files a ticket anyway. What good help delivers, what makes it precise, and the rule behind it: every unit has a function.
Blog
Onboarding without per-user pricing
Onboarding tools bill by monthly active users because they render inside your app and can count them. What you are buying, and what is left once you build the runtime.
Ticket deflection without a separate support tool
Deflection needs answers that exist, a way to find them, and a place to show them. Two of the three you already have. What the separate knowledge base adds, and what it costs.
Three tools, one knowledge layer paid for three times
Onboarding tool, support platform, docs site. Each does a different job with the same explanations. What a single content layer replaces, and what it honestly does not.
Content or logic: where the line runs
When something is shown is logic. What it says is content. Three questions that place anything, the hard cases, and why the split gives you two speeds.
One explanation, six copies: author once instead
Tooltip, onboarding step, help article, deck, support macro, API docs. Six versions of one explanation that drift apart, and what one source actually changes.
Why in-app help needs stable identifiers
By position, by content, or by a name that never moves. How your application asks for a sentence decides what a rewrite costs you two years from now.
Your developers should not be correcting punctuation
A support lead spots a wrong word. Two weeks later an engineer spends an afternoon on it. Nothing went wrong, and that is the problem: your process routes on access.
Where does your onboarding copy actually live?
The welcome screen, the empty state, the tour, the checklist and three emails. Onboarding is the one sequence where order is the point, and it is spread over five systems.
Why is your tooltip text in Git?
Version control answers questions about change. A sentence in your interface needs one of its four answers, and pays for all four every time a word has to change.
Are you still hardcoding help texts?
Open the file where your interface strings live and read one out loud. Where a sentence lives decides who may change it, and how long a fix takes to reach a user.
Who owns your error messages?
Ask five people on a product team and you get five answers. Ownership of interface text is decided by your repository permissions, which were never designed for it.
Why nobody dares to update old in-app help
Everyone knows the paragraph is out of date. Four small obstacles keep it that way, and none of them are about writing. What makes old help text fixable again.
Hardcoded help scales. Maintaining it doesn't.
Your payment error message is a string in a file, written in a hurry eighteen months ago. Here is what changes when help content stops behaving like code.