As this post goes live, I’ll be sharing a talk at AlterConf DC called “5 Simple Steps for Trans-Inclusive Data.” This talk originally crept into my brain as an idea for a very long blog post, and as I was preparing to cut that idea down to twenty minutes with Q&A time, I decided to also execute the original plan, since I can’t possibly say everything I want to about how to make data more trans-inclusive in fifteen minutes.

The post that follows is a detailed guide of specific steps you can take to make whatever data you work with more trans-inclusive, building off of the talk content. Skim through the list below and use any tips that you find applicable! I’m drawing from my experience working with member and donor data at national non-profit organizations, but you can apply this advice to any kind of human-centered data you collect including data on customers, employees, patients, survey respondents, and app users. My starting point here is that trans people can show up in any data set, and so it’s important to address the needs we have around privacy, comfort, and affirmation not as a special population but as a regular part of data strategy. Rather than othering trans people, consider our experiences an opportunity to improve your data collection, storage, and analysis practices for everyone!

If you’d like to hear more after reading the tips below, check out my speaking page for more information. I’m hoping to do more “dataqueer” talks and workshops in the future.

Balance needs carefully when asking about gender There is no one right answer to make your data trans-inclusive: what data you can respectfully collect and how you ask for it depends on your purpose

Ask: what are my/the organization’s/the company’s present and future needs? In what context will you need someone’s name, pronoun, identity, gender marker, etc. for your current purpose or in the future? For example: if you need to book someone’s flight or submit a legal form on their behalf, you may need to ask for a name that would be irrelevant if all you need to know is what someone would like to be called

Ask: why do I need this piece of data (for each piece you want to collect)? Make sure the question you ask on your form or survey is both specific enough and general enough based on what you actually need to know Example: if you’re trying to decide whether to ask if someone is “LGBT” versus trans-identified, consider whether you offer any additional benefit or tailored programming specific to trans folks, or whether potentially including trans folks separately in analysis could be beneficial and lead to more inclusion (rather than just wanting data for its own sake) Disclosure can be burdensome and risky, so do a cost-benefit analysis and be sure that any information you collect is for a purpose

Think ahead about potential changes to data structure It’s always harder to migrate data to a smarter structure later than it is to take the time to think about it now, so keep your future needs in mind If you ask a broad question and later want more specific data, you will have outliers that you may have to discard–for example, if you ask about transgender identity broadly and later want to do gender-specific outreach But if you ask a very specific question that you won’t ever need, then later go broad, it’s dangerous to assume that each narrow category goes neatly into the “umbrella” — for example, not all genderqueer people identify as transgender, and not all trans people want to be lumped under the “LGBT” acronym

Consider your audience in advance Does your data collection question make sense to your entire audience? Is your question culturally inclusive (examples: masculine-of-center vs. “AFAB trans people”, inclusion of indigenous and non-white terms)? Ask actual members of the community and do your research

Consider offering alternatives to mediate the tensions between data that is possible to analyze effectively and allowing folks to self-define For gender, you can offer male/female/something else but also offer a free text box for a more complete description If possible, let people identify with multiple communities (for example, someone can be trans, female, queer, and intersex simultaneously)

Develop an advanced plan for what to do if you receive external data that doesn’t conform to your structure Ask for gender, pronouns, and name contextually Many trans people answer these questions differently depending on who’s asking and why they want to know — for example, name might vary for: Phone and mail correspondence vs. online correspondence, particularly if you live with someone who isn’t aware of your trans status Official purposes such as filing legal documents, booking a flight, charging a credit card, or issuing a tax receipt: be as specific as possible about your purpose if you need this information and consider destroying later Public recognition such as a badge name or donor acknowledgement

Asking for this information contextually doesn’t just benefit trans people — it works well for nicknames, married name, and those who use different names depending on cultural or social context

Label fields as clearly as possible and keep original context on the backend Give the user help text to understand what you’re asking and how you’ll use the data — and give them a chance to opt out If a backend field label doesn’t say everything about how the information was collected, add a description — it’s easy to get confused later

If you need a lot of alternative fields, you may want to leave them all visible to everyone as a teaching moment, or consider a link like “I go by different names in different situations” that allows folks to expand their options on a form without stigmatizing or othering

Avoid value-laden and overly general language like “real,” “birth,” “legal,” or “preferred” — not only can it be offensive, but it’s also easy to forget how you’ve promised to use the data later and makes it hard to clearly update

Train staff and volunteers so they’re not surprised, for example, if someone has two “differently gendered” names or wants to change their name or gender identity in your database This also helps when you’re looking for duplicates in your data, since many folks who work with data aren’t aware that two records with “differently gendered” first names could be duplicates!

Avoid outing and protect privacy Honestly evaluate the security of your systems (technological and human) and be transparent with users about the degree of privacy they can expect

Only take data that you actually need so users have a choice not to disclose sensitive information (optional fields are your friend!)

If you’re going to publish demographic statistics, make sure those you’re collecting data from are aware and can opt out Even if you have consent, be aware of sample size and find ways to smooth data or let a respondent know if publishing data that includes gender/trans identity might make their responses obvious (on satisfaction or HR surveys with few trans respondents, for example)

If you need information for a one-time purpose, such as name and gender marker for booking a flight, offer to destroy that data after a certain period of time for everyone or those who request it–and make sure you actually do destroy it

Train staff and volunteers to be aware of privacy concerns: even just sharing a list of legal names, for example, could be a huge violation of privacy Replace othering with universal design At an event, include pronouns on everyone’s name badge



Avoid asking for gender or a title (Mr./Ms./Mrs.) if you don’t absolutely need it



Make it very easy to update data such as name, username, or gender Whenever possible, allow self-updating online Make it clear how to update data, rather than burying the instructions While they aren’t always, usernames can be gendered and thus as important to change as a first name If removing the old data from the system entirely will possibly cause problems in the future, such as not recognizing a duplicate record with an old name and potentially using that name in the future, be transparent about your purpose for keeping the data, offer options, and lock the old data down to as few people as possible



Refuse to work with database or integrated platform vendors who won’t provide the custom fields and update options you need If at all possible, don’t compromise on the data structure and plan you’ve developed because a vendor standardizes fields Instead, spend your money with more flexible vendors



If you work with partner organizations or companies and share data, encourage them to adopt similar policies and practices around this data rather than designing your system to incorporate their more standardized data sets

Have additional questions? Want to share your own thoughts around making data practices more trans and/or queer inclusive? Comment below, Tweet me @queeractivist, or use the hashtag #dataqueer.