Inclusive design starts by naming who the current design already shuts out

What it is

The persona is young, two-handed, sighted. The first time anyone notices a locked door is a one-star VoiceOver review: a timeout, a control that appears only on hover, an error that is only a colour. Identify exclusion means finding who the product’s assumptions already shut out, then working backward from that person’s task — not drawing an “accessibility persona” as garnish. Microsoft’s inclusive-design framing puts this first: exclusion is something the design did, not a deficit the user brought.

Until “who cannot even start, and which assumption did that” is named, curb-cuts and participatory process have nothing to work on.

Why it happens

Every interface assumes a body, an environment, a usable stretch of time. Once the assumption is written as interaction (a time limit, hover, colour-only, drag-only), people who do not match are not “edge users.” They are people this decision locked out. Starting from the excluded person puts that decision on the table: not a vague “consider disability,” but “this timeout cut whose task.”

The second layer is that averages hide exclusion. In a flow with 85% completion, the blocked 15% may be an entire channel that cannot enter; the mean looks healthy and the door is locked. Identifying exclusion wants the structure of the failures (which input, which sense, which time pressure), not a disability label pasted under the persona. A persona spectrum is a tool here: the same need can land on permanent, temporary, and situational bodies, used to find the assumption — not to freeze three non-communicating requirement docs.

Studying it

Run an exclusion audit: pick a critical task, write “what kind of person cannot even start” and the product assumption that matches (must see, must use a pointer, must finish in five minutes, must hear a chime). Cross-check against real feedback and assistive-technology walkthroughs, and see whether each class on the list is supported by task data.

Independent variables: the task, whether the stated personas include a failure structure, whether the assumption itself was recorded. Dependent variables: whether an excluded group and its assumption can be named, count of exclusion kinds that feedback showed and the audit missed.

Recruiting disabled people is the later participation step; this step can start from task-failure logs and AT walkthroughs to get the assumptions listed. Do not replace exclusion structure with “prevalence of disability” — prevalence answers market size, not where the door is.

Where it stops holding

Security and identity checks deliberately exclude people who did not authenticate; that is not exclusion in the inclusive-design sense. Audit “who must stay out” and “who should get in and cannot” as separate lists. Extremely niche failures unrelated to the product’s purpose (using a photo app to control a nuclear plant) need not be listed. An exclusion list that never changes an assumption decays into an exhibit. On internal tools the “excluded” may be new hires or a visitor role, not a disability diagnosis; the assumption still locks the door.

Applying it

• Attach an exclusion card to every critical task: who cannot start, which assumption (timeout / hover / single channel / single input).
• Ban personas that only contain a successful body; write at least one structure that will fail this task.
• Before a new interaction ships, ask “if this channel or this input is off, does the task still exist.” If the answer is no, log the exclusion before talking solutions.
• How to check: overlay the exclusion card on recent failure reports. A kind that appears in reports but not on the card has not been identified; a kind on the card that has never failed in task data needs the assumption checked, not the card ticked done.

Related

• Same group: J1.05.2 Solving for one person at the edge often produces a curb-cut for many · J1.05.3 People who are excluded belong inside the design process
• Nearby: J1.07 Social model of disability · J1.08 Permanent, temporary and situational disability · A11.08 Situational disability
• Search terms: identify exclusion · inclusive design · persona spectrum