A person’s name is not just a convenient way to refer to them. It’s part of the core of their identity. So when a person changes their name — for a marriage, a gender transition, or any other reason — our systems need to be responsive. You may even be aware of this, but you’d be surprised how many places names pop up in your systems.
I started a name change myself not that long ago. It’s been an enlightening (and sometimes disheartening) experience, working my way through the sheer number of online services that I need to interact with. It’s almost entirely universal that you can change your “profile” name. That’s good. It’s also really the bare minimum for any service that collects your name.
Any Service that Collects Your Name?
Before you get into the issue of taking someone’s name (or even their email address!) consider that you may not need it. How do you plan to use that information?
If you’re looking at having a friendly greeting for someone in your app, simply ask them, “What would you like us to call you?” Consider letting them opt out; you could just give them a friendly “Hello!” instead.
If you do ask for anything, be sure you let people change it, and let them know how they can.
Gendered Assumptions
Similarly, if your design calls for pronoun use, you might be thinking of asking for a user’s gender. You can go two ways with this:
- The simplest way is to consider just using the neutral they, them, and theirs.
- You can also ask for someone’s pronouns. (Avoid the word “preferred.” While people may prefer that you use their correct pronouns, it is not optional.)
Whatever you do, think hard about why you might want to ask for someone’s gender. Whatever you do, don’t tie it to a pronoun. And don’t lock them into whatever they choose on day one.
Legally Speaking
Understand that some people may have both a name and a legal name. Whatever names(s) you request, make it very clear what you’re going to do with the information. For example:
- “We would like to know what to call you. Only you will see this name; we’re not going to share it with anyone else. You can change it later.”
- “We would like to know the name you use for others. Your public profile will show this name. You can change it later.”
- “To process payments, we need the name you use with financial services. This is between you, us, and your bank. You can change it later if your financial situation changes.”
- “We’re unfortunately legally required to collect your legal name. We will only share this with entities that have the legal right to know. We won’t show this to you except in these settings, and we’ll have a process for you to change this if your legal name changes in the future.”
If you do need a legal name because what your app does won’t work without it, you should ask for a separate name as well, and clearly label the legal name as such.
If you are asking for a legal name today and decide you’re going to introduce friendly greetings with the name someone is known by later, don’t assume someone’s legal name is what they want you to call them.
And, again, all of these names are subject to change at any time. Don’t lock anyone in.
Reaching the Real You
When I was a much younger developer, starting to think about identifying users — and the glut of distinct usernames that I was starting to create over a much smaller, but still worrying, number of cloud services — I thought to myself, “Why can’t we just use email addresses to identify people?”
Fast-forward to today, and many people do use their email address as a stable identifier. Quite a few services take this idea to its logical conclusion, making users’ email addresses their literal usernames.
Using an email address as a username is fine, but locking people into that same email address is not. Make sure that, when you choose a stable identifier in your system, it’s not something that locks a user’s experience down. A UUID is a great choice, and it’s flexible for your system’s future.
Thankfully, most systems recognize that people change email addresses. People jump service providers all the time. People tend to choose email addresses that are tied to their identities, and peoples’ identities are always evolving.
Again: don’t lock people in.
The Perils of Usernames
While email addresses can be useful logins, they’re not things you should be sharing with others. Many systems use distinct usernames because of this. (Many also use usernames just by default.)
But people tend to choose usernames that are very much tied to their own identity — whether it’s something people call them, a handle they’re using far and wide across the Internet, or even just something they’re really excited about at this stage of their life.
Usernames are where a lot of services, frankly, fall down on the job. And I understand why; for many years, I thought it might only be mildly embarrassing for someone to be stuck with an old username.
But the stakes are much higher than that, especially for usernames that have one’s name as a key component. If you’re undergoing a gender transition, and an important service you use reminds you of your deadname (a name you used to use, but is uncomfortable to hear post-transition) for all time, are you going to enjoy using that site?
Unfortunately, changeable usernames, particularly when they’re widely displayed on a service to many people, can be expensive to implement. Nevertheless, it’s worth doing because not doing so increases the personal discomfort people will have using your service.
One more time: don’t lock people in.
Designing for Inclusion
The current state of the user-identification world suggests to me — especially when compared to how it was decades ago — that we have some diverse voices, as well as people that have listened to diverse voices, designing these systems.
But we still have some way to go. I’m still personally stuck with a few services unnecessarily (and unpleasantly) clinging to a name I no longer use. This is another place where listening to, asking, and including diverse voices on your team will make your service better for everyone.
When I started writing this post, I realized that while I understood a few reasons why people might change their names, my own knowledge is strongest in my own personal experience and the experience of many of the people I’m close to.
I reached out a few places to see what it was I might not know about this topic, and I’ve already learned a few interesting things about the ways cultures other than my own handle names. (For more on the topic of names, read “Falsehoods Programmers Believe About Names” and the W3C’s “Personal Names Around the World.”)
I encourage everyone responsible for designing and implementing systems to do the same. Inclusiveness isn’t about ticking off diversity checkmarks. It’s about listening, understanding, and working to make everyone’s experience better.