Apply the framework here
In product and UX, the framework’s claim becomes: a system fails legitimacy when “available” paths are unusable under ordinary fatigue, confusion, and time pressure.
This page converts the framework into practical design diagnostics for support, appeals, settings, account recovery, and error states.
Recognition
Common misdescription in this field
Misdescriptions that keep friction invisible.
Teams equate surface availability with usability.
- Path is technically present but discoverability is low.
- Recovery requires detective work.
- Exit rates are framed as user preference.
Interpretive burden and jargon debt are privatized onto users.
- Ambiguous copy creates avoidable mistakes.
- Users must infer policy from edge-case behavior.
- Support scripts preserve policy opacity.
Operational diagnostics
What to measure instead
Measure completion and repair under stress, not nominal path existence.
Recourse clarity: can users identify the next recoverable step quickly?
Instrument resolution pathways, not just funnel starts.
Burden count: how many steps to restore baseline function?
Count repeats, redirects, and handoffs needed for correction.
Interpretive load: how much translation is required?
Test with ordinary users under realistic stress and partial attention.
Failure dynamics
Typical failure pathway (how people fall out)
Common failure pathway in product/service systems.
Interventions
Design/legal/operational fixes
Fixes should be structural and testable.