The Access Assumption Audit
The happy path is usually lying to you.
Use this with a product team before a critique, during discovery or when a flow works in the office but keeps failing in the world. Run each check against onboarding, the main transaction and recovery. Rank failures by whether they block access, damage trust or merely create friction.
Connectivity
What happens when the network leaves halfway through? Test the critical flow on a weak connection, interrupt it and inspect what survives.
- Does progress survive interruption?
- Can the user resume without creating duplicates?
- Does the interface explain what happened and who acts next?
- What does failure cost in time or data?
Device
What does this assume about the phone? “Works on mobile” is less useful than knowing which mobile.
- Test an old Android version and a small screen.
- Check low memory, weak cameras and missing biometrics.
- Test the flow on a shared device.
- Name what becomes slower, awkward or impossible.
Language
Where does meaning break when the language changes? Translation is only the beginning.
- Check names, numbers, currency and date conventions.
- Test text expansion and right-to-left reading.
- Remove idioms that carry the instruction.
- Find layouts that depend on one English phrase fitting perfectly.
Literacy
What does the product expect the user to already know? Every product teaches something; the question is whether it knows what it asks people to learn.
- Explain technical and financial language.
- Check whether icons require prior product-pattern knowledge.
- Separate what must be learned now from what can wait.
- Test comprehension, not recognition.
Delivery
Can the user even reach screen one? Sometimes the biggest usability problem happens before the interface exists.
- Check app-store and data access.
- Check payment methods and required documents.
- Test SMS and identity-verification delivery.
- Map the physical, agent and support infrastructure behind the flow.
How I use it
List the conditions the team has quietly assumed, test them against the circumstances of the people expected to use the product and rank what happens when each assumption fails. Some failures block access. Some damage trust. Some merely make the product annoying. That distinction helps a team decide what to fix first.
- Run the audit against onboarding.
- Run it against the main transaction.
- Run it against recovery when something fails.
- Assign an owner and next action to every material assumption.
A happy path is evidence that a flow can work under ideal conditions. The audit asks whether the people the product is for can create those conditions in the first place.