Case Study: Preferred name
In the financial world, asking a customer for their legal name in order to sign up or continue with a service is about as standard and default as it comes. But what about people whose legal name doesn’t fit with who they are? To take it a step further, what about folks who experience a form of trauma when they hear their legal names? For transgender and non-binary folk, there is nothing standard or default about the name given to them at birth. To address this, we’ve created space for a Preferred name, an off-the-side-of-our-desks project that gives customers the ability to input another name besides their legal name.
How can we navigate the legal complexities of finance, and create an experience that stops deadnaming our trans and non-binary customers?
For this project, I worked with engineer Jess Harrelson. Jess and I decided the best place to start this project was to give customers the ability to enter their name in-app from the settings page. We knew the long-term goal was to capture this information during the sign-up process, but navigating the stakeholder complexities for such a contested funnel was too big a chunk to bite off for a proof of concept.
For our proof of concept, we added UI to the settings page that would allow people to set their preferred name. Fairly straightforward, we knew we needed a button to launch a flow that would capture the customer’s preferred name. We’d save that name, provide some education around when and why we had to use their legal name, and begin addressing them correctly in the app as well as in emails.
Customer feedback showed us that we had made the wrong choice in using the word ‘preferred’ to describe the name by which a user would like to be addressed. That approach normalized the concept of a legal name and minimized the significance of the names users would enter into this feature. So we updated the copy to refer not to the user’s ‘preferred’ name, but simply to their name. We chose a tone in our copy that was conversational and human, but maintained the respect and authority a finance app needs.
The last problem to solve in the release of this feature was to decide how to display the legal name. We put our trans and non-binary customers first by choosing UI that gave the user an option of viewing their legal name—or not.
A toggle was a natural choice to empower the customer.
trans or non-binary person’s name isn’t preferred; it’s their name. Period.
This project is a quintessential example of what Project Inkblot calls “Targeted Universalism.” Jess wrote a great blog post expanding on this, but essentially it is the idea that if you design your solution around your most adversely impacted persona, all of your users will reap the benefits. Think #blacklivesmatter. The sentiment behind this is also foundational in Microsoft’s Inclusive Design fundamentals.
“Solve for one, extend to many. ”
— Kat Holmes
We were able to apply this principle directly by prioritizing the needs of our trans and non-binary customers. This mission helped us overcome fears that we would confuse cisgendered customers or that our legal team would oppose the feature (in fact, they were quite supportive). This core tenet expressed itself in our copy choices, product development process, and interface element choices. With the internal and external launches, we were delightfully surprised with how excited all of our customers were.
The success of the project propelled the addition of preferred name into our signup flow, making Betterment’s product a little more inclusive.
“By using design to make our customers feel seen, we create deep emotional engagement. When people feel a sense of belonging, they’ll give you repeat business and they’ll tell others.”
— Aaron Walter, Designing for Emotion
These articles are maintained by Betterment Holdings Inc. and they are not associated with Betterment, LLC or MTG, LLC. The content on this article is for informational and educational purposes only. © 2017–2021 Betterment Holdings Inc
Did you miss our previous article…