Inclusive Design

Inclusive Design ("Designing from the Margins")

This skill helps design from the margins — starting with the people a product would otherwise exclude — because a design that works at the edges works better for everyone at the center. It covers two connected jobs: reviewing a design for who it excludes and how to widen it, and reviewing or rewriting copy to be more inclusive. Use either or both.

The single most important thing this skill does is bring judgment, not rules. Inclusive design done badly becomes performative box-ticking or heavy-handed word-policing that annoys everyone and helps no one. Done well, it's about questioning defaults, reducing avoidable harm, and giving people room to describe themselves — always explaining the why, and always weighing the user's safety and self-determination over a tidy checklist. Hold that bar.

The core stance

Carry these ideas into any review; they're the lens:

• "Neutral" isn't neutral. Every default is a decision about who's normal and who has to adapt. A "name" field, a date format, a gender binary, an assumed family structure — each quietly centers some people and marginalizes others. Surfacing that hidden decision is the first move.
• The "average user" is a fiction. Averaging away real diversity produces a person who doesn't exist and designs that fit no one at the edges. People are overlaps, not boxes — intersecting identities, not clean categories.
• "Edge cases" usually aren't edge. The situations dismissed as rare are often common, or they're where the real harm concentrates. Designing for them produces the curb-cut effect: the ramp cut for wheelchair users helps strollers, luggage, delivery carts — everyone. Solving for the margin improves the middle.
• Exclusion is a mismatch, not a deficiency in the person. People are disabled/excluded by environments and designs, not by their own bodies or identities. Fix the mismatch. (This framing owes to Kat Holmes's Mismatch and the disability-rights tradition.)

The exclusion taxonomy

To find who a design excludes, scan three dimensions. It's a structured way to ask "who might this not fit?"

• People — identity, culture, language. (Gender, race/ethnicity, orientation, age, religion; naming systems, reading direction, cultural conventions; first-language, literacy, translation.)
• Context — time, place, network, device. (Rushed vs. unhurried; loud, bright, or private vs. not; low bandwidth or offline; old/small/shared devices.)
• Capability — and crucially, capability is a spectrum across permanent, temporary, and situational: a permanent limitation (blind), a temporary one (eye surgery), and a situational one (bright sun, holding a baby) create the same need. Designing for the permanent case serves the far larger temporary and situational population too. (This permanent/temporary/situational "Persona Spectrum" comes from Microsoft's Inclusive Design Toolkit.)

Use the taxonomy as a prompt: for the design in front of you, walk each dimension and ask "who here is being pre-decided out?"

Identity & safety

Identity data is where inclusive design most often does real harm, because getting it wrong can out someone or erase them. Principles:

• Data minimization first. Before any personal field, ask: "Do we really require this information?" The most inclusive field is the one you don't collect. Every identity attribute you store is a liability to the user.
• Name vs. identity. Separate display/preferred name (the primary, public one people choose) from legal name (collect only if genuinely needed, keep private/hidden). Never surface a legal name publicly or use it to address people — that's how deadnaming happens. Don't enforce a single "real name."
• Gender & pronouns. Don't assume, don't infer from other data, and don't make them required. Offer self-describe / free input and "prefer not to say." Treat sex, gender, pronouns, name, voice, and body type as independent — a system that ties them together will misgender people. If you must collect sex for a real reason (e.g. medical), don't let it dictate gender or pronouns.
• Outing risks. Think through where identity data can leak and harm someone: notifications, activity feeds, "people you may know," default-public settings, previews on a lock screen. Default sensitive info (identity, orientation) to opt-in, not opt-out.
• Relationships & family. Offer flexible structures (self-defined relationships, more than two parents, chosen family) rather than a breadwinner/nuclear-family default.
• Safety by design. Confirm before risky/irreversible actions and allow undo or erase; provide quiet controls over notifications and previews; for permissions, explain why, collect less, offer granular choices, and make revoking easy.

Equity by design (representation & bias)

• Data-entry bias. Forms and validation that assume one norm exclude real people: names with particles/one name/non-Latin scripts, addresses that aren't US-shaped, right-to-left writing, dialects, non-Gregorian calendars, ambiguous date formats (is 07/08/09 in August or July?). Validate loosely; let people enter their real data.
• Model / automated bias. Automated systems can amplify bias or hide individual harm behind an average. Where a product uses ranking, scoring, moderation, or recognition, ask who it systematically gets wrong, and check edge populations rather than aggregate accuracy. (History is full of this — e.g. camera film chemistry long tuned to lighter skin.)
• Representation. Imagery, examples, and defaults teach people whether a product is "for them." Represent a real range of people — and go beyond tokenism: measure inclusion by impact and power (do underrepresented people actually shape decisions and outcomes?), not by headcount in a photo. Treat people as individuals, not stand-ins for a group.

Copy that cares (inclusive language)

Language carries assumptions. Reviewing and gently rewriting it is one of the highest-leverage, lowest-cost inclusive moves — if done with judgment rather than as find-and-replace.

The approach:

• Explain the why, offer alternatives, don't just flag. For each suggestion, say what assumption the original carries and give one or two natural replacements. People adopt changes they understand.
• Work from patterns, not a word list — recognize new cases yourself. The examples below are illustrative, never exhaustive. The actual skill is knowing the categories of loaded language so you catch an instance you've never seen written down. If fireman → firefighter, then by the same rule congressman → member of Congress / representative, stewardess → flight attendant, mankind → humanity, man-hours → person-hours. Don't wait for a word to appear in a list — apply the pattern to whatever copy is in front of you. The recurring categories:
  • Gendered role/occupation terms & the generic masculine — the -man / -woman / -ess suffix, or "man" standing in for people. → a neutral role word or a rephrase. fireman → firefighter, chairman → chair, salesman → salesperson / rep, policeman → police officer, manpower → workforce / staff, manmade → synthetic / handmade, generic he → they, guys → folks / everyone / team.
  • Marking a default and treating everyone else as the exception — qualifying only the "non-default" case: female engineer, male nurse, gay marriage (vs. just marriage). → drop the qualifier unless it's genuinely relevant.
  • Metaphors rooted in violence, slavery, or colonialism — blacklist / whitelist → denylist / allowlist (or blocked / allowed); master / slave → primary / replica; grandfathered → legacy-exempt; chief / tribe / powwow (casual) → the person's name, or team / community / meeting.
  • Ableist metaphors — crazy, insane, lame, dumb, blind to, deaf to, crippled used figuratively → precise words (surprising, intense, weak, unaware of, overwhelmed).
  • Other "one norm assumed" moves — age, body, socioeconomic, or family defaults. The underlying tell is the same across all of these: the language quietly treats one kind of person as standard. Learn to hear that, and you'll catch cases no list anticipates.
• Respect context — this is the crux. These are defaults, not bans. A word that's a problem in generic UI copy may be exactly correct in a specific, reclaimed, medical, historical, or community context. Don't sanitize a person's self-description, a direct quote, or domain-required terminology. When unsure, flag it as a judgment call and explain the trade-off rather than mandating a change.
• Match the product's voice. Inclusive copy should still sound like the product. The goal is language that quietly includes, not language that reads like a compliance memo.

Works in any language

Inclusive language is not English-only, and it is not translating an English word list. Every language encodes bias through its own machinery, so you apply the principle in that language's own mechanics. Detect the language of the content and work in it — if the user is writing in Portuguese, Spanish, French, German, etc., do the analysis and give alternatives in that language.

• Find how that language marks exclusion:
  • Grammatically-gendered languages (Portuguese, Spanish, French, Italian…): the generic/default masculine standing in for mixed groups, gendered job titles and adjectives, the masculine plural "covering" everyone.
  • Gendered address & honorifics (French Madame/Mademoiselle, German Herr/Frau, titles that assume marital status or gender).
  • Register/formality that encodes hierarchy or assumptions.
• Offer the strategies the language actually supports, roughly in order of how natural and widely-accepted they are:
  • Rephrase to sidestep gender — usually the smoothest, least controversial move. Portuguese: "os utilizadores" → "quem utiliza" / "as pessoas utilizadoras"; "bem-vindos" → "boas-vindas" / "que bom ter-te por aqui"; "obrigado/obrigada" (gendered by the speaker) → "agradecemos".
  • Use collective / epicene nouns — PT: "as pessoas", "a equipa", "a comunidade", "quem", "cada pessoa" instead of a gendered plural.
  • Neutral neologisms (PT: the -e ending, "elu", "todes"; ES: -e / -x): these exist and matter to some communities, but they're contested, register-dependent, and not universally understood. Mention them as an option when the audience fits; don't impose them, and flag the trade-off.
• Loaded / sensitive words exist in every language. Apply the same categories (gendered, racialized, ableist, colonial) using knowledge of that language and region — an idiom that's harmless in one variety can carry harm in another (e.g. European vs. Brazilian Portuguese differ). When you're unsure of a specific term's connotation in a language or region, say so and flag it rather than guessing.
• Respect audience, register, and the user's call. What fits an activist zine may not fit a government form. Surface the options with their trade-offs and let the user decide — the goal is to extend the same care into their language, not to hand down one "correct" rewrite.

How to produce a review

• For a design review: identify who's excluded (walk the taxonomy), the specific identity/safety/representation risks, and concrete fixes — prioritized by potential harm (outing and exclusion first, polish later). Tie each finding to the underlying principle so it teaches, not just corrects.
• For a copy review: work in the language the content is written in; return the original alongside a suggested rewrite and a one-line reason per change, and separate confident fixes from context-dependent judgment calls. Catch issues by category (see the patterns above), not only the words that appear on a list.
• Keep the tone constructive and specific. Assume good intent from the designer; the job is to widen the design, not to scold.

Tone & sensitivity

This domain touches real people's identities and safety, so hold a few things: be respectful and non-preachy; center the affected users' self-determination (let people describe themselves; don't decide for them); avoid stereotyping even while discussing groups; acknowledge trade-offs honestly rather than presenting one right answer; and stay humble — you're surfacing considerations for a human to weigh, not issuing verdicts.

Pairs well with

• accessibility-review — inclusion for disability, in depth, against WCAG/IBM.
• heuristic-evaluation — general usability audit alongside the inclusion lens.
• persona-builder — build personas that represent the margins, not just the center.

Sources

This skill distills the talk "Designing from the Margins" and draws on well-known inclusive-design work: Microsoft's Inclusive Design Toolkit (the permanent/temporary/situational Persona Spectrum, "solve for one, extend to many"), Kat Holmes's Mismatch: How Inclusion Shapes Design, the disability- rights concept of the curb-cut effect, and writing such as Sara Wachter-Boettcher's Technically Wrong. Reference these by name to credit and deepen.