Process

Personas in Inclusive Design: Representing Disability Accurately

By EZUD Published · Updated

Personas in Inclusive Design: Representing Disability Accurately

Personas are a staple of user-centered design, but most persona sets exclude people with disabilities entirely. When disability is included, it is often reduced to a single “accessibility persona” that collapses the vast diversity of disabled experience into one character. Inclusive design demands a more thoughtful approach.

Why Standard Personas Fall Short

Traditional personas are built around demographics, goals, frustrations, and technology preferences. Disability is rarely mentioned. This absence sends an implicit message that disabled people are not part of the target audience. The result is products designed for a narrow slice of human ability.

When teams do include disability, common mistakes include:

  • The single disability persona. One persona labeled “visually impaired” cannot represent the range of conditions from low vision to total blindness, each involving different assistive technologies and strategies.
  • Defining personas by their disability. A persona whose primary characteristic is “uses a wheelchair” reduces a person to a medical condition, ignoring their goals, expertise, and context.
  • Excluding intersectionality. Disabled people are also parents, professionals, older adults, and non-native speakers. Personas that treat disability as a separate category miss these intersections.

A Better Approach: Disability as Context, Not Category

The Inclusive Design Research Centre (IDRC) at OCAD University recommends moving away from fixed personas entirely, instead using “user states” or “persona spectrums” that acknowledge that anyone can experience disability situationally, temporarily, or permanently. Microsoft’s Inclusive Design Toolkit uses a similar spectrum model: permanent (one arm), temporary (arm injury), situational (holding a child).

If your team uses traditional personas, integrate disability thoughtfully:

Distribute disability across personas

Rather than one “accessibility persona,” add disability-related context to multiple personas. A project manager persona might have low vision and use ZoomText. A college student persona might have ADHD and benefit from reduced motion and clear content structure.

Specify assistive technology and strategies

A persona who is blind is not useful without specifying that they use JAWS with Chrome on Windows, navigate by headings, and prefer keyboard shortcuts. Assistive technology choices affect how a person interacts with your product at every level.

Ground personas in research

Personas not based on research with disabled users are fiction. Conduct interviews and contextual inquiries with people who have the disabilities represented in your personas. See our guide on user testing with people with disabilities for recruitment and methodology.

Include cognitive and neurological diversity

Personas frequently focus on sensory and motor disabilities while ignoring cognitive, learning, and neurological conditions. Include personas who experience dyslexia, autism, anxiety, acquired brain injury, or memory impairments. These conditions affect navigation, comprehension, and interaction in ways that shape design decisions.

Persona Attributes to Include

For each persona, document:

  • Goals and tasks (primary, not disability-related)
  • Disability or condition (specific, not generic)
  • Assistive technology and settings (screen reader, magnification, switch, voice control, browser settings, OS settings)
  • Strategies and workarounds (how they handle inaccessible content today)
  • Context of use (device, environment, time pressure)
  • Frustrations (accessibility barriers they commonly encounter)
  • Intersecting factors (age, language, digital literacy, bandwidth)

Example Inclusive Persona

Amara, 34, Marketing Director Amara has low vision (retinitis pigmentosa) and uses ZoomText screen magnification set to 4x on a 27-inch monitor. She also uses the high-contrast mode in Windows. She navigates primarily with a mouse but uses keyboard shortcuts in applications she knows well. Amara manages a team of eight and spends most of her day in email, project management tools, and presentation software. She is frustrated by dashboards with small, low-contrast text and charts that cannot be zoomed without losing labels.

This persona is useful because it specifies the condition, the technology, the context, and the barriers, while keeping Amara’s professional role and goals at the center.

Connecting Personas to Design Decisions

Personas only matter if they influence design. For each design decision, ask:

  • Can Amara read this text at 4x magnification with high contrast?
  • Can a persona using JAWS navigate this form and understand error messages?
  • Can a persona with ADHD complete this task without losing their place in a multi-step flow?

Integrating these questions into design reviews and design sprints keeps personas actionable rather than decorative.

Key Takeaways

  • Distribute disability across multiple personas instead of isolating it in one.
  • Specify assistive technologies, settings, and strategies, not just the condition.
  • Include cognitive and neurological diversity alongside sensory and motor disabilities.
  • Ground every disability persona in research with disabled users.
  • Use personas actively in design reviews and sprint planning to inform real decisions.

Sources

More in Process

Inclusive Design Process Guide: Building Accessibility Into Every Stage Guide Continuous Accessibility Monitoring Accessibility in Design Reviews Nothing About Us Without Us: The Principle That Shapes Inclusive Design

View all Process articles →