We’re all Naïve


When we’re designing an application, it’s good to consider the global needs of our users.  There are often egregious cases where an app depends on something very specific, like a US code page, that isn’t very portable to other cultures.  However, the more insidious cases are where the developers think that they’ve considered the global needs of their users but are missing the details.

We’ve all heard the anecdotal stories about products using the wrong names, colors, or pictures for their products and logos, but some of our missteps are more insidious.  We can make mistakes because we don’t know that other cultures do things differently, indeed, perhaps it doesn’t even occur to us.

Developers can be surprised to find out that different calendars are used in different countries.  Or maybe they’ve made it past that step and presume that the culture would prefer their own country’s calendar without realizing that maybe Gregorian is more common in that locale.

Or, it could be more subtle.  Maybe we’ve learned that some countries don’t use the / in their dates, but rather use a . or a -.  So, it would follow that maybe for a time like 1:48:12 PM some culture may prefer a separator other than the : colon.  Perhaps that other culture uses a period?  But would that code be ready for a format like 13:48.12 as some cultures do?  Or, particularly for us Americans, we could realize that not everyone uses an AM/PM and instead they use a 24 hour clock.  So maybe I could give them a choice to use 24 hours or 12 hour AM/PM type clocks?  What does my UX (User experience) look like when they’ve chosen the 12 hour clock for a language that has no concept of AM/PM?  Or a locale that has terms like “afternoon”, “evening” instead of a simple AM/PM.

Maybe rather than saying we’re naïve, it may be better to say that we all have unconscious biases.  Many of us have heard their HR folks talk about unconscious bias when talking about diversity, but this shows up a lot in globalization as well.  We all have biases based on our own culture.  We consciously “know” that other cultures are different, but sometimes we forget, or we don’t consider it in some new context.  Or we consciously know about some aspects and unconsciously don’t realize the depth of the situation.

People can also get tripped up on this bias in unexpected ways.  I tend to think that English speakers, and probably American developers in particular, are at a little bit of a disadvantage since so many parts of computing systems favor English speakers.  Even when we realize there’s something out there besides ASCII, it can be tough to realize the complexities of the other cultures.

Ironically, I’ve also seen developers from other cultures see that an API set favors English and then miss their own biases.  It tends to be obvious when one’s own culture is in a different language than the APIs that you use.  But just because you’ve managed to get your application to behave well in your own language as well as English, does not mean that it works well for other cultures as well.

What we do next is sort of a catch-22.  Recognizing that we may not be seeing the whole picture is the biggest step, but if we knew what we were missing then it wouldn’t be an unconscious bias.


Comments (3)

  1. Gwyneth Marshall says:

    Indeed, Shawn. I once worked with an Arabic-speaking developer who forgot to enable BiDi support. When this was pointed out to him he was so embarrassed. We’ve all been there. That’s how standards and teamwork can help.

    1. That’s funny. There are *so* many things that we can easily overlook.

      1. tm says:

        Did you hear the one about the translation app for which the user interface was only available in English?

Skip to main content