Reframing the average user: A guide to inclusive product design
“I’m building this digital product to be usable for a small portion of the population,” said no product designer, anywhere, ever.
Design teams pour their passion and expertise into building products that will be used (and loved) by as many people as possible. But legacy systems and design conventions can unintentionally sabotage these efforts by prioritizing the experiences of the so-called “average user.” This approach overlooks the full range of human needs, abilities, and contexts.
Inclusive product design flips the script
Inclusive product design is a practical, human-centered approach that helps teams build flexibility into digital experiences from the start. This ultimately allows more people to enjoy using products as intended, regardless of ability, age, language, or life situation.
Not sure where to start designing inclusive products? This guide breaks down simple, practical steps you can take at every stage of product development. No overhauls. No red tape. Just small changes you can fit into existing workflows. Bonus: you’ll discover common pitfalls to avoid and real examples of teams making meaningful progress with inclusive product design, one decision at a time.
Skip straight to the stages you’re interested in:
Build more inclusive products by implementing small, practical changes at every stage
You don’t need to overhaul your entire design and product development process. Instead, focus on simple steps you can incorporate into existing processes to build more inclusive, usable, and widely adopted digital experiences. Bonus: you’ll also mitigate future accessibility issues and save yourself time, effort and money associated with fixing and remediating broken experiences.
Stage 1: Research
During the research phase, you’re focused on gaining a better understanding of user needs and pain points. You are looking to identify areas of opportunity and deepen your understanding of people’s lived experiences navigating digital products. Practicing inclusive product research can take different forms.
| Research type | Goals | Inclusive methods |
|---|---|---|
| Discovery and generative research | Better define a problem, identify an opportunity for assistive technology users, or leverage insights to kickstart a project. | Conduct open-ended user interviews with assistive technology users to yield meaningful insights. You can start with a smaller representation of people with disabilities, with the longer-term goal that 20% of all research participants have lived experience. Eventually engaging with a diverse range of assistive technology users to gain a high-level understanding of different accessibility considerations. |
| Usability evaluations | Collect data that helps to improve your products or better understand how they’re currently working for assistive technology users. | Use the combination of qualitative and quantitative data to help identify and prioritize any functional or usability roadblocks. Test your most critical task flows across different assistive technologies, devices, and browsers. You can use a tool like the free Accessible Usability Scale (AUS) to measure the perceived usability of a product for an assistive technology user. By implementing AUS early in your research, you set yourself up to compare future scores to a benchmark. |
Avoid these common research stage pitfalls
1. Don’t recruit from narrow, homogenous research participant pools
Including diverse participants generates more inclusive outcomes. Consider doing research with people with disabilities, older adults, neurodivergent participants, and more.
The benefits of including people with disabilities in the research phase include:
2. Don’t mistake accessibility for universality
Just because your experience works for screen readers doesn’t mean it will work for all assistive technologies. Engage with a diverse range of assistive technology users to gain a high-level understanding of different accessibility considerations.
3. Don’t rely on inaccessible third-party tools to reach users
Check that your research tools (e.g. surveys, scheduling apps, video conferencing, prototype platforms) work with screen readers, keyboard navigation, and other assistive tech your participants may use. Need inspiration? Check out how the Fable team used our own accessible Fable Engage to build an accessible feature in that same product!
Inclusive products research in action: CVS Health
Former Senior Accessibility Designer and Inclusive Research Lead at CVS Health, Greg Weinstein, addressed the imbalance of typical UX data capture by centering the experiences of people with disabilities in user research. CVS Health’s Design Accessibility team has generated enthusiastic support for accessibility by developing empathy for the diverse challenges people face when interacting with CVS Health.
“Thanks largely to our partnership with Fable, we have a replicable, ongoing user research process with people with disabilities … that has been very important as one of the pieces of our inclusive design work at CVS.”
– Greg Weinstein, former Senior Accessibility Designer and Inclusive Research Lead at CVS Health
Stage 2: Design
A lot of accessibility issues are unintentionally introduced in the design stage. Anna E. Cook, Senior Accessibility Designer at Northwestern Mutual, is quoted as saying, “67% of accessibility issues can originate in design.”
You can prevent many of these issues by catching them before the handover to development teams. Identifying usability issues before a product is built will save you from remediation time down the line and ensure you’re designing with accessibility in mind.
Remember: adding accessibility features after the fact is a costly process that, in extreme cases, can mean rebuilding your product. According to the Centre for Inclusive Design, “the relative cost of retrofitting a product or service to become inclusive will increase significantly over time and can reach up to 10,000 times the cost of introducing inclusive design earlier on.” Prioritizing usability sets you up for the future with a relatively minimal investment.
It’s never too early to collect usability feedback
It’s possible to get critical feedback from assistive technology users in the pre-prototype stage. Then, once you get to the point of building an interactive prototype using tools like Figma, Azure and InVision, it’s also simple to collect initial thoughts and feedback from assistive technology users who use unique types of alternative navigation.
The questions and format for your prototype review will depend on the goals you have in mind, but in general you can expect to get answers to questions like:
Avoid these common design stage pitfalls
1. Don’t leave room for assumptions
Use design annotations to give detailed guidance to developers in your handover materials. For example, some design elements might be decorative while others are informational. Explicitly telling the dev team which is which will target the inclusion of critical accessibility elements like alt text.
Fable has a Figma widget that allows design teams to embed insights from people with disabilities directly into Figma design files and FigJam boards. This lets developers hear feedback straight from the source.
Watch how it works:
2. Don’t speak two different languages
Designers operate in pixels, but working in REMs (root ems) makes a website more responsive across different screen sizes and user settings. A designer can communicate REM needs to dev teams through notes in Figma.
It’s essential to find a single source of truth that communicates how to approach design and development work. It doesn’t have to be a complicated design system—it can be as simple as a shared Confluence document that calls out commonly used design components, conveys spacing standards, and outlines how to convert from one size to another.
3. Don’t let uncertainty keep you from engaging with people with disabilities
Interviewing people with disabilities can offer rich insights, but some designers might feel nervous about doing or saying the wrong thing. There’s no need for anxiety. Asking productive questions and leading with curiosity is bound to uncover rich insights.
“You can do all the accessibility checks you want but it’s not going to replace talking to people who experience it every day. I’m never going to be able to catch every accessibility issue. So, I think being able to have that collaborative co-design relationship with Fable testers, that’s been instrumental for us.”
– Annabel Weiner, User Experience Accessibility Specialist at Ally Bank
Stage 3: Development and pre-launch
Development teams frequently use the automated tools like Wave’s Web Accessibility Evaluation tool, Google’s Lighthouse accessibility tool, HTML CodeSniffer accessibility tool by Squizlabs to detect common issues including missing alt text, color contrast, misused ARIA attributes, and more. But these automated tools only catch ~20-30% of accessibility issues, so they can’t be your only source of feedback.
Both automated and manual accessibility testing have a place
Automated accessibility testing
Automated tools focus on specific code stacks and can help find errors or problems that might lead to the final product being inaccessible. They offer time savings and scalability, but they can’t guarantee that your software will be usable for people with disabilities.
Manual accessibility testing
This type of testing involves humans looking through the platform—both frontend and backend—to see if it is accessible. This can take the form of in-house quality assurance (QA) checks that also consider accessibility, software testing groups for accessibility features, or user testing within the disability community.
The upside of manual testing is you get a human perspective, which helps serve the goal of building technology humans can use. The downside is that recruiting testers can be time consuming.
Automated tests show you what’s broken. Human testers show you what’s unusable.
At this stage, inclusive product development could include the following:
“For every hour that a UX designer invests into accessibility pre-launch, we save up to four hours in engineering post-launch, not bug-fixing accessibility issues.”
– Dirk Ginader, Accessibility UX Engineering Lead at Google
Avoid these development stage pitfalls
Design teams still play an important role after handoff to development , from flagging high-impact flows for accessibility testing to providing detailed design intent, so devs build components accessibly to staying involved in the QA loop.
1. Don’t assume someone will make it accessible “later”
The real insights come from human testing, especially with people who use assistive technologies like screen readers, screen magnifiers, and switch devices. They’ll catch problems that no plugin or checklist will find, and you won’t need to start over later when budget, motivation, and time are lacking.
2. Don’t let the lack of assistive technologies slow you down
Due to WCAG’s emphasis on screen reader users, many developers have learned how to do screen reader testing on their own (although this doesn’t replace feedback from an actual screen reader user). But only focusing on one type of assistive technology leaves out a large chunk of other users. Inclusive design means having awareness and empathy for the wide range of assistive technologies used to navigate digital products.
3. Don’t narrowly define audiences
Disabilities aren’t always visible or obvious. For example, a user on the autism spectrum might struggle with overwhelming visuals or too much information presented at once. Getting product feedback from a wide range of users leads to the most usable end products.
Stage 4: Post-launch and product maintenance
With every new product release or update, there’s an increased possibility of a broken or inaccessible user experience. Regular-scheduled testing ensures that you are not only meeting compliance standards but providing a highly usable experience.
Design’s impact doesn’t end at launch
It’s always been challenging to measure the accessibility of digital products and to capture team progress over time. It’s important to find the right metrics that stakeholders will care about and can easily understand. Your plan should include establishing benchmarks, monitoring product accessibility health over time, and continuing to build team empathy.
| Test type | Purpose | How it works |
|---|---|---|
| Task completion via Compatibility Tests | Benchmarking. Determines whether assistive technology users can complete the most important tasks. | Determine the critical tasks for all your products, run Compatibility Tests for each one, and retest the exact same tasks on a regular basis to identify changes in accessibility, ease of use, and task completion. |
| AUS via Self-Guided Tasks | Benchmarking. Determining if your organization is truly inclusive. Evaluates key tasks and compares the results with Fable’s Accessible Usability Scale (AUS). | If your organization leverages System Usability Scale (SUS), you can also compare this data to your SUS scores. For example, if you find significantly worse usability for users of assistive technology compared to non-assistive technology users, that’s a sign that you need to make sure that accessibility is prioritized equally to general user experience within your organization. |
| Recurring Tests | Monitor product accessibility and health. Align your accessibility reporting with the same cadence of reporting for your other product health metrics, and visible dashboards for leadership. This will help embed accessibility as a staple in your product strategy and priorities. | Once you’ve established your baseline data and the benchmarks you want to capture on a regular basis, use the recurring request feature on Fable Engage to set your requests to run automatically. This will allow you to remove the manual lift of monitoring and measurement and ensure consistency in your reporting efforts. |
| Interviews with Users | Build team empathy and awareness by understanding diverse user needs. | Get direct feedback from users to collect data, extract insights, and improve your products overall. Continuously conduct User Interviews through Fable anytime you are seeking out voice of customer feedback. |
Avoid these maintenance stage pitfalls
1. Don’t assume accessibility is “done” because you passed an audit
Inclusive products aren’t static. New features can break old fixes. A seemingly harmless visual tweak can kill keyboard nav or screen reader clarity. Make sure teams don’t ship “minor” UI changes without re-checking accessibility.
2. Don’t treat all bugs equally
When you consider the volume of potential product bugs, accessibility issues will never be on par. It’s not an apples-to-apples comparison. The priority of all bugs and fixes needs to be evaluated based on projected impact. (e.g., What’s the business impact if screen user readers are completely blocked from using a revenue-generating digital experience?)
3. Don’t let inclusive design fall off the roadmap
If you don’t allocate the time and resources to fix accessibility issues surfaced by your testing, then the work is irrelevant. It’s not enough to know that issues exist; you need a plan to fix them in the moment and prevent them from happening again in the future. Remember: if it’s not tracked, it won’t be fixed.
Sustain inclusive product design for the long term
Your focus on designing inclusive products doesn’t end at launch. In fact, some of the most impactful improvements will happen once your product is out in the world—and real people start using it in real contexts.
It helps to think of inclusive design and product development as a muscle to build. The big impact builds in small steps over time, not a one-and-done workout. Here’s how your team can continue to prioritize universal usability for the long term:
Remember there’s no such thing as the “average user”
When ideating new features or improvements to include in a product, make sure you’re thinking about all users. That includes people born with disabilities, people aging into assistive technology use, and people with cognitive accessibility needs. Expanding your audience not only increases market reach, but it also fosters customer loyalty, which can translate into stronger sales over time.
Create lightweight rituals that keep inclusion visible
Add one accessibility-focused question to your design reviews or sprint retros. For example: “What edge cases might we be missing?” or “Does this work at 200% zoom or with voice control?” You don’t always need a formal process—just small, repeatable cues that keep accessibility in the conversation.
Document what works, even informally
Capture key decisions, tools, accessibility learnings, or inclusive design patterns. You can start with a shared doc, Notion page, or Figma board. Even a quick “accessibility notes” section in your project files goes a long way toward building team knowledge.
Benchmark usability
Fable’s Accessible Usability Scale (AUS) is a free tool for measuring the usability of your digital products for assistive technology users. Similar to the System Usability Scale (SUS), the AUS provides a usability score—but it’s specifically focused on the experiences of people with disabilities using tools like screen readers, switch controls, or magnifiers.
Example AUS score:
| # | Statement | Scale Position | Calculation |
|---|---|---|---|
| 1 | I would use this website frequently, if I had a reason to. | Agree - 4 | (4-1) x 2.5 = 7.5 |
| 2 | I found the website unnecessarily complex. | Strongly disagree - 1 | (5-1) x 2.5 = 10 |
| 3 | I thought the website was easy to use. | Strongly agree - 5 | (5-1) x 2.5 = 10 |
| 4 | I think that I would need the support of another person to use all of the features of this website. | Neutral - 3 | (5-3) x 2.5 = 5 |
| 5 | I found the various functions of the website made sense and were compatible with my technology. | Agree - 4 | (4-1) x 2.5 = 7.5 |
| 6 | I thought there was too much inconsistency in how this website worked. | Strongly disagree - 1 | (5-1) x 2.5 = 10 |
| 7 | I would imagine that most people with my assistive technology would learn to use this website quickly. | Agree - 4 | (4-1) x 2.5 = 7.5 |
| 8 | I found the website very cumbersome or awkward to use. | Strongly disagree - 1 | (5-1) x 2.5 = 10 |
| 9 | I felt very confident using the website. | Strongly agree - 5 | (5-1) x 2.5 = 10 |
| 10 | I needed to familiarize myself with the website before I could use it effectively. | Disagree - 2 | (5-2) x 2.5 = 7.5 |
| Score | 85 | ||
Think beyond products to include people and processes
Create KPIs (key performance indicators) for each to make it easier to report on accessibility progress and business impact. Here’s a handy framework you can use.
Share the knowledge
Having internal accessibility “champions” is valuable, but make sure that one person does not hold all the knowledge for your team or organization. Set your organization up for success by sharing knowledge widely. At the very least it should be well documented, so others can continue to work on your accessibility roadmap, even in times of change.
Inclusive design isn’t about perfection—it’s about progress
Practicing inclusive product design should never require overhauling your end-to-end processes. Instead, it’s about adapting existing processes to become more inclusive. Start small, stay curious, and keep usability in mind with every choice your design team makes.
Need help building your inclusive product design roadmap? Looking for easy access to a broad range of experienced accessibility testers?
Book a call with our experts so we can help get you the right support for your needs.