inclusive-personas

name	inclusive-personas
description	Use when defining who a design serves — creating personas, user stories, or scenarios — ensures the full ability spectrum and situational contexts are represented from the start, not retrofitted

Inclusive Personas

Personas shape every design decision that follows. If your personas only represent able-bodied, neurotypical, tech-savvy adults with fast internet, your design will only work for those people. This skill ensures the full range of human experience is represented from the beginning.

The Principle

"Nothing About Us Without Us." Design for the margins and the centre benefits. Design for the centre and the margins get excluded.

Process

Step 1: Map the Ability Spectrum

For the design context, identify the relevant spectrum across:

Permanent conditions:

• Vision: blind, low vision, colour blind
• Hearing: deaf, hard of hearing
• Motor: limited fine motor, limited reach, tremor, paralysis
• Cognitive: learning differences, memory challenges, attention differences
• Speech: non-verbal, speech differences

Temporary conditions:

• Broken arm, ear infection, concussion, medication effects, post-surgery

Situational conditions:

• Bright sunlight, noisy environment, one hand occupied, driving, multitasking, emotional distress, unfamiliar language, slow connection

Step 2: Identify Relevant Personas

Not every project needs every persona. Select 4-6 personas that represent:

• 2-3 primary users — the most common use cases
• 1-2 edge case users — people at the margins whose needs reveal design weaknesses
• 1 stress case user — someone using the design under difficult circumstances

Step 3: Build Each Persona

For each persona, document:

## [Name]

**Context:** [Who they are, what they do, their relationship to this product]

**Abilities and conditions:** [Permanent, temporary, or situational factors that affect how they interact with interfaces]

**Technology:** [Devices, assistive technology, connection speed, technical confidence]

**Goals:** [What they need to accomplish]

**Frustrations:** [What typically goes wrong for them with similar products]

**Environment:** [Where and when they use this — lighting, noise, distractions, time pressure]

Step 4: Write Inclusive User Stories

For each persona, write stories that capture:

• The standard path: "As [persona], I want to [goal] so that [outcome]"
• The assisted path: "As [persona] using [assistive technology], I want to [goal] so that [outcome]"
• The stress path: "As [persona] under [stressful condition], I need to [goal] without [negative outcome]"

Step 5: Identify Scenario Intersections

Map where personas overlap in unexpected ways:

• A sighted user in bright sunlight has similar needs to a low-vision user
• A stressed parent holding a baby has similar motor constraints to someone with limited hand mobility
• A non-native speaker has similar needs to someone with a cognitive processing difference

These intersections reveal universal design opportunities.

Step 6: Present and Validate

Present personas to the user. Ask:

• Who is missing from this set?
• Do these feel like real people or cardboard cutouts?
• Which persona makes you most uncomfortable? (That one probably needs the most attention)

Save to: docs/designpowers/personas/YYYY-MM-DD-<project>-personas.md

Integration

• Called by: research-planning, design-discovery
• Informs: Every subsequent design skill — personas should be referenced when making any design decision
• Pairs with: cognitive-accessibility, adaptive-interfaces

Anti-Patterns

Pattern	Problem
"Our users are everyone"	If everyone is your user, nobody is. Define specific people
Personas without disabilities	You have excluded a quarter of the population
Edge cases treated as afterthoughts	Edge cases reveal the quality of your design. They come first, not last
Personas based on demographics alone	Age and job title do not determine how someone uses an interface. Focus on behaviour, ability, and context