Asking for Gender in Applications

How to approach an inclusive gender question.

Pivotal Labs is the end-to-end product development consultancy arm of Pivotal. As an engineer here, I get to work with a wide variety of clients and their digital applications.

During my last project, we worked on an application for physicians and clinicians to manage patients and their data. The patient form included the following gender question:

Input form showing radio buttons for gender: Male, Female, or Other

The use of the word “other” as a gender category is “othering” and segregating. It actively casts people who are not one of the main two categories as outsiders, which suggests lesser status or importance.

This is not an anomaly. There is not a lot of awareness in the medical field (or most fields) of the transgender community. Medicine represents a particularly sensitive area as negative interactions can endanger lives.

The Product Manager, Designer, and I collaborated on research and alternative solutions. We found very few resources that were helpful or appropriate when thinking through the user experience of gender forms. We put together the following guide to help think through different approaches for gender questions based on its intended use.

Guidelines for how to create a gender form

Step 1:

Ask why this information is necessary. Why does this question add value? Often gender is a default field that is captured without a specific need. This is important to ask, given that the information opens up possibilities for discriminatory behavior [see report on discrimination in healthcare]. For example, service providers are legally able to refuse care to transgender patients under the pretext of “I do not have the appropriate training to care for this patient.”

Potential questions to ask:

• Is this for statistical analysis? If so, how is this information useful to classify data? (a common misconception is that the difference between male and female body types is statically significant enough to be of value; your specific lung capacity may be of more use than your gender).
• Is this for social purposes? Such as addressing someone based on personal preference (e.g., Him, Her, Them)? Unless it is a service or social platform, most apps do not need to care.
• In general, what is the added value for your specific product experience? Be sure to dig into the “whys” here, there may be a more targeted question that is better to ask. (E.g., are you capable of getting pregnant?)

Step 2:

If the question is necessary identify the best pattern for what you are trying to achieve. Pattern examples:

• Custom textbox for gender identification (Facebook)
  Gender options were male, female, custom, the latter created a textbox. Presumably Facebook needs this information for ad targeting, but potentially to explore variety of how people self-identify.

Gender form showing a drop down selecting “custom” and a text field allowing a custom gender entry.

• Dropdown for “what pronoun do you prefer” (Facebook)
  Presumably used most for services that want to refer to their customers in their preferred pronoun (e.g., him, her, them)

Pronoun selection dropdown with Female, Male, and Neutral options.

• Multi-option identification
  Allows users to select multiple forms of identification. This can be a good way of capturing better statistical data because there are a defined set of choices.

Identification form allowing a user to select all options that describe them. The options given are male, female, and transgender.

Hopefully these examples give some ideas on how to approach the issue with sensitivity to both the needs of users and the business requirements of the software. These are definitely not the only approaches. As with all UX elements, experimentation to fit the exact needs is encouraged.

Step 3:

Before building, test approach with transgender users. Most cisgender (not transgender) people are not aware of how these questions are perceived.

Step 4:

If / once you deploy, revisit your data and re-evaluate whether it is needed or if you should take a different approach depending on your intentions of use.

This is not an area that we often have to give thought to but it is also not complicated if we approach the user experience with empathy and consideration for the sensitive situations we may put our users in.

Thank you to my colleagues Josh Franklin and Caroline Hane-Weijman for collaboration on the project and on this post!

Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced and incorporated continuously through development and innovation, because good software is never finished.