 This is something you just did a few minutes ago. Quick hand-raising poll. Please raise your hand if you know what the word cisgender or cis means. Transgender or trans? Binary gender? Okay, this is awesome. My name is Jennifer too. I'm a software engineer. In 2014, I was working for a large doctor's office, mostly primary care physicians, the doctor you see about once a year. And I was writing software for the doctors, patients, and everyone in between. One day a co-worker who worked in business operations came to me. Jennifer, I'm changing roles and I'm looking for a point person, perfectly an engineer who can do the technical work to take over one of my personal projects. It turned out that our software wasn't very friendly for our transgender patients. And this was something that patients, doctors, and everyone else had been raising as an issue for a while. This software was perfectly usable, but it was cold and hurtful for our trans patients. And sometimes it would cause cold and hurtful interactions. Would I be that point person and tackle fixing this problem? Of course I would. So here's what the problem looked like. Patients would register as members of the practice through a web form and they were required to select male or female as their gender. And as you know, this can be an unpleasant question to answer if you're not cisgender. It's hard to tell what the question really means. Are we asking what you identify as, what you were assigned at birth as, something else entirely? And if you're non-binary and you don't identify as male or female fully, then it feels like the web form just erased your entire existence. That's only one side of the problem. On the other side, on the doctor's side, doctors, when they're looking at a patient's chart, they couldn't tell that the patient might be transgender. And between the doctors and the patients were all of these support staff. Admins working at the front desk who want to be able to refer to patients by their preferred pronoun. Phlebotomists who are doing lab work and they want to call the patient the preferred name, but they have a first name that they have to give to the lab. Admins and Billing who call the insurance company until a patient's care is covered. All of these support staff wanted to support our trans patients and they'd uploaded this request to the top of their wish list. So hearing about all of this, I realized that the problem was way bigger and involved many more people than I could have imagined. So I started asking for help. I pulled together a few other coworkers to figure out the best thing to do in a single day hackathon. These people came from different roles in the company. Product managers, software support, that original coworker from business operations. And each of them saw how different users used our application in different ways. Before we met up, I did a little bit of pre-meeting research on the problem. There were many great guides on how to ask for gender or sex in web forums. This one's an example. And a very, very short summary of all of these guides is to not collect gender information. Collecting it doesn't directly benefit the user. They all have this one exception clause to that role, though. They all say, don't ask for sex or gender unless you need it for medical, legal, whatever reasons. And this is great to have that permission except there's no guidance around how to collect if you do need it for medical reasons. Existing guides weren't much use to me. So this is what we decided to do as a first pass that we could accomplish in a single day hackathon. First thing we do is change that label gender to sex because it's a slightly more accurate description of what we're looking for. And we're going to add some hover helper text that explains what this whole required field is. And in that hover text, we're gonna point the users down to this more gender information link, which we add. If you click on it, it opens up a free form text field. One thing that we talked about was how to structure this gender data that we would be collecting. And we all had different opinions on it. We argued a lot about it until someone pointed out that we had no idea who our trans patients were or what they actually needed. How could we decide how to structure this gender data if we didn't know what the data could possibly include? The best way to serve our trans patients wasn't necessarily to come up with some gold-plated, perfect solution, but to thoughtfully and humanely gather data so we would have enough information to later build out that gold-plated solution. This idea of changing the problem from how to structure the data to a problem of how to collect data so we could later structure it, that's an example of a concept called MVP. MVP stands for Minimum Viable Product. It's the idea that you should make the smallest change possible so that you can deliver some value no matter how tiny it is. Tiniere might be even better. So if your user needs to get around, don't build fractions of cars that are unusable until the end. Build fields that continually provide greater value, like first you start with a skateboard then you go to bicycle, motorcycle, then you do the car. We started referring to these hackathon project changes as our skateboard changes. The skateboard changes were all relatively straightforward and simple technical changes. I paired with another engineer, we knocked it out and we were done by the end of the single hackathon day. But how did we know what text to put into the hover here? Helper text can leave you feeling either frustrated or it answers your question in a way that lets you breeze through finishing the rest of your web form. That's what the hover text looks like today. Coming up with the right words took longer than making the code changes. It's really long. How did we know this was the right thing to say? If you want to build compassionate software, you need to go listen to your users. You are not your user. Even if you use your software yourself, there are other people out there and they're typical users as well and they're nothing at all like you. Don't forget about them. So for us to learn more about our typical user, we reached out for help. My friend FishNova said is trans and non-binary and they were incredibly generous in connecting me with their trans network. To help those people maintain anonymity, Fish acted as a relay between me and the trans network. Fish relayed drafts of the hover text, questions, answers, clarifications. We learned answers to questions like how does it feel to join a new doctor's office? Why? This wording change we want to do, would that change the way you feel about joining a new doctor's office? Fish's help made it possible for a number of trans people to safely and anonymously share their feelings and experiences and opinions with us. And we learned how different trans people interact with healthcare and with web forms. I still don't know who those people who helped me are. If that was you, thank you. Here's what we learned at End Applied. This is the first sentence in that big block of hover text. We require this field because one of the many ways we use this information is in communicating with your insurance provider. Right away in your message, establish why a binary sex designation is needed and how that data will be used. Telling your user this does two things. First, it establishes empathy. When you're asked to answer questions without an explanation, it feels like you're being asked questions for the sake of being asked questions. It's like you're dealing with some mindless automated system, like one of those phone trees when you call customer support. Press one because we hate you. But if you say why you need this information, you demonstrate that you recognize the question is inherently frustrating and difficult to answer. And that acknowledgement changes the web form from mindless and caring machine to something that might have empathy. The other thing this message does is it empowers the user. Knowing how information will be used about them can restore some sense of agency in an otherwise powerless situation. And it can turn that into a feeling of collaboration instead. Give your users that feeling of collaboration and agency. That's the feeling that we want them to walk into the doctor's office with. And our doctors are counting on us to start that relationship right. And so tell your user how information will be used and who it will likely be shared with. And whatever phrasing you use, run it past your legal department. Don't promise something your company can't provide. Second line in the hover text says, please make sure the sex you provide here is the same as what your insurance provider has on file, usually the same as what your HR has on file. Ask for what you need. Give your patient both enough context and enough information to act appropriately. What are we asking for in this required sex field? We're not asking for sex. We're not asking for sex assignment birth. We're asking for insurance sex. It's totally different, right? The patient has likely been dealing with their insurance company for a while and they know what they need to say in order to get the medical coverage that they need. And if they don't know, we should make sure they know which sex designation will be most helpful and how to look it up. Also, notice that we're very careful here to separate the patient from the sex designation they provide. That's really important to distinguish because it helps people feel more comfortable or less uncomfortable. Third sentence. If you would like to tell us more about your gender identity, please click on the more gender information link. That information will not be shared outside our practice. This sentence signals a few things. One, we care about your gender identity. Two, we will keep secret what you entrust to us. And three, we respect your autonomy and you decide what part of your identity to share with us. A patient should be in control of their gender identity. They're not obligated to share their gender unless they want to. If they want to, they now know that the option is available to them and how to take it and they have the power to decide whether to take it and the knowledge of what we will do with that information. In the last sentence, we make an affirmation. Our entire team is committed to making sure every member feels safe, welcome, and respected. One thing that we learned is that some patients feel safer sharing their gender identity with their doctor but not with whoever might be at the front desk. These patients have no idea that it's been the front desk admins who have been the ones who've been advocating the hardest and the loudest and the longest for them. But what the front desk admins did, it doesn't matter. No one should be forced to trust anyone else. The right thing to do is to let the patient know where we stand and give them the choice to decide whether to share their gender or to not to. So that's why the Hovered Texas is this big, long block of text. The point of it is to give our users knowledge and in doing so, give them more agency in their relationship with us, their doctor's office. Don't copy this text blindly. This might not be what your users or your patients need and it might not be the attitude that your coworkers or the rest of your team is committed to. Go out and listen to your users and find out what you should be doing. These small changes went live in April of last year and it was a huge hit. People across the company were talking about how awesome my department was just for making this change. Patients were screenshotting and applying the change in social media. That was really cool to see. So could we do better? To answer that, I teamed up with a designer, David Hull. David taught me a lot about user research that made it possible for me to learn more from talking with users than I could have before. Together, we interviewed several doctors who see transgender patients. The short answer is we found that we had already made the most impactful software changes possible but we wouldn't have known that if we hadn't done the user research. If you find yourself in a similar situation where you need to answer questions about how users feel or what they're doing, go pair with a designer and interview together. User research is a skill and it's way easier to learn from an expert than to independently become an expert yourself. Here's a few things I learned from David. User research is about investigating why users do what they do. What actions are they taking or avoiding? What are they trying to accomplish by doing that? Who are they anyway? Just like in writing software and user research, you want to set some goals before diving in. Think about what you want to learn and ahead of time, figure out how you can learn that without asking leading questions. To do that, you want to give the person you're interviewing lots of space to talk. Try saying things that start like, tell me about or show me how you or how do you feel when? And as you're listening to the answers that come back, listen for problems, not solutions. Someone might say something like, I need to see a patient's preferred pronouns right here on the screen. That's a solution. The unspoken problem is when I don't know the patient's preferred pronoun in this situation, I can cause the patient distress or discomfort. As you interview more and more people, you'll be able to better understand what the problem they all face is. And that perspective will help you design a solution that will solve the problem for all of them. As you talk with more people and you learn more about the problem, it can be really tempting to start to problem solve. Try to resist that temptation. You're interviewing someone. Go back into the moment and focus on what you can learn from them right then. If you find yourself saying things like, I think or what I'm trying to do here is, or if you start noticing that you're pitching solutions to the person you're interviewing, these are all signs that you're trying to problem solve. Do it later. Go back to asking the person you're talking with about their experiences and their feelings and you can go back and unpack your reactions afterwards. When I set off to do user research with my designer, Buddy David, there were a few questions we wanted to answer. I mentioned preferred pronouns earlier. This was something that many of the support staff told us over and over again that they wanted. So doctors probably wanted it too. So we went to talk with some doctors and find out where would it be most useful to show them a patient's preferred pronouns. Answer, nowhere. Doctors, the doctors at this practice would rather take the time to establish a relationship and let patients control when they share information about the gender, not some intake web form. So they wanted to take the control of sharing that information out of the web form's hands and put it back into the patients. No preferred pronouns got that. Sex assigned at birth, medically critical information that you probably need to know. Nope, turns out you get no medical information out of this. It doesn't tell, yeah, hang on, now you're gonna find out why. It turns out that sex assigned at birth doesn't tell you anything like, what does the patient need today? Does the patient need a pap smear or prostate exam or some other kind of screening? Can't really tell. It doesn't tell you anything about a patient's identity. Sex assigned at birth doesn't even tell us what sex to provide an insurance company for billing purposes. It's completely useless. All right, sex assigned at birth, useless, got that. Chromosomal makeup, that will give us the medical information we need, right? Yeah, nope, nope, also useless. Still doesn't tell us what kind of screenings a patient might need, what kind of organs they might today have. And on top of that, it erases the experience of many people. Some people are intersex, so their chromosomes might be something like xxy, xyy, something else entirely. And some people can be xy and have a uterus in other female reproductive organs. So I have more stories like this, catch me during a break if you want to hear more. Where are we today? That binary sex selector in the web form, it's still present and it's still required. There was never the big exciting technical change that we were expecting that would deliver the gold-plated perfect solution. And that's okay. Building new things isn't always the right thing to do. Sometimes small changes are what you really need. Small engineering changes when coupled with thoughtful user research can make a really big difference to your users. Today, that web form, that web form that used to be cold and hurtful, now it has some warmth and caring and humanity. It's making a difference to our trans patients and to everyone who helps care for that patient. User research meant that we delivered the right thing and didn't waste time on a solution that wouldn't bring value. If you want to build compassionate software with compassionate user interfaces, take the time to do your user research. Learn about everyone involved and how they feel. And when it's time to decide what to do, don't be afraid to go dream that smaller change that makes a big impact. I need to give a big thanks to FishNova said, Julia Tuttle and the rest of the anonymous trans network for teaching me about what it's like to be trans and dealing with healthcare. Designer David Hall, all my former coworkers at OneMedical and all of the amazing people who gave me fantastic talk feedback. Thank you for your help. And if you want to learn more about user research, here are a few quick fundamentals or good reads that can introduce you to the field. Thank you, Open Source and Feelings for having me speak here today and thank you all for being here.