Discoverability
A capability that users cannot find does not exist, no matter how well it is built.
Definition
Norman's term for the degree to which a user can determine what actions are possible and how to perform them. It depends on signifiers, constraints, mappings and feedback working together.
Expert heuristic. A review criterion developed by practitioners. Useful and widely taught, but evaluated by judgement rather than measurement.
On this plate
Reach for this when
- Introducing gestures or icon-only controls.
- Reviewing analytics for features with near-zero adoption.
- Designing empty states and first-run experience.
Common mistakes
- Gesture-only interactions.
- Tours instead of visible affordances.
- Assuming an internal team's familiarity generalises.
- Answering low usage with a tour, when the problem is the name or the location.
Where discoverability fails
Gesture-only interactions are the most common failure. A swipe with no visible cue is invisible to anyone who has not been told about it, and there is no equivalent of hovering to find it.
Icon-only controls are the second. An icon without a label is a guess unless the metaphor is already a convention in that context.
The third is depth. A capability three levels into a menu tree exists but will only be found by people already looking for it.
Making things findable
- Label controls with words. Icons support recognition; they rarely establish it.
- Give gestures a visible alternative, always. Swipe to delete needs a visible delete somewhere.
- Reveal partial content at a scroll boundary so the user knows there is more.
- Use empty states to teach the primary action, since that is where a new user is looking anyway.
- Surface capability contextually, at the moment it becomes relevant, rather than in a settings screen.
- Make search cover features and settings, not only content.
Why a feature goes unfound
| Cause | What it looks like | Fix |
|---|---|---|
| No signifier | A gesture or hover reveals it, nothing hints at it | A visible control, even a small one |
| Wrong name | It exists, and nobody searches the word you used | Name it as readers describe it, keep the old word as a synonym |
| Wrong place | It sits under a menu nobody opens for this task | Move it to where the task happens |
| Wrong moment | Introduced during onboarding, needed three weeks later | Introduce it at the point of need |
| Buried depth | Three levels down, behind an unrelated label | Flatten, or expose it from the surface |
In practice
- i.
Swipe actions with a visible fallback
Mobile listsSwipe to archive is fast for people who know it. Pairing it with a visible action in the row's detail view means the capability is available to everyone, and the gesture becomes an accelerator rather than the only route.
- ii.
Empty states that teach
New accountsAn empty project list showing the create action prominently, with a one-line explanation of what a project is for, teaches at the moment of need without a tour.
- iii.
The feature announced too early
Timing as discoverabilityCollaboration was explained on day one, when the workspace had one person in it. The explanation was accurate, well written, and forgotten by the time a second person joined.
Commonly confused with
Close neighbours that get substituted for each other. The difference is stated first, then the condition that picks one over the other.
Visibility of System Status
HeuristicKeeping the reader continuously informed of what the system is doing.
Key difference
Visibility of system status is about what the product is doing right now. Discoverability is about what the reader could do next. One reports state, the other advertises possibility, and a perfectly honest status message does nothing for a feature nobody can find.
Use Discoverability when
- The capability exists and nobody uses it.
- The action is hidden behind hover, a gesture or an unlabelled icon.
- The fix is a signifier, a label or a better place to put it.
Use Visibility of System Status when
- Something happened, is happening, or failed, and nothing said so.
- The fix is feedback: a state, a message, a progress signal.
Local chart
PRIN·005 · Region I · Grid B1
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Sources
Where a source establishes something narrower than the popular reading of it, the note says so.
- [1]
The Design of Everyday Things
D. A. Norman, Basic Books, 1988, revised 2013
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applied through
Where this shows up as a concrete interface decision.
- TooltipCMP·013 · Component
- Command PalettePAT·018 · Pattern
- Empty StatesPAT·010 · Pattern
- OnboardingPAT·014 · Pattern
- ClosureFND·007 · UI foundation
- IconographyFND·050 · UI foundation
Check your work
Review passes that test whether this was done properly.
- Mobile UX ChecklistCHK·003 · Checklist
Related concept
Connected closely enough to change how you apply this.
- Help and DocumentationHEUR·010 · Heuristic
- Recognition Over RecallHEUR·006 · Heuristic
- Affordances and SignifiersPRIN·007 · Principle
- FeedbackPRIN·004 · Principle
- Gulfs of Execution and EvaluationPRIN·010 · Principle
- Progressive DisclosurePRIN·003 · Principle