Mind the Pronoun Gap: UX Suggestions for Transgender and Nonbinary Inclusion
I spend a lot of time thinking about the user experiences of transgender and nonbinary individuals. I’m a UX designer and researcher. I also identify as genderqueer — I use they/them pronouns as well as she/her pronouns, and I go by my middle initials CJ instead of my legal first name. This makes me a living edge case, stress testing pretty much every user profile system I’m added to.
Based on this combination of UX perspective and edge case experience, I have 8 suggestions for managing name and pronoun data in ways that help support transgender and nonbinary software users. These are focused on strategy and implementation. For additional resources on trainings, wording, and the business case for gender diversity check out The Argo Collective.
These are based in my experiences as well as extensive conversation with other queers and technologists. While these guidelines should be helpful in most situations, queer identities and experiences are incredibly diverse — these won’t cover every queer perspective.
1. Collect only what is needed
Before collecting name, sex, or gender information, have some conversations to define why you need that data, and how you expect to use it. If you don’t need it, stick with a username and don’t collect personal information at all.
(A note on names: It’s common to see “preferred name” used to describe the name a transgender or nonbinary person goes by every day, to provide a distinction from the “legal name” on documents like a drivers license. I intentionally don’t use the term “preferred name” in this piece, since it implies that a person’s name is an option or preference rather than a fact. I use“name” to denote the name an individual uses every day, and “legal name” for names listed on official documents.)
2. Explain how data will be used
Help users understand what you’re asking so that they can answer in ways that meet your needs and theirs, and that keeps them safe.
Even data fields that seem simple become nuanced as they map to the complexities of human experience. For example, a friend of mine is the birth parent of their kid, and goes by Dad. This makes the text field “Mother” a quandary sometimes — is it collecting information on the birth parent? The person the kid calls Mom? The main caregiver? Specifying why information is needed and how it will be used is a good way to clarify these questions and collect cleaner, more useful data.
3. Make it easy to edit and hack fields
Name and pronoun fields should be easy to find and easy to edit. Any changes to these fields should update elsewhere quickly and universally. If this isn’t the case, expect users to hack available fields based on their needs.
A colleague of mine works in the gender clinic at a large teaching hospital. The clinic software has pronoun options, but those pronouns aren’t visible to clinicians while they’re in treatment rooms with patients. The clinic lists pronouns in the allergy alert field instead, because that field has the breadth of propagation and the level of importance they need. User hacks like this are a great source of insight for how to build more effective solutions.
4. Actually use the pronouns and names users provide
Many user profile systems have a field for “Nickname” or “Preferred Name”. The first few times I came across these fields as a user, I felt a warm glow of being supported and seen. But in my experience the data entered in this field is usually stored somewhere while the “Legal Name” field is used as the default and pushed out to other systems.
If software offers a “Nickname” or “Preferred Name” field, the name entered in that field should be used as the default in all internal- and external-facing systems. This includes ID badges, chat platforms like Slack, company email addresses, internal directories, mail merges, and all records where a legal name isn’t required.
I’m seldom “outed” as LGBTQ by other people these days. In the past couple of decades — in the realms I typically move in — it’s become possible for more people to live openly. It’s also become understood that identity disclosure is a personal decision and that outing is generally inappropriate. However, I’m “outed” by software constantly. I get called by my legal name (which I don’t go by because it feels uncomfortably feminine for my identity) at least monthly — by customer service reps, in clinic waiting rooms, by coworkers bringing it up as a curiosity over beers. Name field defaults disclose information every day that we would think twice about disclosing in most other settings.
5. Test systems (so that vulnerable users don’t have to)
Make sure to QA or otherwise test changes as they’re put in place. And consider testing user-created hacks as well, until purpose built solutions are developed. A friend of mine worked hourly at a small nonprofit while he was transitioning. He asked HR if he could write his male name on his timecard, even though his paycheck were still made out to his female name. He was welcome to try, HR said, but they didn’t have a way of knowing whether their system would still generate his paychecks. Being able to test these processes, or at least maintain manual oversight over them, is an important part of supporting transgender and nonbinary individuals.
6. Support staff who support users
Staff should have access to clear information about how individuals they interact with want to be addressed. This empowers existing allies to support transgender and nonbinary individuals more effectively, and it generally helps prevents micro-aggressions and social gaffes.
7. Translate on users’ behalf (when appropriate)
Transgender and nonbinary folks spend a disproportionate amount of time troubleshooting software that isn’t yet designed to include them. In many cases it will be inappropriate to do this work on a user’s behalf since it involves private personal information. But in some cases like HR and health insurance it’s worth asking whether trusted staffers could be empowered to do some of this troubleshooting work.
8. Be prepared to follow through
An organization that includes pronoun and preferred name options in its software is signaling that it is equipped to include and support gender diverse individuals. But inclusivity in software is just one piece organizational diversity and inclusion. Software changes must be part of organization-wide inclusivity efforts that include trainings, physical spaces such as all-gender bathrooms, and supportive policy language.
I first presented these guidelines at the 2018 Lesbians Who Tech conference in San Francisco. The talk is available on YouTube with closed captioning.