In Product Education
Teaching that lives inside the interface permanently rather than as a flow shown once.
The problem it solves
Onboarding flows run once, early, when the user has no context. The questions that arise in week three have nowhere to go except support or the exit.
Treat onboarding as an event and you accept a hard limit: everything must be taught in the first session, to someone with no context, and none of it is available later. In product education inverts that. The teaching is a permanent property of the interface, available whenever the question arises.
It is quieter work than a welcome flow and it compounds. A well written empty state: What a screen shows before there is any content in it., a definition next to an ambiguous metric, or an example in a placeholder keeps teaching for as long as the product exists.
Where teaching can live
- Labels and headings
- The cheapest education there is. Renaming a control so it states its effect removes the need to explain it anywhere else.
- Inline definitions
- A short explanation next to any term the product invented, such as a metric name. Visible, not hidden behind an icon the user must discover.
- Placeholders and examples
- A field showing a realistic example teaches format and expectation with no extra interface.
- Empty states
- The one place a new surface can explain itself, and the only teaching that reaches a user who finds a feature in month four.
- Just in time help
- A short panel attached to a complex control, opened by the user, not fired at them.
The ordering matters. Work down the list and stop as soon as the problem is solved. Most teams start at the bottom, because building a help panel is a project with a clear owner while renaming a label requires an argument about vocabulary.
Worked example
Fathom Ledger, an accounting tool
Support kept getting asked what Reconciled meant, and the team scoped a help centre article. Instead they changed the column header to Matched to bank and added one line under it reading Both sides of this transaction appear in your bank feed. The question stopped. The article was never written.
Every help article is a bet that the user will go looking. Every good label is a bet you have already won.
There is a real limit. Permanent teaching accumulates, and text that helps in week one becomes noise in week ten. Give explanations a lifecycle: collapse an inline definition after the user has seen the surface several times, and review the whole set when the interface changes.
When it fits
- Products with concepts the user has to learn, especially invented vocabulary or domain specific metrics.
- Features discovered late, long after any first session flow has run.
- Teams with recurring support questions that map to a specific label or screen.
- Interfaces used by people who rotate in and out, such as shared team tools.
When it backfires
- When explanatory text accumulates without review, so the interface fills with advice experienced users read past.
- When help is added instead of fixing the label that caused the confusion, which preserves the problem permanently.
- When definitions hide behind an icon, so only the users who already understand go looking.
- When the teaching is written by people who know the product too well to notice the assumed knowledge.
Products using it
Stripe
Dashboard metrics carry short inline definitions next to the number rather than only in documentation.
GitHub
Settings pages state the effect of a toggle underneath it, so the consequence is readable without leaving the page.
Linear
Keyboard shortcuts are shown next to the corresponding menu items, teaching the faster path during ordinary use.
The psychology under it
The takeaway
Fix the label before writing the help, and give every permanent explanation a plan for when it should fade.
Finished the teardown? Bank it and the day counts toward your run.