Design-stage localization: 3 reasons why it’s the solution for fast-growing, agile companies (Part 1)

Design-stage localization is a powerful way to continuously release fully localized products like mobile apps, web apps, and games. It allows for the creation of designs suitable for multiple languages and bridges the gap between the designers,  developers, and translators working on localization. 

But talk to fast-growing companies that are agile and rely on continuous development to some degree; you’ll quickly realize that most haven’t maintained processes and technologies to integrate design into localization. The problem is that a lack of consistent systems and approaches means design is still treated as an afterthought. 

The traditional way of carrying out localization worked well—until it didn’t. For many contexts today, design-stage localization has emerged as the solution for agile companies that are going global. Admittedly, it requires change and a shift in the way you work. But with the right mindset, tools, and implementation the results can be game changing. 

What is design-stage localization?

For decades, design and localization have been at opposite ends of the product development process. The classic approach goes like this: 

Product teams start with a mockup, then create a UI that is sent to development. The product is first developed in the source language and launched in one market. Finally, the product is translated and launched in new markets. 

In a nutshell, a product is launched in a single market and then translated post-release for new markets, one at a time. 

In contrast, design-stage localization involves starting the localization process alongside product development. The design-stage process goes like this: 

Product teams start with a mockup, finalize the UI in the source language, and then linguists begin translating the UI before the feature goes to development. This means that fully localized prototypes are created ahead of time. 

The most important thing to understand is that localization shifts from post-release (an afterthought) to pre-release (fully embedded in the product development process). 

The easiest way to grasp design-stage localization is a continuous cycle with 8 key steps. Here’s a high-level overview of the workflow:

Let’s take a closer look at the steps involved in the above flow: 

Design-stage localization is all about effective collaboration between your stakeholders before you build. If you’re using Lokalise, you can use the dedicated plugins for Figma, Sketch, or Adobe XD so your designers, developers, and linguists can work with visual context and have overall coherence in the product experience. 

In essence, the full scale of design-stage localization embeds localization at the beginning of your product development workflow to streamline key naming, file handling, and error management. 

An advanced design-stage localization workflow using Figma & Lokalise 

The good news is that design-stage localization isn’t a one-size-fits-all approach. It’s flexible and works fluidly with your existing tech stack and workflow. 

Let’s look at a more advanced workflow that allows product teams to accelerate the design-stage localization process further.

Using Figma and Lokalise, localization teams can design mockups suitable for multiple languages without translations, and development can begin in parallel to translations.

Here’s an overview of how it works: 

Now, let’s take a closer look at what this looks like in practice:

1. The designers/content team create the design with key names on Figma.
2. The keys and base language are pushed to Lokalise.
3. Developers get the keys from a duplicate page on Figma.
4. Linguists work on Lokalise throughout the entire flow.

The flow above allows designers and developers to dovetail their efforts for a localization cycle that follows the pace of development and of each feature release. 

Instead of waiting for translations, development can start with key names reflected in the design as opposed to language values. Plus, teams can test the design using machine translation and set character limits to ensure that the design won’t break. 

Note: In later editions of this guide, we’ll show you real examples of design-stage localization workflows that some of our customers have built along with step-by-step instructions to get started. 

What types of companies and products does it suit best? 

Success stories from our customer base show that fast-growing, agile companies that rely on CI/CD to any degree are natural adopters of design-stage localization. 

Companies that rely on continuous development for products like mobile apps, web apps, and games already have the processes and technologies to fit design-stage localization into their workflows. 

That said, our research also shows that companies that are between levels 1 and 2 of the localization maturity model can easily implement and benefit from design-stage localization. 

In short, tech-savvy companies with strong product teams will find it especially helpful for accelerating localization, centralizing collaboration, and achieving their international expansion goals. 

When is it the right approach?

If your priority is quickly launching an MVP and you only operate in a few other markets that are similar to your core market, a traditional localization workflow will likely be more effective. 

But if you’ve found a product-market fit and want to deliver great UX in multiple markets simultaneously, then design-stage localization is the optimal workflow for your stakeholder and company. 

Why should companies start localizing at the design stage?

When implemented correctly, design-stage localization almost always results in higher team productivity, more collaboration, faster time to market, and lower risks than traditional approaches.

The value of design-stage localization

When Romain Dahan created Withings’ design-stage localization workflow, the most important thing he did was align his stakeholders on the goal of localization; thus providing a great user experience for customers globally. 

In the long run, your most important assets are your customers and team. Bearing that in mind, here’s how design-stage localization helps you collaborate effectively with your team and deliver the best possible product for your customers.

1. Streamline collaboration, align stakeholders, and get early feedback

Efficient, simple collaboration and excellent communication are key to building strong partnerships between localization and the parts of your business that require localization support.

With design-stage localization, you can streamline collaboration between your designers, developers, product team, and content team. Your team can work together before you build, while ensuring everyone is working from the same set of information and is focused on the same priorities. 

In the words of Keith Vaz, Interaction Designer at the super app Gojek:

“UX writers can now begin the work a lot earlier and the workflow has urged us to work closely with each other to get things on track.”

They now have a single source of truth for copy for both designers and copywriters. This means, “no more having to go through several hefty Google Sheets, hunting for one line of copy and then having to manually copy-paste it to the designs.”

Aside from eliminating the endless back and forth between stakeholders, it allows product teams to collect valuable feedback from users before releasing a product in multiple markets:

“Translating our designs to our users’ native languages for user testing sessions is super seamless now,” says Keith Vaz. He adds that, “earlier it would take a few hours for the UX writer or the designer to manually edit all the copy on each screen.”

2. Match localization with the pace of agile development and get to market faster

“We are waiting for translations”… “which is the latest wireframe?”… “Let’s just launch in English!”

Working in localization, you’ve likely heard some variation (or all) of the above. You may have experienced the frustration of localization being perceived as slow, manual, and complicated.

Well, design-stage localization changes that. 

Take this example from Luisana Valero, UX Designer at Elli (VW Group), who says they are now able to “deliver assets about 5 times faster for multi-language asset creation (app screens).” 

At Gojek, Keith Vaz says, “accommodating manual copy-pasting ends up being a job for a day or two.” He adds that with the new workflow, this time should be cut to just an hour or two. 

With faster turnaround times and a process that’s embedded in product development, keeping up with continuous development becomes manageable. Teams working on localization are no longer slow and complicated and can partner with product teams to seamlessly marry localization and development. 

Bearing that in mind, we were especially delighted to hear how Withings managed to create an efficient l10n process involving their product team, designers, developers, and content team. In the words of their product manager, Romain Dahan:

“By migrating to Lokalise, we’ve accelerated the delivery of new localized features by 90%.”

He tells us that Lokalise’s Figma integration served as the key to transforming the localization process at Withings and building a design-stage workflow. 

Yes, you read that right. The Figma integration enabled Withings to eliminate 50% of their product manager’s operational workload. This allowed more time to focus on performance to deliver better experiences to customers in 190 countries and 11 languages. 

3. Improve UI quality, prevent costly design breaks, and reduce errors pre-release

If you’re designing something for multiple regions, you can imagine how re-adapting the product interface can slow down the entire localization process.

It creates friction in designer-developer relations, unnecessary work for project managers and translators, and makes shipping localized products quickly (without errors) nearly impossible.

While designers can easily alter the design, developers have a much bigger job in reworking the code to reflect the new design. Often, this forces teams to choose between delivering localized products that don’t look great or shipping late. 

When you integrate designers into the localization flow early on, teams can quickly and easily check whether the design functions correctly across all target languages. Here’s how:

1. Linguists working with visual context can request design amendments to accommodate the translated text. Alternatively, you can set character limits to easily communicate constraints to linguists/UX writers.
2. Designers can pull the translated text back into the design and perform design QA before the product goes to development.

By translating the entire UI, your linguists can better understand the flow and what you’re trying to build. That means avoiding lots of back-and-forth and excess copy that can break the design.

Did you know? Resolving these bugs in the design stage is 10x more cost effective than making adjustments after release.

Why some companies resist implementing a design-stage localization workflow

Resistance to company change

Here’s the bad news: teams don’t typically want to change without a strong motive that ties in directly with their own goals.

Making decisions that require drastic changes, like building new workflows, isn’t easy. New processes take precious time to learn. There will likely be resistance from stakeholders who are used to doing things a certain way. 

But here’s the thing: there is a better way and continuing to do what you’ve always done has an opportunity cost. The alternative of sticking to the status quo shouldn’t be an option—the cost of not switching or keeping your processes and technologies up to date is too high. 

Fear of new tools/workflows

In most companies, introducing new processes and tooling will create some initial friction and require change management. 

But there’s no need to dive straight into the full scale of design-stage localization. You can start by connecting your design tool with Lokalise to simply push screenshots into your projects and provide linguists with additional context. 

Once you have a proof of concept and your stakeholders aligned, it’ll be much easier to get buy-in and implement change. Plus, having a clear understanding of the onboarding process will help your team know what to expect and what support is available as you ramp up. 

Note: In part deux of this post, we cover the common challenges companies face in implementing a design-stage localization workflow and break down each stakeholder and how their role in the localization process changes.  

The benefits of design-stage localization

We’ve covered the value of design-stage localization above, but here’s a quick recap – you can:

• Streamline collaboration, align stakeholders, and get early feedback
• Match localization with the pace of agile development
• Prevent costly design breaks and resolve errors pre-release
• Improve UI quality
• Launch in multiple markets simultaneously

Now, let’s look at two examples for some quantifiable benefits in some of these areas. 

90% faster feature rollout with design-stage localization at Withings

The context: Withings is a connected health pioneer that is localizing their Health Mate app (currently available in 190 countries and 11 languages). They deliver 3 features per release, and each originally took around 10 hours of manual localization work to create and search for keys, link duplicates, extract keys to create tasks for reviewers, and so on. Instead of focusing on strategy, the team at Withings was struggling to match quality localization with the pace of development. 

The challenge design-stage localization solved – Implementing design-stage localization with Lokalise & Figma helped the team to:

• Seamlessly integrate localization into their product development workflow
• Break silos between departments, so teams can collaborate with overall context and coherence
• Spot localization defects before building as linguists have context for the entire UI
• Speed up the process as developers can start building without waiting for translations
• Create an efficient l10n process involving the content team, designers, and developers. 

The results: The product manager at Withings went from 10 hours to 1 hour of task management spent on localizing a new feature. Plus, there are significantly fewer keys to go through each month, which means more time spent on improving localization quality. The bottom line: Withings gets localized products to market faster with far fewer “local customer complaints about translation quality.” 

Read the full case study. 

Localization related bugs at DBS fell from 30% to 8%

The context: DBS is one of the leading banks in Southeast Asia, serving consumer markets in Singapore, China, Indonesia, India, Taiwan, and Hong Kong. 

The challenge design-stage localization solved: By using the Figma plugin, the l10n workflow has become much smoother and helped the team to:

• Solve issues with text not fitting into the design 
• Reduce endless back-and-forths in email threads 
• Give writers and developers context for what each key is used for in the design
• Remove confusion about which is the latest version for wireframes

The results: “After introducing Lokalise, localization-related bugs fell from 30% to below 8%. It helped improve the efficiency of the localization process and the team and made it a lot easier for DBS to create relevant, localized user experiences for global customers. 

Read the full case study.

Key metrics to measure the success & goals of design-stage localization

There are myriad metrics and key performance indicators used to measure the efficiency of localization efforts. This is where most organizations use KPIs or measurements, such as:

Key metrics: 

• On-time deliveries
• Number of linguistic or technical quality errors
• Project delays or extension requests
• Average turnaround time
• Time to market
• Adherence to budget

Business metrics look at the bigger picture and consider the contributions that localization makes towards overall business goals. Since the goal is never just to localize, what specific business metrics are the best to look at?

The most obvious candidate is ROI. While it consists of hard-to-quantify factors, implementing a design-stage localization flow should impact ROI when factoring in localization costs.

That said, whereas ROI is very important, it doesn’t always come down to that. It might be creating an equitable experience for customers around the globe, delivering delight in the form of native experiences, or building brand awareness. 

The bottom line is: you should align any new strategy with clear goals based on your primary business goals. 

Want to know more?

Here’s what you can do next:

• Take a look at Part 2 of this post, which covers the top design-stage challenges for localization teams
• Click the button below to get our complete guide to design-stage localization