Some thoughts on UX content and design-stage localisation
How bringing translators in early improves user experience
This is Part 1 of a talk first presented at Button in 2022. You can also read Part 2. Decentering English: why we should listen to translators. Both articles build upon some of the ideas outlined in On writing about money and diaspora: some notes about content design in the remittance space (November 2021).
Deep gratitude to my closest collaborators on this topic over the past years — Abdikani Yabarow, Gathoni Homem, Mine Demir, Sam Tuma— who have shaped my thinking and informed my practice.
You know how UX content folks have been vying for a seat at the table for years? Asking — sometimes demanding — to be included on projects early so we can make more of a difference? I think localisers are facing a similar struggle. In many organisations and on many projects, they’re coming in too little too late.
I argue that for localisation to truly make a difference to UX content, translators should be included on projects early. And that means at the design stage.
In Part 2, I’ll develop the idea that for design-stage localisation to achieve its greatest impact, we need to let go of some of our sense of control of language.
But before getting into all that, I’ll explain how I came to this topic.
Writing in the remittance space
The organisation I work with primarily serves people who are economic migrants, refugees, or asylum seekers. These are people with family origins in low-income countries who are living in higher-income countries. Our service helps customers send money to family and friends across the world — often in the countries where they or their parents migrated from but sometimes also across the diasporic communities they participate in.
Remittances — which is what we usually call the money sent by someone in an immigrant diaspora to the country they migrated from — are a big deal across the world. According to the World Bank, in 2022, global remittances hit 626 billion USD. [2] Some countries, like Nepal, Somalia, or El Salvador, rely on these funds to such an extent that remittances make up 20–30% of their GDPs. Globally, remittance amounts far outnumber overseas aid and foreign direct investment combined. And in moments of crises (natural disasters, global pandemics, etc.) migrants send remittances much quicker than foreign governments or NGOs can send foreign aid.
So in 2020, when my colleague Gathoni Homem and I joined the organisation as UX content designers, we set out to think how we might better incorporate the reality of our customers in our content practice.
Our guiding question was this:
how can we write in a way that’s both empowering for our users — celebrating their role as economic supporters of their families — while at the same time acknowledging the global systems of inequality and oppression that lead to economic migration and human displacement in the first place?
After some additional research and internal alignment, we agreed we’d work on some content principles as a first step. We came up with this:
- We write for clarity. Our job is to get users from point A to B with confidence. We respect users and keep our language clear and unambiguous.
- We write for localisation and inclusion. Many of our users read us in translation. Most users who read us in English do not have English as their main language. We stick to plain language and avoid metaphors, figurative language, and linguistic or regional in-jokes.
- We do not equate sending money with care or love. We know from research that many people who have migrated, particularly first generation folks, are often under huge pressure to send money. [3] We have little way of knowing if our users are happily transferring money to a beloved sibling or if they’re frustrated that their aunt cajoled them into sending money to a least-favourite cousin. Or if they’re sending money for a wedding, or a funeral, or a caved-in roof that needs fixing. So we don’t attribute judgements of value to, for instance, a successful transfer message (“How kind!, “You’re awesome!”, “Share the love!”). We don’t add pressure for our users and we never guilt-trip them into sending money they may or may not have.
- We reject any form of saviourism. We’re not in the business of “helping Africa” or “stabilising nations”. Also, our customers are simply our customers; they’re not under some moral obligation to “help” the country they migrated from.
These were a good start and we still refer to them all the time when making design decisions. But they’re only part of the picture. You see, our product was localised in 7 languages. And it quickly became apparent to us that the way we were working with translators fell short of the standards we were setting for ourselves with our content design principles.
Basically, we’d finish writing the English strings, send them off for translation, receive them sevenfold a few days later, and send those off for development. And we’d hardly speak to the translators again until the next time we pinged them on Slack with a(n almost always urgent) translation request. Translators had little time to translate, let alone to consider any of these principles we’d so carefully set out.
So while it was great that we were thinking all these fine thoughts about empowering users while acknowledging systemic oppression, we were still only considering these questions in terms of English-language content. Effectively, we were letting down the majority of users who read us in any of our languages apart from English.
So we began to think about localisation more seriously and how we could better integrate it into the content design work we were doing. We decided to tackle 2 different but related sets of questions:
- How do we do localisation right — or at least better? What are the processes and tools we can use? How can we improve our workflow?
- What does it even mean to us to do localisation right? Whose voices are we centring? How can we begin to challenge some of our own ideas about language and agency?
Design-stage localisation
The industry shift to design-stage localisation is fundamental to the way we started exploring these questions.
In the traditional model, localisation comes at the tail-end of the product development cycle. It’s an afterthought. And even if translation quality itself is supported by strong processes, there’s simply no space nor time in this model for designers and translators to collaborate. Designers have little time to understand or consider localisation needs and, usually, translators have even less time to offer much input beyond simply delivering the words. Even if the translator wants to suggest something, it’s often too late and too costly to pause development and move many steps back.
What design-stage localisation does is bring the work of localisation right to point where design decisions are being made. This is a critical shift.
Moving localisation to the design stage opens up all kinds of possibilities and potential. Ways of working that may have seemed impossible or just impractical before are now much easier to achieve. By bringing in translators earlier, we can include them in things like competitor analyses, user research, content audits, drafting of user stories and scenarios, wireframing, etc.
These are not merely nice-to-haves.
Does any of this sound familiar to you? “Design is done. Just write some copy.” “It’s too late to change the flow. Just fix it with your word magic.”
Like content design, localisation is not magic. Like good content design, good localisation requires a thorough understanding of the user, a strong grasp of constraints, and a few rounds of iteration and testing.
Translators cannot just randomly conjure up really good words any more than content designers can. It’s not a trick. It’s a learned skill. And one that requires time and space to be practised.
So if design-stage localisation was going to potentially allow our team to carve out that time and space, we wanted to know how to best use these. We wanted to build some kind of a basic structure for collaboration between design and localisation.
The goal was to increase the impact that localisation — and content as a whole, in all languages — could have on the product. So we were looking at things like speed, efficiency, and quality. But you know, it also turned out that treating translators as design partners was also just really fun for us all.
Learning about our processes and languages
Evaluating the state of localisation
We needed to figure out what we were actually doing and how we were going about it. This involved talking to folks and looking into numbers.
First, we turned to the people most involved with localisation: the translators. These weren’t particularly structured conversations — just a way to learn about the history of localisation at our own organisation, what the current process looked like, and what worked well or less well.
In startups it’s often the case that localisation efforts begin in a pretty ad-hoc manner: someone who already works there ends up doing translation because they happen to know that language, not because they especially know or like translation. So it was important for us to understand whether translators enjoyed the work, wanted to keep doing it, or even had time for it along with their main work responsibilities.
In that process we discovered a few curious things:
- Some languages were being translated by many hands. We’d ping one translator and they wouldn’t have time or simply not feel comfortable, so they’d hand off to someone else.
- One translator told us they disliked the work and would rather not do it. Another one had the opposite reaction: they loved it and wanted the chance to help us rethink how we were doing localisation. (Bingo! That person, Mine Demir, became key to helping us rethink how we worked.)
Then, we turned to localisation stakeholders: marketing, legal, and tech. What were their pain points and concerns? Finally, we checked our numbers. What languages were most popular with our customers? What corridors or languages were key growth areas for the organisation? We’d focus on languages where we could have the most impact for the user.
Documenting the state of localisation and level of maturity
Armed with our research notes, I wrote out a kind of history for localisation at our org. The goal was to establish a collective understanding of how localisation was happening and how it had evolved.
And with our existing processes handy, it was easy enough to figure out where our practice was on a localisation maturity model. This step was important to us in terms of alignment within the team, but also in having something to point at as we discussed the changes we wanted with our stakeholders. We used Lokalise’s maturity model because it was simple and actionable, but there are other options out there. (As with all maturity models, don’t use it as a roadmap. But it’s a useful framework to reference.)
Identifying priority languages
We realised we couldn’t change everything and all languages all at once, so we’d have to make some tough calls. From the data we’d gathered on user base per language, expected growth, but also the interest level of translators for this kind of work, we decided to divide our 7 localised languages into 3 levels of low, medium, and high priority. We came up with a language priority matrix. In it, we defined what priority level each language had and what resources we were going to offer it.
For one of our high priority languages, we got headcount for a new translator to join us. For another, we lobbied internally so the existing translator (who also had multiple other roles) could have more time to work with us.
While we spent most of our energy on the high priority languages, it turns out it was also helpful to have the lower priority languages laid out. For a few reasons: it made our work more transparent and helped show that not spending time on one language meant we couldn’t do very much to increase quality. (In part because of this level of clarity, we’ve since managed to raise another language to high priority level.)
Experimenting with priority languages
The basic idea was that we wanted to treat our high priority language (P1) translators as much as possible as design partners. This meant bringing them close to the moments in which design decisions were being made.
So we experimented with a mix of things.
Loc docs
One of the problems we identified was that translators didn’t have too much of a process for documenting design decisions. Also, translation decisions were being made too fast, often without any space for experimentation.
Together with translators, we defined some documentation needs that would be common across content and localisation. P1 translators began working in loc docs — basically copy docs by another name. The idea was to create more space for experimentation and slow down decision-making.
By this point, we’d been using a Translation Management System (TMS) for about a year. And these systems are great because they’re so efficient. Usually, a TMS will incorporate some kind of translation memory meaning that translators can speed through text rather quickly. But efficiency is often a false friend. The TMS encourages action — it isn’t really a tool for thinking. And when you’re dealing with a lot of legacy content, the translation memory can trip you up. You can end up writing things a certain way simply because that’s how you (or someone else) wrote them before.
We have a simple template that we duplicate for projects, and we have 3 tabs for our P1 languages. This allows us all to see each others’ work and creates a centralised place to ask questions about content.
Implementing loc docs allowed us to break that automatism and support the translator in coming up with the right content for the particular situation we were dealing with.
Content decision database
Inspired by a brilliant post by Grace Roche, we’d already started building a beefed-up glossary to serve our terminology needs in English. We were really happy with how it helped us surface not only the terms we were using but why we’d chosen one term over another. So we expanded it to our P1 languages.
Why document content decisions? It wasn’t enough for us to know that we wanted the concept of “send money” in Somali to always be “dir lacaag”. It was also important to know why weren’t using “xawallah” or any other term with a similar meaning. This is especially crucial when these decisions are based on customer language or other research.
In Notion, we built localised language databases which we then referenced to our English-language database. The result was a 4-language database that our team edited as we worked on different projects. It’s tagged by flow or function so it’s easily searchable.
Each individual entry has the term we use, related terms we don’t use, reasoning for this, links to any research, and any exceptions. Each entry is also marked with a last-edited date and a status that be be either OK or Revise. Periodically, we’d go over these to-be-revised items and decide how to tackle them.
Localised language guidelines
Along the same lines, we needed to maintain general linguistic consistency. So while we largely follow the same voice and tone guidelines across the product, we started working on language-specific guidelines too. These were crafted together with the community managers for each diaspora and spell out what we wamt to sound like in our priority languages. Translators, supported by content designers, are responsible for maintaining these.
Including translators early and often
But treating translators as design partners must mean more than documentation. One of the bigger challenges (and sources of fun) has been figuring out how to include translators in design work.
Including translators in research
We started regularly including P1 translators in qualitative user research, specifically in user interviews. This is particularly important when we’re dealing with larger projects involving new features and big changes.
In these cases, translators either join the kickoff or are briefed by design on what the goals are. The UX team draws up a plan and check in with the translators to get their feedback. During the interviews, translators might just listen in or, if the interview is in one of their languages, actively participate through interpretation.
There are many advantages to including translators in user interviews:
- User research in more languages. We’re no longer limited to the languages folks on the design team know. This means that we both speak to customers who may not have otherwise spoken to and that we’re able to accommodate customers who would feel more comfortable speaking to us in, for example, Somali or Turkish instead of English.
- Better research insights. Because we’re not forcing customers to adapt to our linguistic limitations, customers feel more at ease on calls. And most people are just more willing to talk when they feel comfortable. While the UX team is still technically ‘running’ the interview, the translators have leeway to ask follow-up questions or clarify any misunderstandings.
- Makes localisation visible. One important outcome of design-stage localisation is visibility of the otherwise pretty invisible function of localisation. Having translators as integral participants in research means that it’s easier to surface their work once research results are presented to the wider organisation.
- Increased translator knowledge. Related to visibility, being in direct contact with customers allows translators to gain confidence in their knowledge of customer needs. Just as content designers, translators who participate in research gain valuable ideas about how users speak and what their fears and doubts are. These are insights translators can directly bring to bear in their translation work.
Including translators in crits
We also began regularly including translators in content and design crits. Ideally, because translators were working alongside us in research, the proposed design direction wouldn’t be entirely new to them. This cut down on a lot of context-setting at this stage and we could move to thinking about the advantages and disadvantages of one design direction or another.
Giving translators Figma access
We also began using Figma to do content design across languages. We were already using a plugin to push source copy from Figma to Lokalise and then pull the localised copy back into Figma. So it was a no-brainer to give translators access to Figma so that they could see their copy in context and fix anything that didn’t look quite right.
This is what we did to set up a new process. In Part 2 I’ll argue why we should take translator feedback on copy seriously and give a few examples of how we tried to do that.
[1] I mention English because, as the global language of the internet, that’s the source and design language for so many of us.
[2] The World Bank (2023) “Remittances Grow 5% in 2022, Despite Global Headwinds” https://www.worldbank.org/en/news/press-release/2022/11/30/remittances-grow-5-percent-2022 Accessed 2023/03/19
[3] Laura Hammond (2011) “Obliged to Give: remittances and the maintenance of transnational networks between Somalis at home and abroad,” Bildhaan: An International Journal of Somali Studies: Vol. 10, Article 11. https://digitalcommons.macalester.edu/bildhaan/vol10/iss1/11 Accessed 2023/03/23
