Can bias get built into software in ways that actually harm non-English customers? It can, and it’s actually very common. In this article, I’ll break down seven types of cognitive bias that commonly stand in the way of delivering a truly remarkable experience to customers from outside a company’s home market, and especially for customers that speak other languages.
1. Anchoring Bias
This type of bias is when a person relies too heavily on the first information they obtain, using it from that point on as the baseline for comparison. Essentially, any new input that comes after that is used to validate the initial findings.
In software development, anchoring bias toward just one language can happen at the earliest phase: UX research. If all the research is being done in one language, such as English, users from other languages and cultures will have limited ability to overcome that anchoring effect that weighs heavily in tilting development toward just one group of people, those who speak English.
To take it a step further, if research is conducted in one language first, versus in multiple languages at simultaneously, the inputs that come in the original language are often the anchors that set the tone for how a given area of the product comes to life. So, even if research is done in multiple languages, it’s important that it be done in a way that doesn’t privilege one language as the sole anchor.
A frequent example of the anchoring effect in software design is when a product team designs fields such as “First Name” and “Last Name” in a US-centric way, without enabling these to appear in reverse order (common in some languages, such as Japanese), or not allowing for multiple last names (common in Latin America).
2. Availability Bias
This type of bias relates to making decisions using information that is immediately available or at our disposal, and relying on examples that easily come to mind. Product development often entails availability bias toward the language of the people doing the actual building of the product. They “write what they know” into the code, in a sense.
When the people building the software are monolingual, they tend to assume that all of their users want to perform actions in merely one language, just like themselves. An example of this type of monolingual bias would be when a product team creates a text box with, say, 10 characters, because all of the examples they can think of someone typing into that box would be fewer than 10 characters. They might not be thinking of languages like Spanish and German, which tend to have longer words.
3. Bandwagon Bias
When many people hold the same belief, it can turn into “group think” or what is often known as a “herd mentality.” Minority opinions tend to get drowned out by the majority, because the majority view becomes dominant. Many product teams, including international ones, use English as their language of business. This is especially true at global software companies.
An example of bandwagon bias as it applies to product teams is the common belief that you have to build for the majority of current users, versus the majority of your potential users. Not only does this type of “group think” exist within less diverse product teams themselves who speak English only; it also applies to the user base itself. If product teams think in English, design in English, and build with biases rooted in English, they’ll build a great product for English speakers. Those speakers will overwhelm the user community and dominate other sources of input that product teams use to improve their product. Meanwhile, the unique and important needs of speakers of other languages will easily become drowned out by the majority.
4. Confirmation Bias
Confirmation bias entails paying more attention to previously held beliefs while ignoring any evidence that would challenge those beliefs.
An example of this in localization might be when a product team says, “We’ve had great success with our product in other countries without focusing on non-English speakers. Why should we focus on them now?” It’s hard to argue with past financial success metrics, but user experience and customer satisfaction data might show that in fact, the past choice to sidestep non-English speakers has its faults that might outweigh some of the supposedly stellar performance. Indeed, many companies struggle to believe without tangible evidence that their performance would be even better if they did focus more on non-English speakers.
5. Recency Effect
This form of bias stems from the fact that recent events are easier to remember and thus, top of mind when we are making decisions. Recent events weigh more heavily than ones further into our past.
When developing software, it can be tempting to repeat the same processes and do things in a similar way to the past, focusing on English users, instead of opening up to user inputs and ideas from other languages. A common example of recency bias is that executives and many people from around an English-speaking company will routinely speak with customers who speak English. It’s much less convenient to speak with someone who has broken English, let alone to use an interpreter. As a result, those voices don’t get heard as often. The most recent voices are usually ones that speak English.
6. Proximity Bias
Proximity bias relates to the highly human tendency to prefer, and trust, the people we see in person as opposed to those who are distant from us.
Customers who are further away, and in fact, the employees who are further away, suffer from proximity bias. It’s much harder for customers in other countries to have their stories heard, not only due to inability to meet in person with product teams and others at a given company, but time zone is another barrier that plays into, and can exacerbate proximity bias too.
7. Zero-Risk Bias
This type of bias leads people to choose the option that is lower risk and offers certainty of a smaller benefit, as opposed to an option that entails more risk, but ultimately offers greater potential benefit to the individual, team, or company.
Zero-risk bias is extremely common with localization. Many companies, and product teams, don’t like to discuss their users from other markets and how to best optimize for them because they’re afraid of the added complexity. They might even throw out the term “premature optimization” as a way to block a focus on non-English users. However, most companies rely on non-English markets in order to continue on their growth trajectory, so the reward becomes more apparent as time goes on. There is definitely a high reward associated with focusing on non-English markets, eventually, but many product teams are not willing to stomach the risk of diverting their focus from other things that offer more of a guaranteed benefit in the short term.
What Localizers Can Do
This is by no means an inclusive list of all the types of bias that localization teams encounter in the course of doing their work. But, when you stop and think about how many forms of bias exist that prevent product teams from truly building for non-English customers, it might make you wonder if it’s even possible to overcome so many deep-rooted challenges. However, as challenging as it may be, those of us who seek to provide an equitable experience to non-English users must continue to advocate for this important cohort.
The most important thing to do is to realize that bias is everywhere, and most people are entirely unaware that it exists. Remembering this and approaching it from a non-judgmental and helpful perspective is job number one. Otherwise, you’ll face backlash if you try to shame and blame people into paying attention to non-English users. Acknowledge that these types of bias exist, and then ask yourself if you can find ways to leverage them to the benefit of non-English users. Remember, your product teams aren’t ignoring these users out of any ill will. They’re simply human beings, conditioned by their environment and biased by the many factors mentioned above, just as we all are.
Once you have acknowledged these forms of bias and their manifestations at your own company, the second most important thing to do is to find ways to raise the visibility of non-English users. Are there existing channels that already have strong buy-in (so that you can leverage familiarity bias) where data can be viewed through a non-English lens, but currently are not? Are there ways you can increase the frequency with which non-English customer views are included and presented? Are there case studies and recent wins that you can use, to harness recency bias? Can you bring customers on site more, to overcome proximity bias? There are many ways that we can use human nature to our advantage as we seek to advocate for non-English customers.
Localization teams are notorious for facing quite a bit of resistance in their struggles to create equitable experiences for people of different languages. It’s very hard to get non-English users onto the radar of busy product teams, especially in an English-centric, monolingual-biased environment. But, recognizing the types of bias that exist on software development teams (and elsewhere in the business, of course) can help you be more strategic in your approach to helping advocate for a best-in-class global company.
