Practical Tips for Trans-Inclusive Data

graph of genders in the colors of the trans flag with options "male," "female," and "annoyed with your question"

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.

  1. 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
  2. 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
  3. 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!
  4. 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
  5. 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.

About Avory

Avory Faucette is a queer feminist activist, writer, and public speaker. Zie graduated from the University of Iowa with a JD in 2009, focusing on international human rights and gender/sexuality issues in the law. Hir current work focuses on queer identity, policy, and marginalized identities under the queer umbrella. As a genderqueer person, zie comments frequently on non-binary identity, transgender and genderqueer issues, and media coverage of these populations. Zie also speaks at colleges, universities, and events on transgender and queer issues and conducts trainings on related topics.

Posted on January 30, 2016, in trans and tagged , , , , , , . Bookmark the permalink. 2 Comments.

  1. Sutapa Balaji

    hi, your writings have been very useful for me as I struggle with our task of designing a database that gets us what is need and reflects our values. You mention above 2 things that we were planning – let people self identify and also let people identify with multiple communities. One feedback on that I got was that it comes in the way of proper reporting if people choose multiple communities. What is your response to that?

    • That’s a great question. While letting people choose multiple communities can make the reporting more complicated, you can still do reporting if you adjust your method a bit. For example, you might report on “percentage of respondents who identify as female” and “percentage of respondents who identify as transgender.” There could be some overlap between the two, but if you’re interested in one variable at a time, it shouldn’t be a problem. Explanatory captions can be really helpful here, so that the reader knows how you collected the data. If you absolutely need to be able to add identities up to 100% for some reason, you can show a “more than one of these” option.

Leave a comment