Rooting out unconscious bias in user personas

Rooting out unconscious bias in user personas

Cognitive empathy requires not a face, not preferences and demographics, but the underlying reasoning, reactions, and guiding principles. Without these you cannot develop empathy. And if you cannot develop empathy, you cannot wield it — you cannot walk in someone’s shoes.

Indi Young, “Describing Personas,” Medium.com, 15 March 2016.

Table of Contents

The trouble with user personas

I was asked recently if I thought user personas lead to inevitably biased designs. I stumbled to provide a good answer because my confidence over my own use of personas had been plagued with self-doubt.

In my experience as a UX designer, I have often found it hard to convince project stakeholders of the importance of personas and to maintain use of them on the design team. And whenever I sought out best practices for creating user personas, I came up with conflicting opinions from marketing and design professionals.

All of this left me struggling to provide a direct answer, which is why I set out to write this article — to provide a deeper analysis on the topic of user personas and unconscious bias.

Please note: I would love to engage with other people on this topic and any holes in my research or analysis. Please share your thoughts in the comments section below.

(TLDR) too long, didn't read

Many designers believe that user personas inevitably create biased products because when you make generalizations about a group of people, you have little to go on other than your biased assumptions.This can be true, depending on how you make and use personas. And it may be tempting to use alternate methods to avoid the uncomfortable topic of creating biased representations of users altogether.

But in this post, I argue that you should make representations of your users somehow because the act of creating a persona can help designers go deeper into a product’s value proposition — unlocking far more creative possibilities and discussions than just solving for a task.

So how do you tap into the power of representing your product’s users in meaningful, unbiased ways? By following the professional discourse over user personas since they first originated in 1999, I’ve drawn together some of the key ways to get value out of user personas without perpetuating harmful stereotypes:

  • Diversify your design team, and have a plan for how you’ll handle microaggressions.
  • Focus on context and rationale, and remove any unnecessary demographics.
  • Remove the persona’s name, and name the behavior.
  • Remove the images, or use images that humanize users and challenge stereotypes.
  • Base the personas on user research.
  • Adapt user persona templates to your needs.
  • Make the user persona a collaborative effort as well as a living document.

Rather than finding irrefutable arguments either for or against user personas, I found that the most accurate and ethical approach is to combine user personas with an analysis or their key tasks. User personas should be consciously edited for scope and biases and backed by user research, not just assumptions. The best “proof” of a user persona’s effectiveness is not how completely it maps to real user segments (a technical impossibility) — instead it must pass the test of demonstrating predictable behavior in front of a group of design decision-makers.

What are user personas, and why do designers and marketers create them?

A user persona is a fictional representation of a user or group of users of a service, product, site, or brand. Personas are created to assist design teams in decision-making before, during, and after an iterative design process. The content of a user persona can either be based on assumptions (empathy mapping) or based on user research (interviews, contextual inquiries, focus groups, shadowing, and quantitative data). They typically include a picture, name, demographics, attitudes, goals, values, motivations, needs, wants, behaviors, technology used, accessibility needs, pain points/frustrations, and quotes.

Where did user personas come from?

The concept was created by Alan Cooper in his 1999 book The Inmates Are Running the Asylum1 and further developed by Tamara Aldin and John Pruitt in their 2006 book The Persona Lifecycle.2 Starting in 2016, a debate evolved over whether the user persona or Clayton Christensen’s Jobs to Be Done model is more appropriate for UX design projects.3 Around the same time, Indi Young’s Medium post “Describing Personas” sparked further discussion about how personas play a role in creating biased products.4

What are the commonly believed benefits of user personas?

The following are the commonly believed benefits of user personas:5
  • They help designers avoid designing for themselves or a “general” user.
  • They humanize complex data about users through storytelling.
  • They help designers build empathy for different users’ experiences, which helps designers better design for their product’s use cases.
  • They help designers balance the competing needs of different users.
  • They serve as proxies for users (when based on assumptions).
  • They help designers engage with users (when based on user research).
  • They align a design team around a common design goal.
  • They help manage the collective decision-making of a user-centered design process.
  • They make it easier to describe a product, service, site, or brand to stakeholders or outside consultants.
  • They add value to other user research activities.

What are the common critiques of user personas?

The commonly held critiques of user personas are as follows:
  • They are mere representations (stereotypes) and don’t account for the complexity of human experience.6
  • They are not verifiable because you cannot irrefutably map a persona to a user segment.7
Since the topic of this article is user personas and unconscious bias, I’ll focus on that. But before moving on, I want to briefly touch on verifiability of user personas as a false dilemma. Being widely understood as fictional archetypes, user personas aren’t evidence of anything. And as already established by the commonly believed benefits, they are primarily used in the product design community as a tool for shifting mindsets and making design decisions.

How have unconscious biases shaped product design?

Susan Turner and Phil Turner pose the key question in their 2010 article “Is stereotyping inevitable when designing with personas?”8 They define persona creation as a “representational process.” The output of the process could interchangeably be labeled archetypes, categories, or stereotypes. They go on to describe how essential this representational process is to “engag[ing] with a situation with the minimum of cognitive effort.”

In other words, these unconscious generalizations keep us from overthinking our reality with each new interaction. However, just because stereotyping is natural human behavior, it doesn’t necessarily follow that personas are therefore natural and good.

Designs have an important role in our lives as consumers. They send us messages about who qualifies as a product’s “ideal user” and who is excluded. These messages then go one to shape our relationships to different products.

Watch out for personas that diminish, prescribe, and dehumanize.

Diminishing personas

Personas that diminish users assume a user is less capable than they actually are. Women are often the target of this type of bias. Turner and Turner offer the example of early word-processing software development, where these companies assumed “secretaries were permanent novices” and designed accordingly.9

Prescribing personas

Personas that prescribe draw on stereotypes that only certain types of people do certain things. An example of prescribed personas example can be drawn from Alan Cooper’s The Inmates Are Running the Asylum — the origin of the user persona concept.10 Cooper uses an analogy of three different car buyers to demonstrate the need for personas: Joe the Carpenter, Seth the Junior Executive, and the [nameless] Soccer Mom. Can you guess to whom Cooper assigned the desired car features “rugged,” “sporty,” and “safe?” And what did you first assume about the genders, races, abilities, and sexual orientations of each occupation? These assumptions impact the options we make available to users in our designs.

Dehumanizing personas

Personas that dehumanize use stereotypes that have direct consequences on someone’s well-being, freedom, or safety. These types of personas can certainly be made by humans, but as is becoming more common with Big Data, the next example is computer-generated. In Cathy O’Neil’s 2016 book Weapons of Math Destruction, she demonstrates how “proxies” (indirect data used in absence of direct data) are used to model algorithms with unconscious bias baked directly into the software.11 An example she uses is zip code as a proxy for a user’s “potential to pay back a loan or to handle a job.” Tying zip code to the likelihood of defaulting on a loan or being a good job candidate has the unfortunate consequence of targeting lower-income communities to a dehumanizing effect.

How can we minimize unconscious bias in user personas?

Diversify your design team, and have a plan for how you'll handle microaggressions.

One common recommendation to check for stereotyping is to diversify the ages, genders, races/ethnicities, income levels, and sexual orientations of your design team. The reasoning often given is that more diverse teams will catch and challenge more of the harmful stereotypes.12

 

However, diversity alone is not enough because it doesn’t take into account the impact of team members being exposed to these microaggressions. For example, a designer could create a persona including a harmful stereotype and share it with a teammate who happens to share an identity with the person depicted in the user persona. This puts them in an awkward situation to say the least. And one may also reasonably ask why improving the accuracy of your team’s user personas is a compelling justification for diversifying your design team if the ethical imperative of stopping discriminatory hiring practices is not motivation enough.

But if you’re already taking the opportunity to craft more inclusive hiring and retention practices, you might also consider how your team handles microaggressions. It’s far too deep of a topic to go into strategies for addressing workplace microaggressions in this article. Instead I’ll point you to a paper written by six Columbia University professors that is packed with recommendations for countering microaggressions at work.13

Focus on context and rationale, and remove any unnecessary demographics.

Some argue that demographics allow design teams to “relate” more to a user persona. However, critics of this use of demographics point out that this information can trigger unconscious bias and cause further harm. Many argue that you shouldn’t take removing demographics to an extreme. Some cases, like services that deal with the experience of racial violence, rightly require specifying a persona’s race and ethnicity demographics. Some demographics can be recast as more generalizable experiences — “life phases” instead of ages. Indi Young’s article provides some great examples of these arguments.14

My advice is that there shouldn’t be a hard and fast rule about demographics, but including demographics should be done with an editorial eye and a clear justification. In most cases, you will be better served focusing on the elements that are most key to a user’s experience — their context and their rationale.

Remove the persona's name, and name the behavior.

We are biased toward names from our own cultures because they are more familiar to us. This makes names from our culture sound more “natural” and names from other cultures more “foreign,” more “other.”15

This normalization and othering of names is taken to the extreme in a white supremacist culture. Take the name “Sally Manning” as one random name with an Anglo American origin. If we were creating a persona for Sally, in your mind, would you immediately think Sally might be an African American woman (even though many African American people have Anglo American names)? And what about Sallys who don’t identify as women? This may lead design teams to assume the race/ethnicity (and many other factors) of Sally’s intersectional identity.

So if a name isn’t useful for a persona other than to recall a specific persona, and it can lead us designers astray, why not use the ink to name the user’s behavior instead? If Sally prefers to watch YouTube videos for small home improvement projects rather than hiring a professional, why not call Sally “The DIY Fixer?” It’s more descriptive and memorable.

Remove the images, or use images that humanize users and challenge stereotypes.

As we’ve already established, a commonly believed benefit of user personas is that they help design teams “empathize” with users. Adding a headshot or an illustration gives “personality” to the persona. However, this can cause two problems.

The image can limit the team’s notion of who the persona represents the person depicted in the image. The other issue is that images paired with personas can further harmful stereotypes. One interesting strategy is to consciously choose an image of someone who isn’t normally associated with that stereotype or who is systematically excluded.16 An example would be someone with limited mobility using a fitness app. Another strategy is to use photos that portray the person in the context of the experience rather than using a headshot.

Base the personas on user research.

If your user personas are based on assumptions alone, you can pretty much guarantee that they will be based on biased assumptions. They can be the starting point for learning about users (commonly called proto-personas),17 but personas based on assumptions are little more than caricatures of meager value (and potential harm) when left unto themselves.

This isn’t to say that research always eliminates assumptions either. Due to confirmation bias, we always have the potential to seek “evidence” to validate our assumptions at the cost of better alternatives. Therefore it’s best to use observations of users’ behaviors and direct quotes when constructing their personas. Let the users speak for themselves rather than trying to judge or categorize their behaviors.

Limit the scope of the user personas.

This problem most commonly occurs when I ask if a company can tell me more information about their users. I typically receive an outdated, nearly forgotten file of user personas written from the perspective of the company, dividing all of its users into discrete buckets.

It’s hard to imagine that any problem could be solved with this broad of a scope. A user will engage with your product from a specific and meaningful point (their point in the customer journey, their context, their access needs, etc.).

If you’re looking for a good guide for determining the right scope of your personas, I recommend Kim Salazar’s article “Just-Right Personas: How to Choose the Scope of Your Personas.”18

Adapt user persona templates to your needs.

There are many sites out there that offer user persona templates (Xtensio, HubSpot, Miro, to name a few). These models are often packed with more content than you’ll actually need. 

Superfluous elements like favorite brands, preferred channels, and personality traits are added with the intent of “bringing the persona to life,” but if they aren’t based on relevant research from the beginning, they say more about the biased assumptions of their creators than the users they are supposed to represent. 

If we compare creating a user persona to drawing a portrait, personas should be more like a gesture drawing than a hyperrealistic portrayal. Focus on capturing just enough detail that your teammates can picture what this user might do in scenarios that are specific to your product. It’s OK to start with a user persona template, but use your editing skills to pare it down to just what you need to get the job done.

Make the user persona a collaborative effort as well as a living document.

It’s very common for persona creation to be the responsibility of one person on a design team. I’d argue that this should never be the case because the usefulness of a user persona is in the ability to use it to make collaborative design decisions. So personas need to be owned by the team that’s using them. Working collaboratively on persona-creation has the added benefit of catching biased assumptions before they make their way into influencing design decision-making (just mind those microaggressions). Research done by Adi B. Tedjasaputra, Eunice Ratna Sari, and Georg Strom suggests that just having people work in pairs to create personas can check some of these assumptions. The same study shows that writing personas in prose format rather than a bulleted list can also shift people from thinking of personas as just a checklist of attributes to creating a more nuanced description of their context and rationale.19

Another reason personas are often derided is because so much effort is put into them just to “empathize” with the user. While empathy can be an important mindset to access to consider new possibilities, the real long-term value comes in how you use them to deepen your inquiry into understanding your users’ behaviors. Personas can point out where you are making risky assumptions that require further testing. This is why they need to be revisited over each sprint and phase of a product.

Conclusion

Unexamined unconscious biases are a real problem for product design, and user personas can be used as a means of rooting them out before they have a chance to cause harm. Conversely, user personas also have the potential to perpetuate stereotypes that diminish, prescribe, and dehumanize the very users we aim to serve. But this dual potential of user personas is the reason to use them more thoughtfully, not to discard them completely. Personas help design teams generate new ideas, inform design decision-making, and guide subsequent rounds of user research. And they do so in a way that grounds the whole process in creating value for users, not just moving them frictionlessly through a flow. By working collaboratively to represent a user’s context and rationale and only including the persona elements that will move your design and research process forward, user personas can become an important piece in an inclusive design toolkit.

References

All hyperlinks referenced in this article were checked and accessed on 2 February 2023 (Groundhog Day groundhog emoji ).
  1. (Alan Cooper, >The Inmates are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity (Indianapolis: SAMS, a division of Macmillan Computer Publishing, 1999).
  2. John S. Pruitt and Tamara Aldin, The Persona Lifecycle: Keeping People in Mind Throughout Product Design (San Francisco: Morgan Kaufmann Publishers, 2006).
  3. Clayton M. Christensen, Taddy Hall, Karen Dillon, and David S. Duncan “Know Your Customers’ ‘Jobs to Be Done,’” Harvard Business Review, September 2016; [for debate about user personas versus JTBD, see also], Page Laubheimer, “Jobs-to-Be-Done vs. Personas,” video, Nielson Norman Group, 19 October 2018; Jared Spool, “Jobs To Be Done: An Occasionally Useful UX Gimmick,” Center Centre – UIE, 17 January 2019; also Emerson Schroeter, “Personas vs. Jobs-To-Be-Done: What’s The Difference And When To Use Them,” CareerFoundry, updated: 5 August 2021; also Sakshi Gupta, “User Personas vs. JTBD: Everything You Need To Know About the Two Top User Research Methods,” Springboard, 9 August 2021.
  4. Indi Young, “Describing Personas,” Medium.com, 15 March 2016.
  5. Phil Turner & Susan Turner, “Is stereotyping inevitable when designing with personas?,” Design Studies 32 (January 2011), e-journal; Young, “Describing Personas;” Gupta, “User Personas vs. JTBD;” Laubmeier, “Jobs-to-Be-Done vs. Personas.”
  6. Margaret Price and Doug Kim, “Kill Your Personas: How Persona Spectrums Champion Real User Needs,” Medium.com, 8 November 2018.
  7. Christopher N. Chapman & Russell P. Milham, “The Personas’ New Clothes: Methodological and Practical Arguments against a Popular Method,” Proceedings of the Human Factors and Ergonomics Society Annual Meeting, April 2014.
  8. Turner & Turner, “Is stereotyping inevitable…?”
  9. Ibid.
  10. Cooper, The Inmates are Running the Asylum, p. 124.
  11. Cathy On’Neil, Weapons of Math Destruction: How Big Data Increases Inequality and Threatens Democracy (New York: Crown, a division of Penguin Random House, 2016).
  12. Stephanie Musat, “How to Write Effective User Personas for a Diverse Audience,” Mindtheproduct.com, 29 April 2019.
  13. Derald Wing Sue, Sarah Alsaidi, Michael N. Awad, Elizabeth Glaeser, Cassandra Z. Calle, and Narolyn Mendez, “Disarming Racial Microaggressions: Microintervention Strategies for Targets, White Allies, and Bystanders,” Purdue University College of Engineering, n.d.; referencing American Psychologist, Volume 74, No. 1, (2019), pp. 128–142.
  14. Young, “Describing Personas.”
  15. Simon M. Laham, Peter Koval, Adam L. Alter, “The Name-Pronunciation Effect: Why People Like Mr. Smith More Than Mr. Colquhoun,” Journal of Experimental Social Psychology, Volume 48, Issue 3 (2012), pp. 752–756.
  16. Young, “Describing Personas.”
  17. Page Laubheimer, “3 Persona Types: Lightweight, Qualitative, and Statistical,” Nielson Norman Group, 21 June 2020.
  18. Kim Salazar, “Just-Right Personas: How to Choose the Scope of Your Personas,” Nielson Norman Group, 12 January 2020.
  19. Adi B. Tedjasaputra, Eunice Ratna Sari, and Georg Strom, “Sharing and Learning through Pair Writing of Scenarios,” Researchgate.net, October 2004, from the Proceedings of the Third Nordic Conference on Human-Computer Interaction 2004, Tampere, Finland, October 23–27, 2004.
Tagged

Leave a Reply

Your email address will not be published. Required fields are marked *

Linkedin

shokaisinclair.com

shokai@shokaisinclair.com

Denver, Colorado

© 2016–2023 Shokai Carter Sinclair