Framework ⚡ Medium

Inclusive Design

Design with the people most likely to be excluded — and you make the product better for everyone.

Accessibility Diversity in Research Marginalised Users Product Equity Representation Edge Cases

01 — TL;DR

Two sentences.

Inclusive Design is a methodology that treats the active participation of people most likely to be excluded by a product as the primary source of design insight — not as a compliance checkbox or a last-mile accommodation. Design with the people who face the greatest mismatch between their abilities and the environment, and you make the product better for everyone on the inclusion spectrum.

The framework was developed most rigorously by Kat Holmes, whose book Mismatch (2018) reframes disability as a mismatch between a person and their environment rather than a personal deficit. The critical distinction from Universal Design — which shares the same goal of broad usability — is that Inclusive Design is a process orientation, not a product specification. Universal Design describes what the outcome should look like; Inclusive Design describes who should be in the room while you are designing it and how their participation changes what you build.

02 — When to Use

Apply this when…

→ Your research participants all come from the same demographic profile — same age range, same ability level, same tech fluency — and your product serves a much broader population

→ An accessibility audit has revealed failures that were invisible during design — a signal that excluded users were not represented in the design process

→ You are building a product intended to serve a broad population — consumer apps, public services, enterprise tools with diverse workforces — where edge-case users are actually a large percentage of real users

→ A team culture audit shows missing groups in decision-making — the people building the product do not reflect the people using the product

→ You are designing sensitive features — identity, health, financial hardship, safety — where the cost of getting it wrong falls disproportionately on already-marginalised users

→ You are entering a new market or context where your existing assumptions about user needs, abilities, and constraints may not hold

When to skip it

There is no scenario where you should skip it. Inclusive Design is not a method you add to a project — it is a process orientation that shapes how you run every other method. It does not require additional budget or timeline; it requires asking different questions about who is in the room and whose experience you are measuring. If you are doing research at all, you can do inclusive research.

03 — How It Works

The mechanism

Inclusive Design works by recognising that exclusion is not a natural property of users — it is produced by design decisions. When a product works for some people and not others, the mismatch lives in the design, not in the person. The framework operates through four interlocking mechanisms that shift who participates in the design process and how the team measures success.

Exclusion is produced by design, not by disability

Holmes' social model of disability reframes the problem entirely: a person is not "disabled" in the abstract — they experience disability when the environment creates a mismatch with their abilities. A one-armed person, a person with a broken arm, and a parent holding a baby all experience the same functional exclusion from a two-handed interface. The design created the exclusion in all three cases. This reframing is not academic — it changes what you measure, who you recruit, and what counts as a successful outcome.

The inclusion spectrum and who is in the room

Every exclusion exists on a spectrum: permanent (one arm), temporary (broken arm), and situational (holding a child). The inclusion spectrum is the core analytical tool of Inclusive Design — it reveals that designing for the permanent case simultaneously solves for temporary and situational users, dramatically expanding the population served. The process question is equally critical: if the people most affected by a design decision are not in the room when the decision is made, the result will reflect the biases and assumptions of whoever is.

Designing for the margin improves the core

Curb cuts were designed for wheelchair users and now serve parents with pushchairs, travellers with suitcases, and delivery workers with trolleys. Closed captions were designed for Deaf viewers and now serve people in noisy airports, language learners, and anyone watching video on mute. This is not a coincidence — it is the predictable result of designing for the most constrained use case. When you solve for the margin, you create solutions that work better for everyone because you have removed friction that the core user tolerated but did not enjoy.

Measurement: inclusion index, representation rate, exclusion audit

Inclusive Design is not effective without measurement. Three metrics make it actionable: the inclusion index tracks what percentage of your user base can complete core tasks without workarounds; the research representation rate measures whether your research participants reflect the diversity of your actual user base; and exclusion audit scores identify specific interaction points where users are forced to adapt to the product rather than the product adapting to them. If you cannot answer "who does this design exclude?" with data, you are guessing.

Edge users, not average users

Inclusive Design is not about designing for the average user and then adding diversity on top. It is about starting from the edges — the people whose needs are most constrained — and working inward. The average user is a statistical fiction; real users exist on a spectrum of ability, context, and constraint. Products designed for the average exclude the majority by definition, because no individual user is actually average across all dimensions.

04 — Real Example

Microsoft AI captioning and Deaf co-design

When Microsoft built AI-powered live captions for Teams meetings, the initial feature was functional but fell short for the users who needed it most. Captions appeared as a running text stream with no speaker identification — usable for hearing users glancing at subtitles, but inadequate for Deaf and hard-of-hearing participants who relied on captions as their primary channel. Without speaker labels, following a multi-person conversation was nearly impossible.

Microsoft's Inclusive Design team brought Deaf employees and external Deaf community members into the co-design process — not as testers validating a finished feature, but as design partners shaping the requirements. The insight that changed everything: speaker labels were not a "nice-to-have" enhancement but the primary requirement for the feature to function at all. The co-design sessions also surfaced needs for caption positioning, font sizing, and colour contrast that the original hearing-majority team had not considered. The result was a captioning system that worked better for everyone — hearing users in noisy environments, non-native speakers, and people processing auditory information differently all benefited from the improvements that Deaf co-designers drove.

Microsoft · Teams · 2020-2022

Deaf co-design surfaces what hearing-majority teams miss

Speaker labels became the #1 requested caption feature across all users

05 — In the Wild

Test yourself & see real examples

No examples yet — be the first.

Spotted a product team that nailed inclusive co-design — or shipped without consulting the users most affected? Submit what the team learned, or what they missed. Every approved example gets attributed to you.

✓ Reviewed before publishing ✓ Your name on every example you submit ✓ Violation or fix — both welcome

Seen Inclusive Design violated in a real product? Help grow the evidence base.

06 — Common Mistakes

Where teams go wrong

✗ Treating inclusion as a post-design audit. The most common failure mode: the team designs the product with their usual process, then runs an "inclusion review" at the end to catch problems. This is accessibility compliance, not Inclusive Design. By the time the audit happens, the fundamental architecture, interaction patterns, and information hierarchy are locked. You are not designing inclusively — you are retrofitting exclusion. Inclusive Design means the excluded users shape the requirements, not just review the output.

✗ Recruiting diverse participants but asking them the same questions. Teams add demographic diversity to their research panels and consider the job done. But if the interview guide, the task scenarios, and the success metrics were designed by and for the majority use case, diverse participants will simply confirm the existing design direction. Inclusive research requires different questions — not just different people. Ask what workarounds they use. Ask what they have stopped trying to do. Ask what the product assumes about their abilities that is wrong.

✗ Conflating Inclusive Design with legal compliance. WCAG conformance and ADA compliance are necessary but nowhere near sufficient. Meeting accessibility standards means your product does not actively exclude people with documented disabilities — it does not mean the product was designed with their participation, serves their actual needs, or provides an equivalent experience. Teams that treat WCAG as the ceiling of inclusion rather than the floor have confused legal risk management with design quality.

✗ Making inclusion a marketing claim without a process change. "We believe in inclusive design" on a company blog means nothing without evidence of who was in the room, whose feedback changed the design, and what was measured. Inclusive Design is a verifiable process, not a brand value. If you cannot point to specific design decisions that changed because of excluded users' participation, you are performing inclusion rather than practising it.

07 — Variations & Related Principles

Connected ideas

Inclusive Design is a process lens that reshapes how you apply other frameworks and methods. The principles below either share its goal through a different mechanism, raise the question of whose experience counts, or explain why designing for the margin produces better outcomes for everyone.

The most important pairing in this list is Inclusive Design with Human-Centered Design. HCD provides the structural process — research, synthesis, prototype, test — but leaves open the question of whose experience is centred. Inclusive Design answers that question directly: centre the people most likely to be excluded. Without that specificity, HCD defaults to designing for the majority, which is precisely the pattern that produces exclusion in the first place.

08 — 10-Min Exercise

Run it right now

⏱ 10 minutes · Team · No prep

The Exclusion Audit

Pick the most important screen or flow in your current product.

1. Write down who this screen was designed for — be specific about assumed abilities, context, and device. Most teams will discover the implicit user is a sighted, hearing, two-handed, English-speaking adult on a modern smartphone with a fast connection.

2. Write down three types of users who are excluded or disadvantaged by this screen. Use the inclusion spectrum: for each exclusion, identify the permanent, temporary, and situational versions. For example: cannot see the screen (blind / eye infection / bright sunlight).

3. For each excluded user type, identify the specific interaction point where the difficulty occurs. Is it a colour-only status indicator? A drag-and-drop interaction? A time-limited action? A text-heavy onboarding flow? Name the exact element.

4. For the top exclusion, write one design change that would solve for the permanent case — and then check whether that change would also improve the experience for the temporary and situational cases. If it does, you have found a curb-cut opportunity. If it does not, the solution is an accommodation, not an inclusive redesign.

10 minutes