Summary: By avoiding tokenism in inclusive design, we gain true inclusion in design efforts. Tokenism means you are ‘going through the motions’ by including one or two underrepresented users. Instead, you need to give justice to marginalized groups and make them the focus of your user research efforts.
What is Tokenism in User Experience?
Typically, “ticking a checkbox” for inclusion is how tokenism occurs. To be clear, tokenism is the act of trying to bring representation of left-out users to a project and then undermining those very users. Tokenism distorts the true intent of inclusion. It leaves users out when it thinks it is including.
As a rule, tokenism is rarely intentional, how embarrassing to be caught pretending, right? In UX, tokenism takes on many forms:
- For example, having internal “users” (employees) act as customers: “Now, pretend you’re the customer”.
- For example, having employees with disabilities “do the accessibility” testing.
- For example, having employees of underrepresented groups weigh in on whether a design is insensitive (racist, sexist, ableist, homophobic etc).
- For example, sticking a ‘disabled user’ or underrepresented user in your personas project.
The first three relate to employees, so basically don’t just use employees and call it good. External, aka “real users” are vital for bringing real stories and voices to efforts to practice inclusion regularly. However, let’s unpack that last one…adding disabled or underrepresented users to your persona creation. For instance, the problem with this is that you may be inadvertently tokenizing by adding the eg blind user into a persona “for show”. In short, in order to avoid “check box inclusion”, make sure the blind persona comes from real user data and is part of an accessibility effort. Accessibility requires actual research or testing with users with disabilities.
Is it okay to co-opt employees with feedback, User Testing, Accessibility etc?
Of course, it is okay! The problem is if your research ends there. Employees are dangerous sources of feedback — this point isn’t made strongly enough in the UX community. I’m talking about “Down the hallway testing”; “Cafeteria testing”; “Guerrilla testing” . Why? Employees are biased (even if they don’t work in your group, they work at your company and that’s enough). Employees are also not realistic, and you should always test with actual users who are doing the thing you are studying in real life. Likewise, avoiding fake users is so important for quality insights.
Why wouldn’t an employee with a disability be able to speak for that group?
Firstly, chances are that employees with disabilities can provide a good deal of user advocacy, as would any person from an underrepresented group. However, organizational culture can change what employees feel safe to share. Certain experiences or information might not be acceptable (socially or emotionally). Worse, the spokesperson or chosen employee may be co-opted by the business needs, software architecture, or team constraints.
For example, a blind employee testing accessibility issues with her screen reader (on top of her regular job) failed to point out that access to the web application was blocked by another app. Logically this meant 100% failure for users. When this was pointed out, she simply said, “Oh yea, we already know that so I didn’t spend much time pointing that out”. (Actual story from an Experience Dynamics client project).
Another example*, a company that was loosing government contracts due to their software not supporting accessibility held a secret: their CEO failed to mention to the team that he was blind and that accessibility was a priority at a personal level. (Actual story from an Experience Dynamics client project).
*Contrast this with Microsoft CEO Satya Nadella, who used his son’s disability (cerebral palsy) to boost the company’s accessibility efforts and encourage all employees to be disability advocates. Oh, and he wrote about the experience in his widely-read book ‘Hit Refresh’, as did his wife in ‘A Mother’s Journey’.
What if you are tokenizing inclusion by being the Lone Wolf Advocate?
Inclusive Design is a team sport. You can accidentally have a tokenizing effect if you are the only one in your team that keeps ‘going on about ______’ (accessibility, including underrepresented groups).
It is important that Inclusive Design be taken seriously, but as a default and UX teams can be pivotal in this process. For example, if you want to improve accessibility (or have Disability Personas), it needs to come from research with users with disabilities as part of a formal accessibility effort — not a bolt-on “just in time” advocacy. Inclusive practices don’t come out of a team meeting or from the passion of one team member alone. The history of UX management tells us this is a failed approach.
Tokenism and Equity: how to get better
Tokenism has always been a problem in organizations. The pressures of “doing things right” versus meeting legal requirements for diversity or equality often clash. Speaking of equality, one of the reasons that is not top of mind is that it can tokenize quickly, e.g. “same for everybody” does not do justice to the group you need to empower. This is why Equity is the new “buzzword” in DEI (Diversity, Equity, Inclusion) efforts. Equity means proactively taking measures to support the specific needs of the left-out group or individual.
Conclusion
The only way to avoid and challenge tokenism is to balance internal ‘users’ with external users (representing the groups you are trying to include). Furthermore, give full justice (time, budget, effort) to the inclusion effort. Don’t try to do Inclusion after hours or part-time. Instead, bring the voices and stories of users from underrepresented groups to your team via UX Research, personas, and, ultimately to your critical design decisions.
