Five Requirements when Building Gender-Inclusive Products
Hello, friends! Today’s blog post is dedicated to five requirements that products need to meet in order to be gender-inclusive. I stumbled upon these requirements as I went through the unnecessarily painful process of updating my name in the workplace.
The intended audience of this blog post is product managers and engineers, although everyone is welcome as always. The goal is to enable (a) product specs and (b) system/data designs to be gender-inclusive.
A user story
I’m your user and I just came out as transgender. I need to update my name and gender-related information–which you may or may not have collected at account creation time–within my account for your product.
Below are five requirements that your product must meet in order to deliver on this user story. Each requirement is further broken down into Dos and Don’ts in an effort to make it as straightforward as possible to incorporate these requirements into your product today.
1.) Never use display information or personally identifiable information (PII) as a primary key
As your product’s user, I need to be able to update the name and gender-related information on my account without it breaking your product.
- Do not: Ever, ever ever use display information or PII (e.g. a user’s name, username, email, etc.) as any type of key. This includes keys for databases, caches, localstorage, or anywhere else you might store keyed data.
- Do not: Concatenate display data/PII into a key, generate a hash with this data, etc.
- Do: Use your user’s unique account ID as a primary key in these stores instead.
2.) *Do* correctly differentiate between gender identity, sex and pronouns in your product
As your product’s user, I need to trust that your company understands (and respects) the differences between gender identity, sex and pronouns.
- Do: Know what you’re asking, why you’re asking it and ask the question(s) correctly. Gender identity, sex and pronouns are three distinct things. As an example, my information would be: [gender identity] (transgender) man, [sex] assigned female at birth and [pronouns] he/him/his.
- Do: Ask for pronouns more often, especially if this information will be used by agents or employees in future communications.
- Do: Display pronouns in your UI as distinct, first-class personal information. Don’t force your users to include their pronouns as part of their last name or title.
3.) Model gender identity, sex and pronouns as strings (and not enums)
As your product’s user, I need to be able to accurately tell you my gender identity, sex and pronouns.
- Do not: Try to enumerate the sexes, gender identities or pronouns, as this literally forces you to “other” individuals.
- Do: Collect a user’s gender identity, sex and pronouns via a text input, with helpful labels or placeholders to assist users in inputting the data in the correct format as needed.
- Okay: To validate on the frontend that the gender identity/sex/pronoun data is provided in a certain format (e.g. “subjective/objective/possessive” for pronouns, although please keep in mind that users may identify with more than one pronoun).
4.) Ship with a PII change process
As your product’s user, I need to be able to update the name on my account without outing myself to a stranger.
- Do not: Make it impossible for your users to update their PII or display data.
- Do not: Force your users to open a new account to update their PII or display data.
- Do: Make it a launch blocker to ship your product with an internal/“back office” tool to allow your customer support agents (or employees) to update users’ display data on their behalf.
- Do: Make it at least a high priority fast-follow to ship a tool or feature that allows users to update their name, username, email, gender identity, pronouns (really all of the display data you collect) in a self-service manner.
5.) Refresh identity data via your auth provider regularly after user sign up
As your product’s user, if I signed up via a Google or Facebook (or other) integration, I need my updated information in those accounts to propagate to my account with your product in a timely manner.
- Do: Make it a launch blocker to implement a regularly scheduled job that queries your third party identity providers for updated information. Most of the time, this job won’t return anything new. But when it does, you have the opportunity of a lifetime to delight your users.
If you’ve made it here, thank you for product managing and engineering a better world. I’d love to connect with you on LinkedIn.
I will, of course, publish another post if I encounter more requirements on my journey, but I hope this is a helpful start. As usual, please leave any questions or comments–or additional requirements–you have below, and I will see you next Monday for my “One month on testosterone” update.
View previous post: Three Ways You Can Be a Transgender Ally in the Workplace Today | View next post: One month on testosterone update
