See all articles

Using Targeted Universalism To Build Inclusive Features

The best products are inclusive at every stage of the design and engineering process. Here's how we turned a request for more inclusion into a feature all Betterment customers can benefit from.

By Jesse Harrelson

Mobile Engineering Manager, Betterment |

Published Nov. 10, 2020

Using Targeted Universalism To Build Inclusive Features Nov 10, 2020 12:00:00 AM The best products are inclusive at every stage of the design and engineering process. Here's how we turned a request for more inclusion into a feature all Betterment customers can benefit from. Earlier this year, a coworker asked me how difficult it would be to add a preferred name option into our product. They showed me how we were getting quite a few requests from trans customers to quit deadnaming them. The simplest questions tend to be the hardest to answer. For me, simple questions bring to mind this interesting concept called The Illusion Of Explanatory Depth, which is when “people feel they understand complex phenomena with far greater precision, coherence, and depth than they really do.” Simple questions tend to shed light on subjects shrouded in this illusion and force you to confront your lack of knowledge. Asking for someone’s name is simple, but full of assumptions. Deadnaming is when, intentionally or not, you refer to a trans person by the name they used before transitioning. For many trans folks like myself, this is the name assigned at birth which means all legal and government issued IDs and documents use this non-affirming name. According to Healthline, because legal name changes are “expensive, inaccessible, and not completely effective at eliminating deadnaming”, institutions like Betterment can and should make changes to support our trans customers. This simple question from our trans customers “Can you quit deadnaming me?” was a sign that our original understanding of our customers' names was not quite right, and we were lacking knowledge around how names are commonly used. Now, our work involved dispelling our previous understanding of what a name is. How to turn simple questions into solutions. At Betterment, we’re required by the government to have a record of a customer’s legal first name, but that shouldn’t prevent us from letting customers share their preferred or chosen first name, and then using that name in the appropriate places. This was a wonderful opportunity to practice targeted universalism: a concept that explains how building features specifically for a marginalized audience not only benefit the people in that marginalized group, but also people outside of it, which increases its broad impact. From a design standpoint, executing a preferred name feature was pretty straightforward—we needed to provide a user with a way to share their preferred name with us, and then start using it. The lead designer for this project, Crys, did a lovely job of incorporating compassionate design into how we show the user which legal name we have on file for them, without confronting that user with their deadname every time they go to change their settings. They accomplished that by hiding the user’s legal name in a dropdown accordion that is toggled closed by default. Crys also built out a delightful flow that shows the user why we require their legal name, that answers a few common questions, and allows them to edit their preferred first name in the future if needed. With a solid plan for gathering user input, we pivoted to the bigger question: Where should we use a customer’s preferred first name? From an engineering standpoint, this question revealed a few hurdles that we needed to clear up. First, I needed to provide a translation of my own understanding of legal first names and preferred first names to our codebase. The first step in this translation was to deprecate our not-very-descriptively named #firstname method and push engineers to start using two new, descriptive methods called #legalfirstname and #commonfirstname (#commonfirstname is essentially a defaulting method that falls back to #legalfirstname if #preferredfirst_name is not present for that user). To do this, I used a tool built by our own Betterment engineer, Nathan, called Uncruft, which not only gave engineers a warning whenever they tried to use the old #first_name method but also created a list of all the places in our code where we were currently using that old method. This was essentially a map for us engineers to be able to reference and go update those old usages in our codebase whenever we wanted. This new map leads us to our second task: addressing those deprecated usages. At first glance the places where we used #firstname in-app seemed minimal—emails, in-app greetings, tax documents. But once we looked under the surface, #firstname was sprinkled nearly everywhere in our codebase. I identified the most visible spots where we address a user and changed them, but for less visible changes I took this new map and delegated cross-squad ownership of each usage. Then, a group of engineers from each squad began tackling each deprecation one by one. In order to help these engineers, we provided guidelines around where it was necessary to use a legal first name, but in general we pushed to use a customer’s preferred first name wherever possible. From a high level view I essentially split this large engineering lift into two different streams of work. There was the feature work stream which involved: Storing the user’s new name information. Building out the user interface. Updating the most visible spots in our application. Modifying our integration with SimonData in order to bulk update our outgoing emails, and Changing how we share a user’s name with our customer service (CX) team through a Zendesk integration, as well as in our internal CX application. Then there was the foundational work stream, which involved mapping out and addressing every single depreciation. Thanks to Uncruft, once I generated that initial map of deprecations the large foundational work stream could then be further split into smaller brooks of work that could be tackled by different squads at different times. Enabling preferred first names moves us towards a more inclusive product. Once this feature went live, it was extremely rewarding to see our targeted universalism approach reveal its benefits. Our trans customers got the solution they needed, which makes this work crucial for that fact alone—but because of that, our cis customers also received a feature that delighted them. Ultimately, we now know that if people are given a tool to personalize their experience within our product, folks of many different backgrounds will use it.

Earlier this year, a coworker asked me how difficult it would be to add a preferred name option into our product. They showed me how we were getting quite a few requests from trans customers to quit deadnaming them.

The simplest questions tend to be the hardest to answer. For me, simple questions bring to mind this interesting concept called The Illusion Of Explanatory Depth, which is when “people feel they understand complex phenomena with far greater precision, coherence, and depth than they really do.” Simple questions tend to shed light on subjects shrouded in this illusion and force you to confront your lack of knowledge.

Asking for someone’s name is simple, but full of assumptions.

Deadnaming is when, intentionally or not, you refer to a trans person by the name they used before transitioning. For many trans folks like myself, this is the name assigned at birth which means all legal and government issued IDs and documents use this non-affirming name.

According to Healthline, because legal name changes are “expensive, inaccessible, and not completely effective at eliminating deadnaming”, institutions like Betterment can and should make changes to support our trans customers.

This simple question from our trans customers “Can you quit deadnaming me?” was a sign that our original understanding of our customers' names was not quite right, and we were lacking knowledge around how names are commonly used.

Now, our work involved dispelling our previous understanding of what a name is.

How to turn simple questions into solutions.

At Betterment, we’re required by the government to have a record of a customer’s legal first name, but that shouldn’t prevent us from letting customers share their preferred or chosen first name, and then using that name in the appropriate places.

This was a wonderful opportunity to practice targeted universalism: a concept that explains how building features specifically for a marginalized audience not only benefit the people in that marginalized group, but also people outside of it, which increases its broad impact.

From a design standpoint, executing a preferred name feature was pretty straightforward—we needed to provide a user with a way to share their preferred name with us, and then start using it. The lead designer for this project, Crys, did a lovely job of incorporating compassionate design into how we show the user which legal name we have on file for them, without confronting that user with their deadname every time they go to change their settings.

They accomplished that by hiding the user’s legal name in a dropdown accordion that is toggled closed by default. Crys also built out a delightful flow that shows the user why we require their legal name, that answers a few common questions, and allows them to edit their preferred first name in the future if needed.

With a solid plan for gathering user input, we pivoted to the bigger question:

Where should we use a customer’s preferred first name?

From an engineering standpoint, this question revealed a few hurdles that we needed to clear up.

First, I needed to provide a translation of my own understanding of legal first names and preferred first names to our codebase. The first step in this translation was to deprecate our not-very-descriptively named #firstname method and push engineers to start using two new, descriptive methods called #legalfirstname and #commonfirstname (#commonfirstname is essentially a defaulting method that falls back to #legalfirstname if #preferredfirst_name is not present for that user).

To do this, I used a tool built by our own Betterment engineer, Nathan, called Uncruft, which not only gave engineers a warning whenever they tried to use the old #first_name method but also created a list of all the places in our code where we were currently using that old method.

This was essentially a map for us engineers to be able to reference and go update those old usages in our codebase whenever we wanted.

This new map leads us to our second task: addressing those deprecated usages. At first glance the places where we used #firstname in-app seemed minimal—emails, in-app greetings, tax documents. But once we looked under the surface, #firstname was sprinkled nearly everywhere in our codebase. I identified the most visible spots where we address a user and changed them, but for less visible changes I took this new map and delegated cross-squad ownership of each usage.

Then, a group of engineers from each squad began tackling each deprecation one by one. In order to help these engineers, we provided guidelines around where it was necessary to use a legal first name, but in general we pushed to use a customer’s preferred first name wherever possible.

From a high level view I essentially split this large engineering lift into two different streams of work. There was the feature work stream which involved:

Storing the user’s new name information.
Building out the user interface.
Updating the most visible spots in our application.
Modifying our integration with SimonData in order to bulk update our outgoing emails, and
Changing how we share a user’s name with our customer service (CX) team through a Zendesk integration, as well as in our internal CX application.

Then there was the foundational work stream, which involved mapping out and addressing every single depreciation. Thanks to Uncruft, once I generated that initial map of deprecations the large foundational work stream could then be further split into smaller brooks of work that could be tackled by different squads at different times.

Enabling preferred first names moves us towards a more inclusive product.

Once this feature went live, it was extremely rewarding to see our targeted universalism approach reveal its benefits. Our trans customers got the solution they needed, which makes this work crucial for that fact alone—but because of that, our cis customers also received a feature that delighted them.

Ultimately, we now know that if people are given a tool to personalize their experience within our product, folks of many different backgrounds will use it.