Skip to content
Design
Skill

/inclusive-personas

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

BOOST
From plugin
designpowers
25436 skills10 agents1 hook
Install
$ npx -y skills add Owl-Listener/designpowers --skill inclusive-personas --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/inclusive-personas

Context preview

The summary Claude sees to decide when to auto-load this skill.

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

SKILL.md

inclusive-personas.SKILL.md
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 |

Read more
Ships withdesignpowers

An agent design team you control. 10 agents that run an inclusive design process while you direct. The system notices how you design and reflects it back. Designpowers is an open, model-agnostic design workflow that gives you a team of 10 design agents.

Get the whole plugin

Other skills on designpowers.