A client recently approached me with a completed, polished mobile app design, ready for development. Their final request seemed simple: “We just need to create versions for German, Japanese, and Spanish.” They had already received spreadsheets with translations and budgeted a small amount of time for a designer to manually copy and paste the text into duplicated frames. This assumption—that localization is a simple, final step of content replacement—is a genuinely common and costly misunderstanding that I see all the time.
The Case Study: A “Simple” Translation Task Goes Wrong
The project was a clean, minimalist financial management app. The design system was solid, but it had been built and tested exclusively with English text. The client’s internal design team began the manual process as planned: duplicate the English-language frames for each new language and start replacing the text string by string.
Within hours, the process had devolved into a considerable mess. German words, often much longer than their English counterparts, were breaking layouts, overflowing buttons, and wrapping to multiple lines in unpredictable ways. Japanese text, which lacks spaces between words, created awkward line breaks and required different visual densities. The team was spending more time fixing broken layouts than actually populating content, and any small change to the source English design now had to be manually replicated and fixed across three other language versions. It was genuinely unscalable.
Step 1: Halting the Manual Work and Introducing a Single Source of Truth
I had them stop all manual work immediately. The core problem was that their content lived inside their design files. This tight coupling meant that design and content could not be managed independently.
The solution was to introduce a localization plugin. While several options exist, they all share a core principle: they replace hard-coded text strings in your design with “keys.” Instead of a button label reading “Submit,” it now references a key like button_submit.
We used a plugin to connect their Figma file to a Google Sheet, which became their single source of truth. The sheet had columns: key, en, de, ja, es. This simple change was transformative: the translators’ work in the spreadsheet could now be programmatically synced to the design, and the designers could focus purely on layout and components.
Step 2: Stress-Testing Components with Real Translated Content
With the plugin connecting their designs to the translation spreadsheet, the real work could begin. We could now, with a single click, switch the entire UI between English, German, and Spanish.
This immediately exposed every single fragile component in their design system. A button that looked perfect in English (Save) immediately broke when populated with the German equivalent (Speichern).
This is where Figma’s Auto Layout became critical. We went through their component library, methodically rebuilding elements to be genuinely responsive to their content.
- Buttons and Tags: We ensured they used Auto Layout to grow horizontally with the text, with appropriate padding defined.
- Text Blocks: We set text containers to “Hug contents” or “Fill container” where appropriate, allowing them to resize vertically or horizontally within their parent frames.
- Cards and List Items: We nested Auto Layout frames to manage complex components, ensuring that a longer title in one language would correctly push down the description text below it without breaking the card’s overall structure.
The plugin made this process incredibly efficient. We could instantly toggle between the shortest language (English) and the longest (German) to stress-test every component’s resilience.
Step 3: From Reactive Fixes to a Proactive Localization System
Once the components were robust, the client’s team could see the full power of this workflow. A change made by a translator in the Spanish column of the Google Sheet could be pulled into Figma, instantly populating the design with the latest copy. No more copy-pasting.
The benefits were considerable:
- Parallel Workflows: Designers could refine the UI while translators finalized copy, working simultaneously instead of sequentially.
- Error Reduction: Eliminating manual data entry drastically reduced the risk of pasting the wrong translation in the right place, or vice-versa.
- Scalability: When the client later decided to add French, the process was no longer a design crisis. They simply added an
frcolumn to their sheet and the design was ready to be populated in minutes. The design work was already done.
Key Lessons from This Localization Turnaround
This client’s experience provides a clear blueprint for any team approaching UI localization. Treating localization as a final, trivial step is a recipe for budget overruns and delays.
1. Decouple Content from Design: Use a key-based localization plugin to manage your text strings from a single source of truth (like a spreadsheet or a dedicated localization platform). Your design file should be a template, not a content database.
2. Build for the Worst-Case Scenario: Design and build your components with Auto Layout from the start. Stress-test them with longer languages like German, not just your default source language. A component that works with German text will almost certainly work with English or Spanish.
3. Integrate Localization Early: Don’t wait until the design is “finished.” Introduce localization plugins and workflows early in the process to catch layout issues when they are still cheap and easy to fix.
The client’s team transformed their process from a reactive, manual, and error-prone mess into a systematic, scalable, and professional workflow. They not only launched their multi-language app successfully but are now positioned to expand into new markets with a genuinely trivial amount of design effort.
What is the biggest bottleneck in your current design-to-translation handoff process? Describe the specific friction point, and I can suggest which type of tool or workflow change might help.