Or, how to model gender within computer systems.
Step 1: Don’t.
It’s glib, but it’s probably the best advice there is. Gender is a complex and multifaceted interpersonal phenomena. Even when we’re using natural language we can find it hard to communicate about our genders.
Dealing with time, translations and caching is hard, and as programmers we’re pretty good at recognizing that you shouldn’t overcomplicate things and add those things in when you don’t need to. Gender is just as difficult to manage as those, and your failures will have consequences. Poorly supporting gender will at best remind people that you don’t consider them ‘real’ or ‘worthwhile’ users, or at worst, open up a person to harassment, discrimination, and violence. Revealing a person’s trans status can kill.
So when you get the requirements for that sign up form, double check that the gender field is actually needed. Did another team member put it in there because they though it might be useful to know? Did someone just add it unthinkingly? Sometimes there are valid reasons for requesting gender information, but most companies just never need to know.
Step 2: Don’t be vague.
Let’s assume you’ve got past step 1 and you still need to put that gender field in there. Why? What exactly do you want? Working out what you are actually after will allow you to phrase the question to get valid input.
Do you want legal gender, to cross-reference against, say, a passport service? Do you want a person’s gender for tax purposes? Do you want to know what style of gendered clothing they’d like to buy? Are you building social network, and you want to display a gender on everyone’s profile? Are you building a healthcare system, and you want to know the assigned biological sex at birth? Or maybe their current biological sex? Or are you just asking for demographic statistics?
To use myself as an example: my gender is androgyne, my legal gender in the UK is female (for now), my biological sex is unknown, my gender grouping is “nonbinary”, I wear clothing in “men’s styles”, my name and title are gender neutral, my pronouns are “whatever people feel like”… and this can become tricky to enter on forms.
You should specify on the form exactly what you want the user to provide, if you want to have any hope of getting valid data. And you’d better do your research, because the possible answers to each of those questions are all different. A good place to start is the Nonbinary Inclusion Project’s best practice guidelines.
Step 3: Don’t make it required.
There are a lot of people with no gender and a lot of people who don’t want to share their gender with you. Unless you absolutely 100% have to (see step 1), don’t make gender a required field.
Step 4: Don’t make the user choose from a list.
Gender is hard to describe, even legally. Most of the time if you must have something, you just want a value you can store in the database and perform queries against.
Don’t provide a set list of options. Give people a free text box and let them type in what they like. It’s alright to add an example prompt to get people thinking along the right lines (like, some greyed out text reading “e.g. ‘Female’”). Most people won’t misspell things, and if they do — is it any worse than the noise there was from people choosing the wrong item in the list? Perhaps when you do your processing you’ll have to make some assumptions like ‘group all the people who said men with the people who said male’ — but you were making those assumptions before, built into the very fabric of your system.
Step 4a: If you must provide a list, don’t list ‘trans’ as a separate option to ‘man’ and ‘woman’. Trans men and women ARE men and women — what are they supposed to pick from that list? This was never an acceptable way of doing things.
Step 4b: If you must provide a list but have flexibility as to what you put on it, you should include options for women, men, nonbinary and/or genderqueer people, and something that represents not answering (such as an explicit ‘would rather not say’ option). This language survey by Cassian Lodge suggests that ‘nonbinary’ or ‘nonbinary / genderqueer’ are the best options we have at the moment. Try to avoid ‘other’ if you can - it is, quite literally, othering to nonbinary and genderqueer people.
Step 5: Don’t make it fixed.
Gender should be something that the user can change as easily as they change their contact information. Names need to change that easily too, as names often signify gender. Don’t make them fixed — make sure they can change, without needing your user to call your support helpline or get an admin to do it. Don’t enforce an arbitrary limit on how many times or how often they can change it. Make sure changes are entirely retroactive; don’t leave historical gender and names floating around.
The corollary to this is be very, very clear to your user about what you’re changing, and who will see that new information. Otherwise you run the risk of outing people.
If you work with software dealing with legally-regulated stuff (such as utility companies whose bills can be used as ID), then depending on your local laws you might need to set some limits to name and gender, such as requiring a deed poll. In this case, do your users a favour, and try to make it as easy as you can.
In OSX, to change the name of the user on my computer, I had to go through an arcane set of commands that risked losing everything on my hard drive. I’ve joined websites that authenticated using Google, saved my name, and provide no way for me to update it now without creating an entirely new account. In Git, there are commits in my previous name in repos I no longer have push access to, so if I want to identify that work as being mine I must out myself.
Our systems don’t need to treat binary trans people and nonbinary people as second-class citizens, as afterthoughts and exceptions and extra features. It’s just laziness and sloppy coding, because what a programmer thought was a simple problem was actually a really difficult one.
Take gender seriously, and get it right before your bugs hurt someone.