Claude Cursor Skill

inclusive-design

Use when working on inclusion, i18n/localization, global name/address forms, low-end devices, slow/metered networks, affordability, or first-time/low-confidence users; not WCAG/screen readers (see accessibility).

LLM Mart · 0 points · 13 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download evanca-flutter-ai-rules-skills_inclusive-design-7d226d8.zip · 12 KB
Part of evanca/flutter-ai-rules — 37 skills

Install

skills CLI npx skills add https://github.com/evanca/flutter-ai-rules/tree/main/skills/inclusive-design
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install evanca-flutter-ai-rules@llmmart
Git git clone https://github.com/evanca/flutter-ai-rules.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole evanca/flutter-ai-rules collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Inclusive Design

Inclusive design answers a different question from accessibility:

Does this respect the real-world context, identity, language, culture, device, confidence level, and constraints of the person using it?

Accessibility asks whether someone can operate the interface with their abilities and assistive tools. Inclusion asks who gets left out by the assumptions baked into the product — the person on a $40 phone over a metered 2G connection, the person whose name doesn't fit your form, the person reading in their third language, the person who has never done this online before and is afraid of getting it wrong. WCAG conformance does not address any of that. This skill does.

Per W3C, accessibility, usability, and inclusion overlap but each has a distinct focus: accessibility targets disability, usability targets the quality of the experience (effective, efficient, satisfying), and inclusion targets the full breadth of human diversity — hardware and software, literacy, economic situation, education, geography, culture, age, and language.

When to use

Use this skill when the work is about who you might be excluding and why — not about a specific assistive-tech bug. Triggers: reviewing a design "through an inclusive lens," building personas, internationalization/localization, designing name/address/profile forms for a global audience, supporting low-end devices or poor connectivity, lowering cost/data barriers, onboarding nervous or first-time users, reducing stress and cognitive load, or any "are we leaving anyone out?" conversation.

When not to use it: if the task is screen-reader support, keyboard navigation, focus order, color contrast, alt text, ARIA, captions, or passing WCAG — that's the accessibility skill. The two are partners; pick by focus.

The core mental model

1. Disability — and exclusion in general — is a mismatch, not a trait

The social model reframes disability as a mismatch between a person and their environment, product, or society — not a deficiency in the person. As August de los Reyes put it:

"The biggest challenge is reframing disability as a mismatch between one's abilities and the environment. In other words, disability is designed."

The empowering corollary: if mismatches are designed, they can be un-designed. The same logic extends past disability to every exclusion in this skill — a form that rejects a valid name, an app that needs more bandwidth than a user can afford, copy only a fluent reader can parse. Each is a designed mismatch you can remove. Microsoft states it as: disability = mismatched human interactions.

2. Microsoft's three principles of inclusive design

  • Recognize exclusion. "Exclusion happens when we solve problems using our own biases." Start by finding who your current solution shuts out.
  • Learn from diversity. "Human beings are the real experts in adapting to diversity." The people at the edges are the source of insight, not an afterthought.
  • Solve for one, extend to many. Design a great solution for one excluded person by "focusing on what's universally important to all humans" — and it tends to help everyone. Captions (built for Deaf users) help in loud airports and teach kids to read; high-contrast modes (built for low vision) help everyone in bright sun. Build for one, benefit many.

3. The Persona Spectrum

A constraint is rarely permanent-only. Microsoft's Persona Spectrum maps each limitation across permanent, temporary, and situational states — which both grows the affected population enormously and reveals the universal need:

Ability Permanent Temporary Situational
Touch (one arm) amputation broken arm a new parent holding a baby
See blindness cataracts / eye dilation driving; bright sunlight
Hear deafness ear infection a loud bar; a quiet library
Speak non-verbal laryngitis a heavy accent on voice UI

"We use the Persona Spectrum to understand related mismatches and motivations across a spectrum of permanent, temporary, and situational scenarios."

The scaling is the point: ~26,000 Americans a year experience permanent upper-limb loss, but counting temporary and situational impairments the number is more than 20 million. Designing for the edge serves the middle.

How to run an inclusion review

Go dimension by dimension and ask "who does this assume, and who does that leave out?" Each dimension has a reference file with the depth.

  1. Language & culture — Is content translatable and localizable? Do name, address, date, number, and currency formats assume one culture? Do forms assume everyone has a first + last name? → references/language-and-culture.md
  2. Device, network & economics — Does it work on a cheap, old, small-screen phone over a slow, metered connection? Does it assume always-on connectivity, the latest hardware, or that data is free? Is there a low-bandwidth or offline path? → references/digital-and-economic-inclusion.md
  3. Confidence, stress & cognitive load — Does it respect that the user may be anxious, distracted, new, or low on mental energy? Does it give control, celebrate progress, and forgive mistakes rather than blame the user? → references/cognitive-load-and-wellbeing.md
  4. Identity & life stage — Does it represent diverse people respectfully (names, genders, family structures, skin tones, examples)? Does it work for the very young, the very old, and the first-time-online?
  5. Recognize your own exclusion — Whose biases shaped the defaults? Who wasn't in the room? Build a Persona Spectrum for the riskiest constraint and design for its edge.

For the philosophy, principles, Persona Spectrum activities, and the accessibility/usability/inclusion distinction in full, see references/frameworks.md.

A note on doing this well

Inclusion is not a checklist you complete; it's a habit of noticing your assumptions. The fastest way to find exclusion is to stop designing for an "average user" (who doesn't exist) and instead pick a specific person at the edge — someone unlike you in language, income, device, or confidence — and walk your flow as them. The friction they hit is the design's, not theirs.

References

Primary sources:

Files (flutter-ai-rules)
  • references
    • cognitive-load-and-wellbeing.md 4.5 KB
      # Cognitive Load & Wellbeing
      
      This is the *human-state* dimension of inclusion: the person using your product may be stressed, distracted, exhausted, anxious, grieving, new to the task, or simply low on mental energy today. None of that is a disability — it's the normal range of being human — and it changes from hour to hour. Designing for it is about respecting confidence, attention, and emotional state.
      
      > Scope note: the *disability*-focused, pattern-level version of this material (for diagnosed cognitive and learning disabilities) lives in the **accessibility** skill's `cognitive-accessibility.md` (W3C COGA). This file is the inclusion-side framing: everyday cognitive load, motivation, and wellbeing for everyone.
      
      ## Mental state is in constant flux — for all of us
      
      Source: [Inclusive Design for Cognition Guidebook — Microsoft](https://inclusive.microsoft.design/articles/inclusive-design-for-cognition-guidebook)
      
      Microsoft defines cognition as "a range of mental processes that acquire, store, manipulate, and retrieve information," and stresses that everyone's cognitive capacity shifts with context: a task that is "entirely doable and even easy at a less stressful time" can feel impossible under stress. Cognitive diversity therefore "includes everyone, from people with diagnosed medical conditions to those in temporary situations."
      
      The governing principle (attributed to Dr. Bruce Baker):
      
      > "For any task to be successful, motivation must equal or surpass cognitive load."
      
      So you have two levers on every screen: **lower the cognitive load**, and **protect the user's motivation**. The guidebook breaks cognitive demand into five types worth designing for:
      
      - **Learning** — offer guidance *in each step*; don't make people leave the task to find help; don't assume prior knowledge.
      - **Focus** — help people tune in and out as needed; respect the cost of interruption; support task-switching and sustained attention.
      - **Decision-making** — make the critical factors and consequences of each choice clear (e.g., flag data loss or cost before it happens).
      - **Recall** — don't assume people remember a task after doing it once; support the systems people use to place, remember, and find things; keep step-sequences short.
      - **Communication** — adapt tone, frequency, and format over time (real-time tips for newcomers, fewer for experts) and offer multiple formats (visual *and* written).
      
      ## Protecting motivation and agency
      
      Source: [Mental Health Guidebook — Microsoft](https://inclusive.microsoft.design/articles/mental-health-guidebook)
      
      The emotional stakes are real:
      
      > "When we fail to help people feel successful and in control, they frequently blame themselves. This emotional state can reduce motivation, focus, and interest."
      
      And capacity genuinely fluctuates: "a task may feel impossible at the moment, but it is doable once the stress has passed." The design job is to meet people on their lowest-capacity day, not their best. Concrete moves, grouped as Microsoft does:
      
      **Preserve** (protect attention and motivation)
      - "Ensure notifications are controllable, actionable, succinct, and relevant to the task." Unregulated notification disruption is "detrimental to cognition and mental health."
      - "Celebrate small wins!" — helping people feel good about themselves and the product maintains motivation.
      - Support clear navigation, minimal interruptions, and reduced complexity.
      
      **Direct** (lower the path's difficulty)
      - "Track progress and make next steps easy to identify and complete."
      - "Surface settings within the flow" so people don't have to hunt.
      - "Provide predictable ways for people to find additional support."
      
      **Customize** (give control back to the user)
      - "Allow people to retain preferences across sessions."
      - "Provide options for readability and appearance."
      - "Introduce new features contextually" rather than dumping everything at once.
      
      ## How to apply this in a review
      
      1. **Find the highest-load moment** in the flow (a long form, a multi-step decision, a setup wizard) and cut steps, defer non-essential choices, and remove anything the user must hold in memory between screens.
      2. **Audit interruptions.** Is every notification, modal, and tooltip earning its place? Can the user control them?
      3. **Check the failure path.** When something goes wrong, does the design blame the user or help them recover calmly? Replace dead-ends and scolding copy with a clear, reassuring way forward.
      4. **Give control.** Can people save progress, change their mind, adjust appearance, and keep those preferences? Agency is what turns a stressful tool into a usable one.
      
    • digital-and-economic-inclusion.md 4.1 KB
      # Digital & Economic Inclusion
      
      This dimension is about the people your product never reaches because of *what they can afford, what device they hold, and how connected and confident they are* — not their abilities. It's the most commonly forgotten axis of inclusion because design and dev teams almost always work on fast hardware over fast, free networks.
      
      ## What digital inclusion means
      
      Source: [Digital Inclusion Action Plan: First Steps — UK Government](https://www.gov.uk/government/publications/digital-inclusion-action-plan-first-steps/digital-inclusion-action-plan-first-steps)
      
      > Digital inclusion is "ensuring that everyone has the access, skills, support and confidence to participate in and benefit from our modern digital society, whatever their circumstances."
      
      Note that *access* is only one of four parts — skills, support, and confidence matter just as much, and a product can fail people on any of them.
      
      ### The barriers, as the UK plan frames them
      
      - **Skills** — digital competencies and access to training. About a quarter of the UK population has the lowest level of digital capability.
      - **Data & device poverty** — affordable, reliable connectivity and a suitable device. 37% of offline households cite lack of equipment as a barrier; 6% of UK households have no home internet at all.
      - **Accessible services** — usable services *with a non-digital alternative path* for those who can't or won't go online.
      - **Confidence & local support** — understanding the benefit of being online, trusting that it's safe, and having in-person help nearby. Lack of interest/motivation (69% of those without home internet) and distrust are real barriers, not just cost.
      
      Who is most affected: low-income households, older people, disabled people, the unemployed, and young people not in education or work. Digital exclusion compounds economic exclusion — among the digitally excluded, unemployment runs far above the national average. The plan frames this as requiring "long term, systemic change," not a one-off feature.
      
      ## The global, intersectional view
      
      Source: [Digital Inclusion — ITU](https://www.itu.int/en/ITU-D/Digital-Inclusion/Pages/about.aspx)
      
      > "Digital inclusion begins with ICT accessibility as a foundational requirement and succeeds only through a holistic, intersectional, and intersectoral approach" — toward "ensuring that all people, everywhere, can meaningfully use technology and participate in the digital economy, society, and environment."
      
      Two things to take from ITU:
      
      1. **Accessibility is the foundation, not the whole.** You start with accessibility and build inclusion on top — exactly the relationship between the two skills.
      2. **The barriers intersect.** A person is rarely excluded on one axis. ITU emphasizes women and girls, older persons, persons with disabilities, young people and children, and people in rural, remote, and Indigenous communities — and an individual often sits at several of these at once. Design for the intersections.
      
      ## What this means in design and engineering
      
      - **Test on a real low-end device over a throttled, metered connection** — not a flagship phone on office Wi-Fi. Measure payload size, time-to-interactive, and data cost per session.
      - **Degrade gracefully.** Provide a usable experience without the latest hardware, large downloads, or constant connectivity. Consider offline support, lightweight/low-bandwidth modes, and not auto-loading heavy media.
      - **Respect data as money.** Don't silently consume large amounts of data; let users control downloads, autoplay, and sync.
      - **Don't assume the latest OS, big screens, or high-end GPUs.** Support older versions and small screens.
      - **Lower the confidence barrier.** First-time and low-confidence users need plain-language onboarding, reassurance that they can't break anything, visible help, and trust signals about safety and privacy. (This connects to [cognitive-load-and-wellbeing.md](cognitive-load-and-wellbeing.md).)
      - **Keep a non-digital or low-tech path** where the service is essential — a phone number, an in-person option — so going digital-only doesn't strand people.
      
    • frameworks.md 6 KB
      # Inclusive Design Frameworks
      
      ## Accessibility vs. usability vs. inclusion
      
      Source: [Accessibility, Usability, and Inclusion — W3C WAI](https://www.w3.org/WAI/fundamentals/accessibility-usability-inclusion/)
      
      Three overlapping ideas, three different focuses:
      
      - **Accessibility** — focus: **disability**. "Web accessibility means that people with disabilities can equally perceive, understand, navigate, and interact with websites and tools."
      - **Usability** — focus: **experience quality**. "Usability is about designing products to be effective, efficient, and satisfying." (Not specific to disability.)
      - **Inclusion** — focus: **breadth of diversity**. "Inclusion is about diversity, and ensuring involvement of everyone to the greatest extent possible." It spans far beyond disability: hardware and software, literacy, economic situation, education, geography, culture, age, and language.
      
      They overlap heavily, which is why teams conflate them — but treating inclusion as "just accessibility" loses the context, identity, and economic dimensions, and treating accessibility as "just inclusion" lets concrete disability needs go unmet. Keep both.
      
      ## The mismatch model (social model of disability)
      
      Sources: [DevOps Dojo — UX/Accessibility, Microsoft](https://devblogs.microsoft.com/devops/devops-dojo-ux-accessibility/) · [From disabled to super-abled — Microsoft News](https://news.microsoft.com/en-xm/features/disabled-super-abled-help-technology/) · [Inclusive 101 Guidebook — Microsoft](https://inclusive.microsoft.design/articles/inclusive-101-guidebook)
      
      Disability is not a fixed property of a person; it emerges at the point of interaction between a person and a world that wasn't built for them.
      
      > WHO, as cited by Microsoft: "Disability is not just a health problem. It is a complex phenomenon, reflecting the interaction between features of a person's body and features of the society in which he or she lives."
      
      Microsoft compresses this to an equation:
      
      > **"Disability = mismatched human interactions."**
      
      And August de los Reyes draws out the designer's responsibility:
      
      > "The biggest challenge is reframing disability as a mismatch between one's abilities and the environment. In other words, disability is designed."
      
      The practical power of this framing: a mismatch is something *you made* and therefore something *you can unmake*. It moves the work from "accommodating broken people" to "fixing a broken environment," and it generalizes — anything that excludes (language, cost, device, confidence) is a designed mismatch you can remove.
      
      Context for scale: per WHO (as cited by Microsoft), over **1 billion people — about 15% of the world** — live with some form of disability; roughly **70% of disabilities are invisible**; and only about **1 in 10** people who need assistive technology have access to it.
      
      ## The three principles
      
      Source: [Inclusive 101 Guidebook — Microsoft](https://inclusive.microsoft.design/articles/inclusive-101-guidebook)
      
      1. **Recognize exclusion.** "Exclusion happens when we solve problems using our own biases." Designers unconsciously build for people like themselves; the first move is to find who that shuts out.
      2. **Learn from diversity.** "Human beings are the real experts in adapting to diversity." People living with constraints have already invented workarounds — treat them as co-designers, not test subjects.
      3. **Solve for one, extend to many.** Solve deeply for one excluded person by "focusing on what's universally important to all humans," and the solution radiates outward. This is the curb-cut effect:
         - **Closed captions** — built for the Deaf community; now used to watch video in loud airports and silent offices, and to teach children to read.
         - **High-contrast / dark modes** — built for low vision; used by everyone in bright sunlight.
         - Other "designed for one, used by all" examples Microsoft cites: remote controls, automatic door openers, audiobooks, and email.
      
      ## The Persona Spectrum
      
      Sources: [Inclusive 101 Guidebook](https://inclusive.microsoft.design/articles/inclusive-101-guidebook) · [Inclusive Activity Cards](https://inclusive.microsoft.design/articles/inclusive-activity-cards)
      
      > "We use the Persona Spectrum to understand related mismatches and motivations across a spectrum of permanent, temporary, and situational scenarios."
      
      Every ability constraint exists in three states, and naming all three both multiplies the affected population and exposes the universal need:
      
      | Ability area | Permanent | Temporary | Situational |
      |---|---|---|---|
      | **Touch** | amputation / one arm | a broken arm | a new parent holding an infant |
      | **See** | blindness | cataracts, eye dilation | driving; bright sunlight |
      | **Hear** | deafness | an ear infection | a loud bar; a quiet library |
      | **Speak** | non-verbal | laryngitis | a strong accent on a voice UI |
      
      The canonical stat: ~26,000 Americans/year experience permanent upper-extremity loss, but "when we include people with temporary and situational impairments, the number is greater than 20 million." The edge case *is* the mass market once you add time and context.
      
      ### Using it in practice (Microsoft Inclusive Activity Cards)
      
      Source: [Inclusive Activity Cards — Microsoft](https://inclusive.microsoft.design/articles/inclusive-activity-cards)
      
      Microsoft's activity cards turn the philosophy into design-process moves across five phases — Get Oriented, Frame, Ideate, Iterate, Optimize. The most reusable activities:
      
      - **Create a Persona Spectrum** — take your riskiest constraint and lay out its permanent/temporary/situational versions before designing.
      - **Mismatch to Solution** — name the specific mismatch, then design it away.
      - **Context and Capability Match / Situational Adaptation** — check whether the design holds up as the user's context shifts (one-handed, distracted, outdoors, offline).
      - **Human Analogy** — borrow how people already solve the problem in the physical world.
      
      The throughline: don't design for a statistical "average user." Pick a real person at the edge, build for them, and extend.
      
    • language-and-culture.md 4.2 KB
      # Language & Culture Inclusion
      
      ## Internationalization vs. localization
      
      Source: [Localization vs. Internationalization — W3C](https://www.w3.org/International/questions/qa-i18n)
      
      Two distinct jobs, often confused:
      
      - **Internationalization (i18n)** — "the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language." It's the *architecture* that makes adaptation possible — no hard-coded strings, externalized text, Unicode throughout, layouts that survive text expansion and right-to-left scripts.
      - **Localization (l10n)** — "the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market." It's the *adaptation itself*.
      
      Do the internationalization work up front; retrofitting it later is expensive. Localization then covers far more than translated strings:
      
      - Language and UI text translation
      - Cultural elements — symbols, icons, colors, imagery (these carry different meanings across cultures)
      - Number, date, and time formats
      - Currency
      - Collation and sorting order
      - Personal names and forms of address
      - Keyboard configurations
      - Region-specific legal requirements
      
      W3C notes that when business practices or learning paradigms differ between cultures, localization can require a comprehensive redesign — not just a string swap. Plan for that.
      
      ## Inclusive name handling
      
      Sources: [Personal names around the world — W3C](https://www.w3.org/International/questions/qa-personal-names) · [Personal names (techniques) — W3C](https://www.w3.org/International/techniques/authoring-html)
      
      Name and form fields are where well-meaning products quietly tell people "you don't fit." Most form designs encode a single culture's naming assumptions. The reality:
      
      - **Not everyone has a given-name + family-name structure.** "In cultures such as parts of Southern India, Malaysia and Indonesia, a large number of people have names that consist of a given name only, with no patronym."
      - **Family-name order varies.** Chinese, Japanese, and many other names put the family name first.
      - **Family members don't always share a surname.** "It would be wrong to assume that members of the same family share the same family name."
      - **Single-letter names are real.** "Don't assume that a single letter name is an initial. People do have names that are one letter long."
      - **Most of the world isn't in ASCII.** A large majority of people don't use the Latin alphabet, and of those who do, many use accents and characters that don't occur in English.
      
      ### Practical form-design rules
      
      - **Question separate fields.** "Ask yourself whether you really need to have separate fields for given name and family name." A single full-name field is the most inclusive default; only split when you have a concrete need.
      - **If you must split, add fields rather than carve up the name.** "Consider whether it would make sense to have one or more extra fields, in addition to the full name field, where you ask the user to enter the part(s) of their name that you need."
      - **Avoid culture-bound labels.** "Try to avoid using the labels 'first name' and 'last name' in non-localized forms." If you do split, "ensure that you label clearly which parts you want where."
      - **Ask how people want to be addressed.** "Ask separately, when setting up a profile for example, how that person would like you to address them." Don't algorithmically guess a greeting from a name field.
      - **Give names room.** "Make input fields long enough to enter long names, and ensure that if the name is displayed on a web page later there is enough space for it." / "Avoid limiting the field size for names in your database."
      - **Use Unicode end to end.** "If you do accept non-ASCII names, you should use a Unicode character encoding (eg. UTF-8) in your pages, your back end databases and in all the software code in between."
      
      ### Quick test
      
      Try entering these into your form and database: a mononym (one name only), a name with the family name first, a name with diacritics or non-Latin script, a single-letter name, and a very long name. If any of them can't be entered, stored, or displayed back correctly, the form is excluding real people.
      
  • SKILL.md 7.7 KB
    ---
    name: inclusive-design
    description: "Use when working on inclusion, i18n/localization, global name/address forms, low-end devices, slow/metered networks, affordability, or first-time/low-confidence users; not WCAG/screen readers (see accessibility)."
    license: MIT
    ---
    
    # Inclusive Design
    
    Inclusive design answers a different question from accessibility:
    
    > **Does this respect the real-world context, identity, language, culture, device, confidence level, and constraints of the person using it?**
    
    Accessibility asks whether someone *can operate* the interface with their abilities and assistive tools. Inclusion asks who gets *left out* by the assumptions baked into the product — the person on a $40 phone over a metered 2G connection, the person whose name doesn't fit your form, the person reading in their third language, the person who has never done this online before and is afraid of getting it wrong. WCAG conformance does not address any of that. This skill does.
    
    Per W3C, accessibility, usability, and inclusion overlap but each has a distinct focus: accessibility targets **disability**, usability targets the **quality of the experience** (effective, efficient, satisfying), and inclusion targets the **full breadth of human diversity** — hardware and software, literacy, economic situation, education, geography, culture, age, and language.
    
    ## When to use
    
    Use this skill when the work is about *who you might be excluding and why* — not about a specific assistive-tech bug. Triggers: reviewing a design "through an inclusive lens," building personas, internationalization/localization, designing name/address/profile forms for a global audience, supporting low-end devices or poor connectivity, lowering cost/data barriers, onboarding nervous or first-time users, reducing stress and cognitive load, or any "are we leaving anyone out?" conversation.
    
    **When *not* to use it:** if the task is screen-reader support, keyboard navigation, focus order, color contrast, alt text, ARIA, captions, or passing WCAG — that's the **accessibility** skill. The two are partners; pick by focus.
    
    ## The core mental model
    
    ### 1. Disability — and exclusion in general — is a *mismatch*, not a trait
    
    The social model reframes disability as a mismatch between a person and their environment, product, or society — not a deficiency in the person. As August de los Reyes put it:
    
    > "The biggest challenge is reframing disability as a mismatch between one's abilities and the environment. In other words, **disability is designed**."
    
    The empowering corollary: if mismatches are designed, they can be *un*-designed. The same logic extends past disability to every exclusion in this skill — a form that rejects a valid name, an app that needs more bandwidth than a user can afford, copy only a fluent reader can parse. Each is a designed mismatch you can remove. Microsoft states it as: *disability = mismatched human interactions.*
    
    ### 2. Microsoft's three principles of inclusive design
    
    - **Recognize exclusion.** "Exclusion happens when we solve problems using our own biases." Start by finding who your current solution shuts out.
    - **Learn from diversity.** "Human beings are the real experts in adapting to diversity." The people at the edges are the source of insight, not an afterthought.
    - **Solve for one, extend to many.** Design a great solution for one excluded person by "focusing on what's universally important to all humans" — and it tends to help everyone. Captions (built for Deaf users) help in loud airports and teach kids to read; high-contrast modes (built for low vision) help everyone in bright sun. Build for one, benefit many.
    
    ### 3. The Persona Spectrum
    
    A constraint is rarely permanent-only. Microsoft's Persona Spectrum maps each limitation across **permanent, temporary, and situational** states — which both grows the affected population enormously and reveals the universal need:
    
    | Ability | Permanent | Temporary | Situational |
    |---|---|---|---|
    | Touch (one arm) | amputation | broken arm | a new parent holding a baby |
    | See | blindness | cataracts / eye dilation | driving; bright sunlight |
    | Hear | deafness | ear infection | a loud bar; a quiet library |
    | Speak | non-verbal | laryngitis | a heavy accent on voice UI |
    
    > "We use the Persona Spectrum to understand related mismatches and motivations across a spectrum of permanent, temporary, and situational scenarios."
    
    The scaling is the point: ~26,000 Americans a year experience permanent upper-limb loss, but counting temporary and situational impairments the number is **more than 20 million**. Designing for the edge serves the middle.
    
    ## How to run an inclusion review
    
    Go dimension by dimension and ask "who does this assume, and who does that leave out?" Each dimension has a reference file with the depth.
    
    1. **Language & culture** — Is content translatable and localizable? Do name, address, date, number, and currency formats assume one culture? Do forms assume everyone has a first + last name? → [references/language-and-culture.md](references/language-and-culture.md)
    2. **Device, network & economics** — Does it work on a cheap, old, small-screen phone over a slow, metered connection? Does it assume always-on connectivity, the latest hardware, or that data is free? Is there a low-bandwidth or offline path? → [references/digital-and-economic-inclusion.md](references/digital-and-economic-inclusion.md)
    3. **Confidence, stress & cognitive load** — Does it respect that the user may be anxious, distracted, new, or low on mental energy? Does it give control, celebrate progress, and forgive mistakes rather than blame the user? → [references/cognitive-load-and-wellbeing.md](references/cognitive-load-and-wellbeing.md)
    4. **Identity & life stage** — Does it represent diverse people respectfully (names, genders, family structures, skin tones, examples)? Does it work for the very young, the very old, and the first-time-online?
    5. **Recognize your own exclusion** — Whose biases shaped the defaults? Who wasn't in the room? Build a Persona Spectrum for the riskiest constraint and design for its edge.
    
    For the philosophy, principles, Persona Spectrum activities, and the accessibility/usability/inclusion distinction in full, see [references/frameworks.md](references/frameworks.md).
    
    ## A note on doing this well
    
    Inclusion is not a checklist you complete; it's a habit of noticing your assumptions. The fastest way to find exclusion is to stop designing for an "average user" (who doesn't exist) and instead pick a specific person at the edge — someone unlike you in language, income, device, or confidence — and walk your flow as them. The friction they hit is the design's, not theirs.
    
    ## References
    
    - [references/frameworks.md](references/frameworks.md) — the 3 principles, Persona Spectrum, the mismatch model, and the accessibility vs. usability vs. inclusion distinction, with sources.
    - [references/language-and-culture.md](references/language-and-culture.md) — internationalization vs. localization, and inclusive name/form handling for a global audience.
    - [references/digital-and-economic-inclusion.md](references/digital-and-economic-inclusion.md) — device, connectivity, affordability, skills, and confidence barriers (UK Gov + ITU framing).
    - [references/cognitive-load-and-wellbeing.md](references/cognitive-load-and-wellbeing.md) — motivation, stress, focus, memory, notifications, and agency (Microsoft cognition + mental health).
    
    Primary sources:
    
    - [Inclusive 101 Guidebook — Microsoft](https://inclusive.microsoft.design/articles/inclusive-101-guidebook)
    - [Accessibility, Usability, and Inclusion — W3C WAI](https://www.w3.org/WAI/fundamentals/accessibility-usability-inclusion/)
    - [Digital Inclusion — ITU](https://www.itu.int/en/ITU-D/Digital-Inclusion/Pages/about.aspx)
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related