There’s a moment every designer dreads. You’ve shipped a product. The launch went beautifully. Analytics look great for most users. Then the emails start arriving. A screen reader user can’t navigate your onboarding flow. A non-native English speaker can’t parse your error messages. Someone with low vision is squinting at your carefully chosen “aesthetic” low-contrast palette. You built something for people, just not for everyone. And the worst part? You probably never even noticed who was missing from the room when you made those decisions. This is the central challenge of design justice in UX.
This isn’t a niche problem. According to a 2023 report by the Nielsen Norman Group, over 26% of adults in the United States alone live with some form of disability, yet fewer than 10% of design teams consistently include disabled users in their research phases. That gap isn’t just a business risk. It’s a justice issue. When we design without including the people most impacted by our decisions, we don’t just create friction, we create exclusion. We encode bias into buttons, workflows, and algorithms that millions of people have no choice but to use.
Why Design Justice Matters for UX Teams
Design justice is the framework that challenges us to do better. Coined and popularized by Sasha Costanza-Chock in their groundbreaking 2020 book Design Justice, the concept asks a deceptively simple question: who benefits from this design, and who bears its burdens? It pushes back against the myth of the “neutral designer,” the idea that if you just follow good UX principles and conduct user testing, you’ll end up with something fair. Neutrality, in a world already shaped by inequality, isn’t neutral at all. It’s complicity with the status quo dressed up in a Figma file.
The good news? Design justice isn’t about burning down your entire process. Instead, it’s about expanding it. That means asking harder questions earlier, inviting different people into the conversation, and accepting that good design sometimes means sitting with discomfort, the discomfort of being told you got it wrong by someone whose experience you’ve never lived. This design justice UX guide is your practical, honest resource for doing exactly that.
Understanding Who Gets Left Out—and Why
The Myth of the “Average User”
Here’s a thought experiment. Picture your typical user. Go ahead, close your eyes, and do it. Odds are you just imagined someone between 25 and 40, probably able-bodied, probably comfortable with smartphones, probably with reliable broadband, and probably speaking your language as a first language. That imaginary person lives at the center of almost every persona document ever written. And they’re a fiction.
The concept of the “average user” has always been a convenient shortcut that quietly erases complexity. It borrows from a troubling historical precedent. In the 1950s, the U.S. Air Force redesigned its cockpits after discovering that designing for the “average” pilot body, an approach that averaged out 140 physical measurements, resulted in a cockpit that fit exactly zero of the 4,063 pilots measured. Not one. The lesson should have echoed through every design discipline for decades. It mostly didn’t. We still build for averages. We still ship products that fit almost no one perfectly and exclude whole populations entirely.
When you design for the mythical average user, you’re implicitly designing for whoever holds the most power in your user research pool. That tends to mean English-speaking, urban, educated, non-disabled people with disposable income and fast internet. The people who don’t fit that profile—elderly users navigating complex healthcare portals, immigrants using government services in a second language, low-income users on prepaid data plans, and people with cognitive disabilities trying to complete a checkout flow—they aren’t edge cases. They are a massive, underserved majority who deserve design that works for them too.
Recognizing Structural Bias in Design Systems
It’s tempting to frame exclusion as an accident, a blind spot, an oversight, or a bug. Occasionally it is. But often, it’s structural. Design decisions are made under conditions that systematically favor certain perspectives. Think about who works at most major tech companies. According to Statista’s 2023 diversity report, women make up only around 28% of the tech workforce, and Black and Hispanic employees together represent fewer than 15% of workers at major tech firms. When your team reflects a narrow slice of humanity, you train your empathy muscles on that narrow slice of human experience.
This issue shows up in real, harmful ways. Facial recognition systems trained predominantly on lighter-skinned faces, like the ones documented in MIT Media Lab researcher Joy Buolamwini’s landmark Gender Shades study, misidentify darker-skinned women at rates up to 34% higher than lighter-skinned men. Health tracking apps that defaulted to menstrual cycle tracking as an “optional” feature for years. Natural language processing tools that perform worse on African American Vernacular English. Voice assistants that consistently struggle with non-native accents. These aren’t coincidences. They’re the predictable output of processes that never interrogated who was in the room, or more importantly, who wasn’t.
Recognizing structural bias means accepting an uncomfortable truth: your design process itself might be biased, regardless of your intentions. The tools you use, the research methods you default to, the demographic breakdown of your usability testing pool, and the cultural assumptions baked into your information architecture—all of it reflects choices made by people with particular positionalities. And until you start auditing those choices with fresh, critical eyes, you’ll keep shipping the same exclusions with different color palettes.
Building Participatory Design Practices That Actually Work
Moving From “Designing For” to “Designing With”
There’s a phrase in disability activism that every designer should tattoo on their brain: “Nothing about us without us.” It emerged from disability rights movements in the 1990s and became a rallying cry against paternalistic policy-making. It belongs just as fiercely in design. The difference between designing for a community and designing with them isn’t just semantic; it’s the difference between charity and justice, between assumption and understanding.
Traditional user research often treats participants like data sources. You recruit them, run them through a protocol, extract insights, thank them for their time, and go back to your design team to make decisions. The research subjects never see the decisions made with their input. They cannot control how others interpret their experiences. They can’t push back when a designer misunderstands something fundamental about their lives. This model is extractive. It takes knowledge from communities who often get nothing back, even a product that serves them.
Participatory design flips this model. It invites community members into the design process as genuine collaborators, not just subjects. Organizations like the Participatory Design Conference community and the Co-Design Lab at MIT have developed robust methodologies for these purposes: co-design workshops where participants sketch and prototype alongside designers, community advisory boards that have real input on product decisions, and iterative feedback loops that bring participants back multiple times rather than consulting them once. It’s slower. It costs more upfront. And it produces designs that are dramatically more useful, more trusted, and less likely to cause harm to the communities they serve.
Compensating Participants and Respecting Expertise
Let’s talk about money. Because participatory design done well isn’t free, and treating it like it should be is its form of exploitation. When you ask marginalized community members to educate your team about their experiences, often experiences rooted in trauma, discrimination, or systemic neglect, you’re asking them to do emotional and intellectual labor. That labor has value. It should be compensated.
The National Center for Equitable Community Research recommends compensating research participants at rates equivalent to professional consulting fees when their participation shapes product decisions. That can feel like a radical ask in organizations where “user interviews” are budgeted at a $25 Amazon gift card. But consider this: your team’s designers, researchers, and product managers are paid handsomely for their expertise. Why should community members, whose lived expertise is arguably more relevant to the problem you’re solving, contribute for free or for a token gift?
Compensation isn’t the only thing, though. Respect for participants’ expertise means changing how you interpret and use what they tell you. It means resisting the urge to immediately translate their feedback through your framework. It means letting community members review how their input has been used and flagging when something has been distorted. Projects like the Detroit Digital Justice Coalition’s community internet initiative and the Civic Design Center’s work in public health show what’s possible when designers genuinely hand over interpretive authority to the communities they serve. The results look different from typical tech products, and that’s exactly the point.
Embedding Equity Into Your Research and Testing Processes
Rethinking Who You Recruit and How
Your usability testing panel is a political document. Every inclusion and exclusion criterion you write reflects assumptions about whose experience counts. “Participants must have used our app in the last 30 days” excludes exactly the people who dropped off because your app was inaccessible. “Comfortable with technology” is a coded phrase that filters out older adults, people with limited digital literacy, and users in under-resourced communities. By the time you’ve written your screener, you may have already ensured you’ll learn nothing you didn’t already know.
Equitable recruitment requires deliberate, effortful outreach into communities you wouldn’t normally reach through standard research channels. That means partnering with community organizations, disability advocacy groups, immigrant services agencies, and public libraries. It means designing your research protocols to accommodate different needs, offering sessions in multiple languages, providing accessible formats for any written materials, allowing participants to bring support people if needed, and being flexible about whether meetings happen in person, remotely, or in participants’ own environments. It means paying attention to who shows up and who doesn’t and being curious about why.
When teams at Microsoft developed their inclusive design toolkit, which became a model referenced across the industry, they shifted their recruitment to specifically prioritize people with permanent disabilities. The insight they uncovered was revolutionary in its simplicity: designing for someone with one arm creates better designs for someone with a temporary injury and for someone holding a baby with one arm. They call this the “curb cut effect”; accommodations designed for people with specific needs tend to make experiences better for everyone. Your recruitment strategy determines whether you ever get access to those insights.
Making Accessibility Research Non-Negotiable
Here’s a hard truth that many product teams are still dancing around: accessibility testing isn’t nice to have. In many jurisdictions, it’s legally required. The Americans with Disabilities Act, the European Accessibility Act, and WCAG 2.1 guidelines all establish legal and technical frameworks that organizations ignore at significant legal and reputational risk. But beyond compliance, accessibility research is simply good research. It reveals friction points that affect all users, not just those with disabilities.
Screen reader testing, for example, exposes the underlying logical structure of your UI in a way visual testing never can. If a screen reader user can’t navigate your registration flow, it almost certainly means your information architecture has problems that affect all users to varying degrees. Cognitive accessibility testing with participants who have ADHD, dyslexia, traumatic brain injuries, or learning differences shows how language complexity, visual noise, and cognitive load affect comprehension and task completion. These are insights that improve every product, not just products used by disabled people.
The Center for Inclusive Design and Environmental Access at SUNY Buffalo and organizations like Fable Tech (which connects companies with disabled research participants) have created accessible pathways for teams that want to integrate this work but don’t know where to start. The barrier isn’t resources. It’s prioritization. When teams argue they “don’t have time” for accessibility research, what they’re really saying is that they’ve decided disabled users don’t count as much. That’s a choice. And it’s one that design justice asks us to make consciously and differently.
Creating Organizational Conditions Where Justice Can Thrive
Building Diverse Teams Is Necessary but Not Sufficient
You’ve heard the diversity pitch. Diverse teams make better products. In fact, the research backs it up; McKinsey’s “Diversity Wins” report found that companies in the top quartile for ethnic and cultural diversity are 36% more likely to achieve above-average profitability. Google’s Project Aristotle found psychological safety, the ability for team members to speak up without fear, to be the single most significant predictor of team effectiveness. Diversity matters. But hiring diverse team members and then expecting them to “add diversity” while conforming to your existing processes is not design justice. It’s tokenism with a better press release.
Real organizational conditions for design justice mean examining which voices are influential in design critiques. Who gets interrupted in standups? Whose concerns about ethical implications get categorized as “nice to have” versus “blocking”? When a designer of color raises concerns about a feature that might harm their community, does the team treat that as critical expertise or as personal bias? These dynamics are subtle, powerful, and almost impossible to see if you’re not the person experiencing them. They determine whether your diverse hire stays for three months or three years and whether they feel safe enough to bring their full knowledge to the work.
Teams that are serious about this do structural things. They establish clear processes for surfacing ethical concerns, not just a suggestion box, but a formal part of design review. They create explicit channels for anyone to flag potential harms without career risk. They measure not just hiring diversity but retention, promotion rates, and self-reported inclusion scores across demographic groups. Design justice in teams is not just a feeling. It’s a set of practices you can observe and audit.
Institutionalizing Justice: Frameworks, Processes, and Accountability
Individual commitment is fragile. Design justice at the individual level looks like one well-intentioned designer fighting every sprint planning meeting to include accessibility tickets, burning out, and leaving for a company that “gets it.” By contrast, institutional commitment is durable. It looks like your definition of done includes accessibility and equity criteria, your product roadmap process incorporates community consultation, and there is executive-level accountability for inclusion metrics alongside revenue metrics.
Several organizations are modeling what this commitment looks like at scale. The City of Austin, Texas, embedded equity impact assessments into their digital service design process, requiring teams to explicitly map who benefits and who is burdened by proposed features before moving to development. The Digital Equity Act, passed as part of the U.S. The Infrastructure Investment and Jobs Act of 2021 created federal-level accountability mechanisms to ensure that digital products funded by public money meet equity standards. These aren’t just feel-good policies; they’re governance mechanisms that give equity teeth.
Bringing Justice Practices to Your Team
Your team may not be operating at that scale. However, you can start smaller. A pre-launch equity checklist that asks teams to document which populations they haven’t tested. A required field in your design spec that names who might be harmed by this feature. A quarterly review of your research participant demographics with a standing question: “Who did we not hear from, and why?” These are small bureaucratic moves. But bureaucracy, for all its negative reputation, is how organizations remember things. It’s how you ensure that design justice survives the departure of the individual champion and becomes part of the culture.
Design justice isn’t a destination you arrive at. It’s a direction you commit to traveling in, knowing the road is long and your own blind spots are part of the terrain. It asks you to hold two things at once: genuine humility about what you don’t know and fierce accountability about taking action anyway. The communities most harmed by thoughtless design have been waiting for accessible health apps, for government services that work in their language, and for products that don’t treat their lives as edge cases—not while designers figure out the perfect framework, but while teams make small, concrete, consistent choices to do better.
The question isn’t whether you have the skills to center marginalized voices. The question is whether you have the will to try, to be corrected, and to try again. Because that’s what justice design, or otherwise, actually requires of us.
