For most cisgender people, meaning individuals who identify with the gender they were assigned at birth, filling out a form asking about their sex is uneventful.
For them, it’s a commonplace question that doesn’t require much thought because they fit the options given: Are you male or female? Sure, I’m one or the other.
Similarly, it’s unproblematic to have the HR department register their sex along with other personal and demographic information in the employee file.
For people who don’t fit the mold of binary genders, being asked how they fit into two non-fitting categories is not neutral.
It sets them apart as abnormal (Hello, “Other”!), enforces an implicit social devaluation, and potentially triggers trauma about how a society that still largely expects people to conform to one of two genders, will allow them to… be themselves.
When we built the first version of Valuebeat things moved fast.
It’s the scrappy-startup reality that you can’t invent everything from scratch.
You steal and borrow wherever you can - and some of these quick fixes are bound to be less than ideal.
When we reached the stage where we finally had the luxury to do user research and iterate on the product, redesigning how gender was represented in our product was a strong request from our product team.
We realized, that the way we collected data on employees' genders rested on assumptions about sex and gender that were unintentionally exclusive and problematic. And we wanted to change that.
We want to make this design process as transparent as possible. To do so, we’re sharing the reflections and research that led us to our current solution.
To be brutally honest, we started out not even realizing that we were asking for people’s sex.
Simply because we weren’t conscious of the difference between biological sex and social gender.
The problem is, that asking about sex – and not about gender – implies biological sex and marginalizes people who don’t identify with the gender they were assigned at birth.
Not to mention that it asks about an entirely irrelevant piece of information when you’re a software provider collecting data on culture.
The functionality of our product isn’t impacted by the sex of users as it would be if we provided, say, medical services.
So why should we justify incorporating information that is a likely trigger for people who have been questioned about and questioning their gender identity more than should be necessary?
That’s why we don’t include options for Male or Female in our gender selector.
Instead, we ask whether you identify as Man, Woman, Non-binary/Genderqueer – or if you prefer not to disclose.
We knew we wanted to create a solution that removed as much friction as possible for users.
At the same time, it had to be easy to understand for our clients.
At the end of the day, we can only justify asking about gender if collecting the data will promote more inclusive organizations.
This means making compromises.
We knew that if we included too many gender options, the data sample on each variation would be too small.
To protect anonymity, Valuebeat will only show you data samples of more than five people.
If we were to include anywhere up to 64 different gender identities, the data would be useless.
Non-binary describes someone who doesn’t identify as either man or woman.
It can mean that they identify with both of these gender identities or neither of them. It basically just indicates that you are somewhere else on the spectrum than on the binary poles.
Genderqueer usually describes a fluid gender identity. Rather than “fitting” one category, being genderqueer means fluctuating on the gender spectrum, and that the gender identity of the person is not “fixed”.
We use these umbrella terms to acknowledge that binary genders aren’t representative of reality and that individuals can fit anywhere on a spectrum.
We won’t pretend that this was an easy decision. Or that we have the perfect solution.
From our user research we learned that identifying as a woman or a man was emotionally difficult for transgender people who didn’t feel that they would yet “pass” as the gender they felt like, e.g. man or woman.
In that case, it would feel more legitimate for them to be able to use a Trans Man or Trans Woman option.
We have two reasons for not including these options.
First, that if we included Trans Woman/Trans Man, we would need to use Cis Woman/Cis Man instead of simply Woman/Man. This would be necessary to avoid the implication that one is a category of “real” women/men, when the reality that these terms simply reflect how aligned your gender is to the one you were assigned to at birth. Both categories are in fact, women and men - and transgender persons can also identify as non-binary or genderqueer as well as with binary genders.
We believe, that at this point in time, not all users and admins will feel confident about the distinction between cisgender and transgender, making it confusing to fill out the form and interpret the data. And we need to make the data useful.
Secondly, it is our wish that users should feel safe to identify the way they feel. No matter how society would “read” them or what they would “pass for" according to their appearance.
In many ways, we would have preferred to ask people about their pronouns instead of their gender.
It was the preference in our user research. Informants would rather be asked about their pronouns, than about their identity.
We would rather ask people about how we should address them than ask them a very personal question about their identity.
We chose not to ask for pronouns because we felt that the risk of misinterpreting the data would be too big.
Any data point is only as good as the humans interpreting it.
Pronouns do not always correlate with the gender identity of an individual and a person can use more than one set of pronouns, e.g. both she/her and they/them.
We feared that admins would still feel compelled to translate pronouns into gender categories. Leading them to assume that an individual who uses the pronoun she/her is a woman which would ultimately still leave it up to others to assign gender, instead of allowing users to self-identify.
We don't pretend that we’ve designed a flawless solution. And we don’t believe that we should have the final say.
If our users feel that they’re not included in the options given we strongly encourage them to inform us.
Our categories should reflect the reality of users. Not the other way around.