On Inclusive Personas and Inclusive User Research  ## Metadata - Author: [[CSS-Tricks]] - Full Title: On Inclusive Personas and Inclusive User Research - Category: #articles - Document Note: --- tags: - #inclusive-design - #user-research - #personas Author: CSS-Tricks (notes on Eric Bailey’s work) Source: CSS-Tricks Reference: https://css-tricks.com/on-inclusive-personas-and-inclusive-user-research/ date created: 2025-09-19 00:00 --- # Title: Inclusive personas and inclusive user research — notes and applications ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) ### References: - Eric Bailey’s article referenced and discussed within the CSS-Tricks post. - Cambridge University Press article on Radical Participatory Design (RPD). ## 📝 Summary: The notes argue for shifting from generalized, market-style personas to inclusive, experience-centered personas that identify concrete barriers to access. Assistive technology is framed as a means (not an end) used by many people, disabled or not. Inclusive personas should be integrated into general personas to avoid marginalization. Radical Participatory Design (RPD) flattens power by making community members equal decision-makers. Practical takeaways include member checking, interrogating org constraints, and creating feedback loops that let participants correct artifacts. ## 📖 Main Content: - Inclusive vs traditional personas: - Traditional personas generalize patterns for target segments; inclusive personas foreground individuals whose specific contexts reveal systemic barriers. - Goal shift: from trend discovery to barrier identification and remediation. - Assistive tech realities: - Not exclusive to disability; heterogeneous usage; multiple tools; varying mastery; compliance ≠ usability. - Universal benefit mindset: curb cuts, elevators, captions. - Integration, not separation: - Decoupling “inclusive” personas makes them ignorable; disability is part of audience diversity. - Example lens: before adding drag-and-drop, determine whether it’s necessary and ensure non-interfering alternatives. - Radical Participatory Design (RPD): - Meta-methodology centering equal participation and decision-making power; flattens power structures. - Counters “model minority” narratives by resisting reductive assumptions. - Actionable practices: - Let go of control; member checking; scrutinize roles/structures; open artifacts to participant corrections. ### 🗒️ Notes - Definitions and reframing - Inclusive personas: individual experience > aggregate trends. - Primary aim: locate concrete, insurmountable access barriers. - Assistive technology - Means, not end. - Multi-tool usage is common; some use none. - Skill varies; overfocus on one AT harms others. - Technical compliance can still fail usability. - Integration into core research - Disability is part of diversity; must appear in personas. - Avoid “special appendix” treatment that invites de-prioritization. - Evaluate new features for cross-experience impact. - RPD principles - Equal membership and power for participants. - Ongoing co-creation; decolonizing stance. - Operational takeaways - Member checking cycles. - Examine organizational incentives and constraints. - Artifact transparency and correction pathways. ## 📖 References: - CSS-Tricks: On inclusive personas and inclusive user research: https://css-tricks.com/on-inclusive-personas-and-inclusive-user-research/ - Radical Participatory Design (Cambridge University Press) — as cited within the CSS-Tricks notes. ## 🗣️ Paraphrase: - Original idea: Inclusive research focuses on individuals to surface concrete barriers to content access; trends and patterns belong to general usability testing, which also applies to disabled people because they’re people. - Paraphrase: Inclusive studies prioritize personal contexts to uncover specific obstacles blocking access. If you want behavioral patterns, run standard usability tests—those motivations apply to disabled participants too, because disability doesn’t erase shared human goals. - Original idea: Separating inclusive personas from general personas makes them easy to dismiss; disability is part of diversity and should be represented within core personas. - Paraphrase: When you park “inclusive” personas in a separate lane, they get ignored. Treat disability as a normal dimension of your audience by embedding those realities within your main personas. ## 📰 Newsletter: This week in WordPress and webcraft: Learning journeys, inclusive UX wins, and fresh tools. - Learning: Revisit personas with an inclusive lens—build for real people by identifying concrete access barriers, not just market segments. Bonus points for member checking and offering non-drag alternatives where it matters. - Community: Shout-out to teams experimenting with Radical Participatory Design—flattening power so community contributors co-own decisions. - New plugins: Keep an eye out for accessibility helpers that auto-flag keyboard traps and missing names/roles—small linting saves big headaches. - Snackable tips: Compliance is not usability; captions help everyone; and “clever UI” shouldn’t block core tasks. Further reading: CSS-Tricks on inclusive personas and research: https://css-tricks.com/on-inclusive-personas-and-inclusive-user-research/ ## ✅ Action Items: - For open-source advocacy and WordPress: - Create integrated personas for WordPress contributor onboarding that include disability contexts (screen reader users, voice control, low bandwidth). - Run member-checking sessions with underrepresented contributors; grant veto power on docs that describe their workflows. - Audit high-friction contribution tasks (first PR, Trac ticket, plugin review) for keyboard-only and AT support; publish a remediation backlog. - Develop workshops: “From compliance to usability in Gutenberg,” showcasing alt patterns for drag-and-drop and complex blocks. - OSPO path: Establish an RPD charter for major initiatives (governance, sustainability funding) with participant co-ownership of decisions. - Transparency: Publicly log research artifacts and changes prompted by participant feedback. - Education: Build a micro-credential on inclusive research for Core and Make teams; embed checklists into PR templates. ## 🧪 Hypotheses: - Integrating disability contexts into core personas reduces post-release accessibility issues by ≥30%. - Member checking increases documentation accuracy and contributor retention by ≥15%. - Offering non-pointer alternatives to drag-and-drop improves task completion for all users by ≥10%. ### 📊 Methodology: - Mixed-methods: task analyses, heuristic reviews for AT, moderated usability with diverse participants. - Data sources: GitHub/Trac issue trends, support forums, plugin repo feedback, telemetry on keyboard interactions. - Analysis: pre/post intervention defect rates, time-on-task, SUS and SUPR-Q, thematic coding of participant feedback. ### ❓ Questions: - Which contributor journeys most frequently surface access barriers? - Where does “technically compliant” fail real usability in WordPress? - What decisions should participant co-owners control in an RPD model for Core? ### 🔮 Future Research: - Comparative study: Separate vs integrated persona models on backlog prioritization. - Longitudinal effects of member checking on governance docs. - Impact of AT diversity (screen readers vs voice vs switch) on Gutenberg patterns. ### 💡 Implications: - Embedding inclusive personas can shift roadmaps toward universally usable features. - RPD-adjacent governance may improve legitimacy and sustainability of open-source decisions. - Better onboarding accessibility - Summary: A set of notes taken from Eric Bailey's article about the use of inclusive personas and user research. - URL: https://css-tricks.com/on-inclusive-personas-and-inclusive-user-research/ I’m inclined to take a few notes on [Eric Bailey’s grand post](https://ericwbailey.website/published/on-inclusive-personas-and-inclusive-user-research/) about the use of inclusive personas in user research. As someone who has been in roles that have both used and created user personas, there’s so much in here What’s the big deal, right? We’re often taught and encouraged to think about users early in the design process. It’s user’ centric design, so let’s personify 3-4 of the people we think represent our target audiences so our work is aligned with their objectives and needs. My master’s program was big on that and went deep into different approaches, strategies, and templates for documenting that research. And, yes, it is research. The idea, in theory, is that by understanding the motivations and needs of specific users (gosh, isn’t “users” an [awkward term](https://jnd.org/words-matter-talk-about-people-not-customers-not-consumers-not-users/)?), we can “design backwards” so that the end goal is aligned to actions that get them there. Eric sees holes in that process, particularly when it comes to research centered around *inclusiveness*. Why is that? Very good reasons that I’m compiling here so I can reference it later. There’s a lot to take in, so you’d do yourself a solid by [reading Eric’s post in full](https://ericwbailey.website/published/on-inclusive-personas-and-inclusive-user-research/). Your takeaways may be different than mine. ##### Traditional vs. Inclusive user research First off, I love how Eric distinguishes what we typically refer to as the general type of user personas, like the ones I made to *generalize* an audience, from inclusive user personas that are based on *individual experiences*. > [Inclusive user research](https://survicate.com/blog/inclusive-user-research/) practices are different than a lot of traditional user research. While there is some high-level overlap in approach, know the majority of inclusive user research is more **focused on the individual experience** and less about more general trends of behavior. > > So, right off the bat we have to reframe what we’re talking about. There’s blanket personas that are placeholders for abstracting what we think we know about specific *groups* of people versus individual people that represent specific *experiences* that impact usability and access to content. > A primary goal in inclusive user research is often to **identify concrete barriers that prevent someone from accessing the content they want or need**. While the techniques people use are varied, these barriers represent insurmountable obstacles that stymie a whole host of navigation techniques and approaches. > > If you’re looking for patterns, trends, and customer insights, know that what you want is **regular user testing**. Here, know that the same motivating factors you’re looking to uncover also exist for disabled people. This is because they’re also, you know, people. > > ##### Assistive technology is not exclusive to disabilities It’s so easy to assume that using assistive tools automatically means accommodating a disability or impairment, but that’s not always the case. Choice points from Eric: * First is that **assistive technology is a means, and not an end**. * Some disabled people [use more than one form of assistive technology](https://ashleemboyer.com/blog/disability-is-not-a-single-selection-field), both concurrently and switching them in and out as needed. * Some disabled people don’t use assistive technology at all. * Not everyone who uses assistive technology has also mastered it. * **Disproportionate attention placed on one kind of assistive technology** at the expense of others. * **It’s entirely possible to have a solution that is technically compliant, yet unintuitive or near-impossible to use** in the actual. I like to keep in mind that assistive technologies are for *everyone*. I often think about examples in the physical world where everyone benefits from an accessibility enhancement, such as cutting curbs in sidewalks (great for skateboarders!), taking elevators (you don’t *have* to climb stairs in some cases), and using TV subtitles (I often have to keep the volume low for sleeping kids). That’s the *inclusive* part of this. Everyone benefits rather than a specific subset of people. ##### Different personas, different priorities What happens when inclusive research is documented separately from general user research? > Another folly of inclusive personas is that they’re decoupled from regular personas. This means they’re **easily dismissible** as considerations. > > […] > > **Disability is diversity**, and the plain and honest truth is that diversity is missing from your personas if disability conditions are not present in at least some of them. This, in turn, means your personas are misrepresentative of the people in the abstract you claim to serve. > > In practice, that means: > […] we also want to hold space for things that need direct accessibility support and remediation when this consideration of accessibility fails to happen. **It’s all about approach**. > > An example of how to consider your approach is when adding drag and drop support to an experience. […] [W]e want to **identify if drag and drop is even needed to achieve the outcome the organization needs**. > > Thinking of a slick new feature that will impress your users? Great! Let’s make sure it doesn’t step on the toes of other experiences in the process, because that’s antithetical to inclusiveness. I recognize this temptation in my own work, particularly if I land on a novel UI pattern that excites me. The excitement and tickle I get from a “clever” idea gives me a blind side to evaluating the overall effectiveness of it. ##### Radical participatory design Gosh dang, why didn’t my schoolwork ever cover this! I had to spend a little time reading the [Cambridge University Press article](https://www.cambridge.org/core/journals/design-science/article/an-introduction-to-radical-participatory-design-decolonising-participatory-design-processes/63F70ECC408844D3CD6C1A5AC7D35F4D) explaining **radical participatopry design** (RPD) that Eric linked up. > Therefore, we introduce the term RPD to differentiate and represent a type of PD that is participatory to the root or core: full inclusion as equal and full members of the research and design team. Unlike other uses of the term PD, RPD is not merely interaction, a method, a way of doing a method, nor a methodology. It is a meta-methodology, or a way of doing a methodology. > > Ah, a method for methodology! We’re talking about not only including community members into the internal design process, but **make them equal stakeholders as well**. They get the power to make decisions, something the article’s author describes as a form of decolonization. Or, as Eric nicely describes it: > Existing power structures are flattened and more evenly distributed with this approach. > > Bonus points for surfacing the **[model minority theory](https://mindworkscollab.org/model-minority-myth/)**: > > > The term [“model minority”](https://www.learningforjustice.org/magazine/what-is-the-model-minority-myth) describes a minority group that society regards as high-performing and successful, especially when compared to other groups. The narrative paints Asian American children as high-achieving prodigies, with fathers who practice medicine, science, or law and fierce mothers who force them to work harder than their classmates and hold them to standards of perfection. > > > > > > It introduces exclusiveness in the quest to pursue inclusiveness — a stereotype within a stereotype. ##### Thinking bigger Eric caps things off with a great compilation of actionable takeaways for avoiding the pitfalls of inclusive user personas: * Letting go of control leads to better outcomes. * Member checking: letting participants review, comment on, and correct the content you’ve created based on their input. * Take time to scrutinize the functions of our roles and how our organizations compel us to undertake them in order to be successful within them. * Organizations can turn inwards and consider the artifacts their existing design and research processes produce. They can then identify opportunities for participants to provide additional clarity and corrections along the way., On Inclusive Personas and Inclusive User Research, CSS-Tricks, 01k5hfpvcnxst84d8jbwgqdanm.