Design-stage localization: the top challenges for localization teams (Part 2)

In Part 1, we covered why design-stage localization is a game-changing solution for agile, multilingual product development. If you read it, you’ve likely thought about what it would take to create a unified localization workflow based around Lokalise, your design tool, and localization team. 

You might be asking “should I use machine translation to get an idea of what a localized prototype will look like?”… “can our developers remain in control of key naming conventions?”… “will this add to our designers’ (already very full) workload?”

Whatever the case, you likely have questions. And we’re here to answer them. For this discussion, let’s start by laying out the top design-stage challenges.

The top design-stage challenges for localization teams

Shifting the way you work and getting stakeholders up to speed

A design-stage process demands something from every department and implementing it successfully requires a shift in mindset and how you work. In the words of the Global Localization Manager at King, Miguel Sepulveda, it requires “approaching the process as a conversation” between your localization team, product, content designers, and developers.

Shifting localization from a one-off activity that happens post-release to a continuous process that happens pre-release impacts your stakeholders – how you collaborate, share information, and function as a team. 

Think about it like this: If your UX writer is the last in the pipeline of the design process before development handoff, it will require some initial coordination to ensure that they start their work earlier in the translation and localization process. The same applies to other team members who have certain dependencies that need to take place before they begin their work.

The challenge is coordinating this change between all the stakeholders. Since design-stage localization is all about effective collaboration before you build, it “urges you to work closely with each other to make sure things are on track,” says Keith Vaz, Interaction Designer at Gojek.

Even if your stakeholders aren’t entirely new to localization, it requires some basic onboarding to educate and ramp up your team. For example, designers may not be familiar with some newer terms like ‘keys.’ They may require some training on how to link keys to the text elements in the design—and it will likely take some initial effort to get them up to speed. Ensuring that the team understands how translation keys function within the design is crucial for smooth collaboration and accurate localization across all platforms.

Breaking silos between tools, processes, and teams

Aside from inconsistent systems and processes, many of the problems that arise in localization programs are due to the fact that designers, developers, content teams, and localization teams work in silos.

When it comes to localization, there are four things that should be shared and integrated in some form. They are:

1. Lokalise
2. Design tools
3. The wireframes of the entire UI being localized
4. Your localization team

It’s simple: All of the above have shared processes that work in tandem to create a unified, continuous localization process that starts at the design stage. In an ideal world, your prototypes will live in a design tool with existing APIs or connectors to your TMS. You will also need defined collaboration rules to help you function better as a team. 

Centralizing tools and processes

Centralizing tools and changing processes is hard in the short term and your team might not want to change. 

Some larger companies have designers, developers, and other stakeholders that work in different ways. For example, one multinational e-commerce company present in 17 markets has several different design teams which all have their own individual processes. 

In fact, it’s fairly common for companies to have multiple systems and processes for managing content and prototyping product flows, especially in larger organizations. Aside from being an obstacle to effective team collaboration, multiple tools and inconsistent systems will create scalability issues further down the road. 

Ideally, you will have a TMS that is connected to the design tool (e.g., Figma) you use company-wide. Often, companies use their TMS as the single source of truth for content in multiple languages, along with the English equivalent. However, some companies use their design tool as a single source of truth. 

Bottom line: You need tools and processes that are truly central (and integrated) company-wide to get a design-stage localization process working like a well-oiled machine. Plus, ensure your TMS has integrations with your existing tech stack. 

Conflicting key naming conventions

In some companies, engineers are the ones who remain in control of key naming conventions. They may already have the bulk of their core product localized and a specific key naming pattern they would like to continue using. 

The truth is, there is no single best practice here. But the good news is that a design-stage process accommodates flexible ways of working that suit various team structures, workflows, and tech stacks.

You may decide not to automate key names completely or create keys at the design stage and continue having your developers create keys instead. For example, one company decided to stick with engineers creating keys instead of them coming from Figma first. 

The bottom line is: you need a process to align key naming with design systems and ensure you don’t have conflicting key naming conventions or are not left waiting for engineers to create keys that will be linked to the design.

Note: If you’re using Lokalise, you have various options to continue using your legacy key naming conventions, which we cover below. Also, make sure to download our complete guide to design-stage localization, where we walk you through exactly how each option works.

Common questions localization teams have about design-stage localization (and the answers)

1. Our stakeholders are resistant to change. How do I prepare for change management?

It’s important to scale things down. Start by putting together a proof of concept and focus on doing a pilot project. Improve what you already have; the small things help you build the foundations on which you’ll pull off the big ones.

2. Our designers are busy. Why should I add this to their workload?

Ask them if they’ve ever had to redesign the UI because of translations that didn’t fit in the design. If the answer is “yes,” you can imagine how this slows down the entire localization process. Then, ask them how they inserted those new translations into the designs. If the answer is “by copy-pasting,” you will quickly learn that they are wasting valuable time.  

Now, ask your developers if they’ve ever had to rework the code to reflect the new design. If the answer is “yes,” it’s likely you’ve been forced to choose between delivering localized products that don’t look great or shipping late.

3. Our developers want to remain in control of key naming conventions. How do we make it easy for anyone to create keys correctly?

We often come across customers who would love to start using our design plugin but face problems with legacy key naming conventions. 



With Lokalise, you have three options:


1. Automatically link text from your designs to legacy key names in Lokalise if the wording matches (or do it manually if the wording doesn’t match).
2. Do not automatically generate key names, meaning you or whoever owns the process can manually input the legacy key names in the plugin.
3. Use the merge functionality. By allowing for per-platform key names, you can add your locale files with legacy key naming conventions, merge them, and push them back into your design.

4. Should I use machine translation or human translation at the design stage? 

If you want to get an idea of what a localized design will look like, use machine translation. It’s instant, virtually free, and gives you a clear idea of what the user experience will look like in other languages.

The most mature design-stage localization programs start by translating the content in parallel to designers building the user interface. Use human translation as soon as the content is finished or almost finished.

Remember: if the content does change, you will be able to easily make amendments as all this is happening pre-release. Plus, you can use a translation memory to offset any additional costs related to translations. 

5. How do I ensure each stakeholder benefits from the design-stage localization process?

To assemble a functional localization team, you need to address the following points:

• Ramp up quickly on a complex product scope
• Understand the key responsibilities, main challenges, and the shift required for each stakeholder
• Avoid working in silos and share context instead
• Ensure your team members stay engaged and motivated

Depending on your product, the market you’re planning to enter, and the complexity of the localization, each process may look different. However, there are several stakeholders that should make up every localization team. 

Let’s look at how each of them could benefit from the design-stage localization process and how they shape the intricacies of this approach.

Who is it for: your team in the design-stage localization process

There are several stakeholders that should make up every localization team. The localization process typically involves four primary groups of stakeholders:

1. Designers and software developers
2. Product, project, and localization managers
3. Copywriters and linguists
4. QA specialists and reviewers

Let’s examine these roles, how they change, and how they impact the design-stage localization process.

Designers

As a designer, you already prototype user experiences in the base language and check to see if text fits within buttons, how layouts change with different devices, and make design decisions based on the best product flows. The only difference in a design-stage localization workflow is that you are prototyping experiences for global customers, simultaneously. 

Here’s what changes:

Software Developers

As a developer working in an agile product development team that relies on CI/CD to some degree, design-stage localization is a natural fit for your development workflow. 

Whether you want to remain in control of the key naming convention or pass on this responsibility to the localization or project manager is a flexible choice you can agree on with your team. The most important thing is that you will no longer be bombarded with Jira tickets related to localization. Here’s what will change:

Product, localization, and project managers

If you’re a product, localization, or project manager, here are some useful questions you should ask yourself about your existing workflow:

• How much time are you spending on task management and reviewing design bugs?
• Are different team members able to work in parallel rather than waiting for each other to complete work?
• How is this sequential approach impacting delivery time?

You want to be focused on product development, improving localization quality, and getting localized products to market faster –  here’s what will change with a design-stage process:

Content Team

The biggest shift for copywriters and linguists is that they can work together with product, designers, and developers before the build. That means you can ensure the overall coherence of the brand and product experience to create delightful, global experiences. 

Quality Assurance Experts and Reviewers

In a design-stage flow, QA is a collaborative process between the entire team. All the stakeholders can see the fully localized wireframes and share their feedback pre-release. The biggest shift is that teams must agree on quality before anything is built. 

Do you want to know more?

Are you interested in implementing a design-stage localization workflow? Want more guidance?

Click the button below to get a print friendly copy of our complete guide to design-stage localization.