The Access Assumption Audit
Five checks for identifying where products break at the access layer.
Most products are designed for the person the team imagines — a user with reliable internet, a modern device, strong digital literacy, and a clear path to whatever the product is trying to deliver. That user exists. But the gap between that user and the real user is where products fail.
I use the Access Assumption Audit as a lightweight check early in product work — before the interface is designed, during research synthesis, and when reviewing designs before they ship. It is not a compliance checklist. It is a forcing function for asking the right question: who is this product actually for, and under what conditions does it need to work?
The audit has five checks. Each one surfaces a category of assumption that teams routinely make without noticing.
Does this work on a slow or intermittent connection?
Most products are designed on fast Wi-Fi and tested the same way. Real users in schools, clinics, farms, and field offices operate on 2G, shared connections, or no connection at all. The question is not whether the product works online — it is whether it fails gracefully, caches well, and communicates state clearly when connectivity drops.
Does this work on the device the user actually has?
Entry-level Android on a four-year-old phone is not an edge case in most of the markets I design for. It is the median device. Screen size, processing power, storage constraints, and OS version all affect what is possible. Designing only for the reviewer's MacBook is designing for the wrong user.
Does this work in the user's language — including right-to-left layouts and non-Latin scripts?
Internationalisation is often treated as a translation task. It is not. It is a design task. String length changes layouts. RTL text changes visual hierarchy. Local number formats, date conventions, and currency symbols all carry meaning that breaks when localisation is bolted on after the fact.
Does this work for a user with low digital or print literacy?
Icon-only navigation, error messages in technical language, and multi-step flows with no recovery paths are not just UX problems — they are access barriers. Products that assume high digital literacy exclude the populations most likely to benefit from them. Plain language, clear affordances, and forgiving error states are access infrastructure.
Does this actually reach the user through the channel they use?
A web app that requires a stable browser session, an email that requires a verified inbox, a notification that requires push permission — each of these is a delivery assumption. The delivery surface is often the last thing designed and the first thing that breaks. Understanding how the product reaches the user is part of designing the product.
These five checks will not catch everything. But they will surface the assumptions that most product teams make by default — and that is usually enough to change the conversation before the design is locked.
If you are building something where these constraints are real, I would like to talk.