I perform quality assurance testing in order to make the world a better place, starting with the products and services I test. As such, for Pride Month, I’d like to highlight some ways that designers, developers, and deciders can make the user management systems they work on LGBTQ friendly. Here are five recommendations for ways to build your system in a way that is affirming instead of isolating:
1. Don’t require static names or email addresses
There’s a concept in software QA called “maintainability” that refers to how easy it is to modify or update the system. Usually that kind of testing deals with things like software and product updates, but it can also apply to a system’s flexibility in allowing users to maintain and update their own information without breaking anything. I bring this up because the first item I’d like to touch on is that type of maintainability best practice. One easy, and maybe lazy, way to set up a database of users is to just make their email address their ID in the system. You use fewer fields, that’s simpler, right? Well, not exactly.
When you make the email address, name, or name-based user ID permanent and unchangeable, you run the risk of confronting users with their deadname down the line. A deadname, for anyone unfamiliar with the term, is the name someone used to use that they no longer identify with, usually but not exclusively due to a gender transition. For a lot of trans people in particular, the name they used to use before transitioning brings back dysphoria and is disaffirming. There are, of course, other reasons for your users to change their names – marriage, for example – and any time you ensure your system shows people the name they feel is theirs, your system is affirming their identity as who they are now.
2. If users have profiles, let them have pronouns
If your system allows social interaction, if it gives people the space to set up a profile for themselves, pronouns are part of how they want to be seen and interacted with, so you should make space for them explicitly in the profile fields. This helps anyone whose gender is not obvious from their name, or their photo, or their voice, and especially anyone whose pronouns are neither she/her nor he/him, because other pronoun sets are harder for most people to remember and having a reminder helps. This kind of thing can help smooth the learning curve for not only gender diversity but cultural diversity as well.
Since the English language hasn’t converged on a set of definite pronouns for people who don’t exclusively identify as either male or female, it’s not enough to just have a standard set of pronouns to select from. Also, because people’s genders don’t fit into neat categories, some people identify with more than one set of pronouns. The easiest and most flexible way around this is to just give a free-text field without character type restrictions. If you have a UI that wants to use pronouns for people, you could have a “What pronouns do you want our system to use for you?” that offers a standard set dropdown and an Other option with fill-in-your-own with fields for every tense, which you’d really want to restrict to a much shorter length and alphabetic characters only. That’s not a UI I’ve ever seen, though, because that’s complicated! In most systems you’re better off avoiding pronouns (“Contact Lauren”) or using they/them pronouns (“Say hi to them”) in referring to users, and letting the pronouns field just be for people to see on the users’ profiles.
3. Offer gender-inclusive options
If you are asking for a user’s honorific title, gender, sexual orientation, or transgender status, let them opt out, but give plenty of options if they want to provide that information. Honorific title shouldn’t just be “Mr, Mrs, Ms, Miss, Dr” it should have “Mx” in addition to any other options that might be relevant to your user base. Mx, pronounced “Mix,” long form tentatively “Mixter,” is a gender-neutral alternative to Mr/Mrs/Ms. Without such an option, nonbinary people without professional titles like Dr. must avoid this field or use a gendered title that is inconsistent with their gender identities.
If you are asking for a user’s gender, offer at minimum, “Male, Female, Agender, Nonbinary, Other, Prefer Not to Say” and allow multi-select. Sure, you’ll get users that select every gender because they want to make your data messier, but you’ll also get genderfluid people and people who identify as both nonbinary and male or female who will be able to select their full identities. Don’t include transgender as a gender. Ask that question separately if you ask it at all. If you are asking for sexuality, ask about “interested in” and offer the same gender options plus “No one” because asexual and aromantic orientations are real and valid. Be clear in the UI about where this information will be visible or searchable, because your users should get to choose what information to share with whom.
4. Don’t ask for sex assigned at birth
Just don’t. There may be some exceptions in the medical industry where this information is genuinely meaningful, but the vast majority of software and websites have no legitimate use to collect, store, or share this information. Don’t ask for legal sex, either, unless there is a legal requirement for you to collect that information. Legal sex can be kind of a complicated and uncomfortable question for transgender folks, so if you don’t need it, don’t ask for it.
If you really, really want to use a simple data set to profile your users with, be honest and say something like, “What gender would you like your ads targeted for?” and offer “Men, Women, Unspecified/Another Gender Identity” like the US Passport. Your dataset was going to be messy either way, but this way you tell people why you want them to put themselves in a gender box and give them a pretty inclusive way out.
5. Use preferred names, not legal names
As with legal sex, sometimes you need to ask for someone’s legal name. If you don’t need it, don’t ask, but if you do, always ask for a Preferred Name too. Once you’ve asked for that Preferred Name, use it! Preferred Name should override the Legal Name field wherever a Name is shown – whether that’s in the “Hello” message on your home page or the user-facing audit trail of user actions or the Name column in your Time Off Requests report. Anywhere the user sees their own name, they should see their Preferred Name, and anywhere other users see that user’s name, same deal. The only place Legal Name should show up in your UI is where it’s actually the correct name to use, and those are going to be very limited. Anywhere else, it’s confusing at best, and in some cases seeing a legal name that’s different from the one someone uses can out people as transgender to their colleagues.
Some additional notes:
It’s easy to approach a UI from your own perspective, but limiting your design to your own perspective is going to build a world that shuts people out. Build systems that respect and account for as many people as you can imagine. And if you’re telling yourself, “Sure, our systems don’t do these things, but we’re small, we don’t have any LGBTQ+ users, or if we do, they must not mind, or they’d tell us there’s a problem,” spend some time and really think about what that means. Don’t treat designing for LGBTQ+ users as a corner case, treat designing for the full breadth of the human experience as an exercise in creativity and a selling point for your system.
And the reason your users aren’t reaching out? Maybe they’re burned out on all the systems that don’t support them. Maybe they stopped using your product because it doesn’t seem to want them there. Maybe your support ticketing system doesn’t connect up to your developers’ bug tracking system, so you just never see the reports. Maybe your bug reporting system isn’t obvious to your users. You can’t rely on users to tell you when something is wrong unless it’s broken in a new or unusual way – that’s why it’s good to have QA professionals assess your product for accessibility, usability, and so forth. Aspiritech offers WCAG and Section 508 accessibility testing and its analysts and leads offer usability feedback from their personal and industry experiences in addition to testing for your requirements.
This article was written in collaboration with members of Aspiritech’s LGBTQIA+ and Gender Identity discussion groups, and so has had input from people with personal experiences where the items above would have helped them feel more included, including the author herself, who has a complicated relationship with gender and sexuality and is still figuring those out in her thirties.
