ROLE
Designer
TEAM
Product manager, designer
SUMMARY
Our dev, copy, and design teams needed a better way to manage bilingual files in Figma.
I designed an internal plugin to simplify the process - eliminating the need for third-party tools that would complicate our internal dictionary and force the team to work outside of Figma.
FIGMA PLUGIN CONCEPT
A localisation plugin concept to ease cross-team bilingual file management
So what's the problem?
TL;DR
Our design team works across two primary languages - Hebrew and English - while supporting both local and international product development. Designers, copywriters, and developers each require different language versions at various stages, resulting in duplicated Figma files, inconsistent copy, and error-prone manual syncing. Existing localisation tools were either too rigid or didn’t fit our workflow, making it difficult to maintain alignment across teams. An in-context solution (that is, within Figma) was needed to streamline bilingual design and reduce friction in the handoff process.
A frustrating workflow with pain points
The two methods of managing bilingual copy currently in use are:
-
Duplicating screens for each language which means switching back and forth between language versions, which is cumbersome and error-prone.
-
Leaving translation comments directly in the design files. This creates a messy workflow where translations are often missed or overlooked.
KEY INSIGHTS FROM USER INTERVIEWS
Interviews with the designers, copywriters, and developers
There are three types of users involved in the localisation workflow: developers, designers, and copywriters. After sitting down and discussing the current workflow with each member, I was able to pull together these insights:
To summarise the user insights;
From my own personal experience as well as that of the other designers, the copywriters, and the developers, there was one thing clear: managing bilingual content in Figma is messy and inefficient. Everyone is using workarounds - duplicating screens, leaving translations in comments, or jumping between tools - which slows things down and leads to errors. The teams needs a simpler, centralised way to manage copy directly in Figma, without breaking their flow or existing systems.
THE OBJECTIVE & EXECUTION
Objective: centralised bilingual copy management
Eliminate the need for duplicating screens or switching between language versions, allowing designers, copywriters, and developers to work more efficiently in one shared source of truth.
Execution: A Figma plugin which manages bilingual content for dev, copy, and design teams
Eliminate the need for duplicating screens, switching between language versions, or using an external system, allowing designers, copywriters, and developers to work more efficiently in one shared plugin.
PAST ATTEMPTS AT LOCALISATION
Using a third party product required too many resources
Due to us trying out multiple products, I was able to do primary research on what is currently out there in the market. We tested Frontitude, lokalise, and Ditto. All these products required the devs and copywriters to manage the copy outside of Figma in their own platforms.
The furthest we got was with Frontitude, where we attempted to sync our system dictionary, however because our dictionary used a different key system, the developers needed to readjust the keys as well as adding strings.
Below: the new copy naming conventions I created for when we tested Frontitude. As you can see, we would have had to create a whole new (and complicated!) system for naming copy which would have created friction and inconsistency if mistakes were made.
Why did these fail?
-
External copy management: These tools required managing all text in a separate platform, forcing designers, copywriters, and developers to leave Figma to update or review copy - breaking our workflow.
-
Incompatible with our system dictionary: Most tools relied on syncing with a string-based dictionary. Our system, however, uses pre-defined keys in iCount's internal dictionary, and adopting string-based syncing would have required rebuilding or constantly resyncing key structures - something we couldn’t support.
-
Not enough manpower: rewriting keys, adding strings, and renaming all of our system's keys with the new naming conventions simply required too much time and resources that we didn't have.
RESEARCH & TESTING
What we liked during our product testing
While testing out the different products (Frontitude, lokalise, Ditto), we were able to get a sense of what worked well for us in our teams.
This included:
-
Setting a base language for each file
-
An up-to-date activity log with timestamps
-
Status symbols
-
Editing within the plugin
-
Previewing the translation in the screen
Conclusion
After researching the plugins and testing each one, I decided to take the best features out of each one and combine it into one plugin for the team to use.
FEATURES WE LOVED
Base language definition
Activity log
Editing + text statuses within the plugin
Previewing the translation text in-screen
LOW-FI WIREFRAMES
Lowfi wireframes: first steps to understanding layout and functions
These are the initial wireframes I came up with when starting to design the plugin. While not all of the desired functions are there, this served in helping to get a sense of the layout and flow of the plugin.
FIGMA PLUGIN DESIGN SYSTEM
Using the Figma plugin design system
When researching how to create Figma plugins, I came across the Thomas Lowry github for Figma plugins UI. I understood that this was the best practice within this field, and was able to find a community Figma file by Daniel Johnston with all the components.
FINAL DESIGNS
Setting a base language for the file
💡 Functionality enhancement: To avoid repetitive manual setup, the plugin allows users to define a base language for the entire file - ensuring consistency across all text frames from the start.
✅ Design execution: A base language can be set and saved at the file level, so users don’t need to select a language each time they interact with a text frame. Users are able to change the base language for a specific text frame at any time as well.
Managing key names, original texts, and translations
💡 Pain point addressed: Managing key names, editing translations, tracking progress, and assigning responsibility was scattered or done manually.
✅ Design execution: When selecting a text frame, users can set or edit the key name, update both base and translated text, assign statuses (e.g. In Progress, Complete), and delegate to team members - all from one panel.
Viewing the history of each text frame
💡 Pain point addressed: Changes to text and translations were undocumented, making it hard to track who updated what and when.
✅ Design execution: A built-in activity log records all edits per text frame, giving full visibility into changes and helping with collaboration and accountability.
Preview each screen in both languages
💡 Pain point addressed: Previewing designs in both languages required duplicated frames or switching layers - causing confusion, workflow interruptions, and visual misalignment.
✅ Design execution: Users can toggle between base and translated views within the same frame, with text updating live - making it easy to check layout and flow in both languages.
Dev mode sidebar integration
💡 Pain point addressed: Developers had to dig through Figma comments or files to find the correct key, base, and translated copy - wasting time and increasing the risk of errors.
✅ Design execution: In Dev Mode, selecting a text layer reveals a sidebar with the key name, base text, and translation - ready to copy and implement directly from Figma.
DELIVERABLES FOR A DEVELOPER HANDOFF
Deliverables for development handoff
We had originally planned to outsource development of this plugin, so I put together a complete handoff package that included a handover brief, the Figma file (of course!), an interactive prototype, a user flow, and a link to the Figma Plugin Design System created by Daniel Johnston. All of these materials are included below in the deliverables section.
Project brief
This brief included the objective, target audience, key features, as well as the design specifications and the technical requirements of the plugin.
Figma file of final designs
The final plugin designs were documented in a dedicated Figma file, with clear component structure and annotations to support a smooth developer handoff. This ensured the outsourced dev could easily understand functionality and visual details at a glance.
Plugin flow
The plugin flow shows exactly what each function does and the steps the user can take. There are two flows - one for devs, and one for designers and copywriters.
Interactable prototype
In this prototype the viewer is able to test out the plugin and understand its functions a bit better. I wanted to make sure that what I was handing over would be as clear as possible.
CASE STUDY RETROSPECTIVE
Plugin didn't make it to development
Although the plugin was fully designed and ready for development, we were ultimately unable to build it. Finding a skilled freelance Figma plugin developer proved more difficult than expected, and internal development resources were limited - this project was repeatedly deprioritised in favour of client facing higher-urgency features. It's frustrating to see a well-researched, cross-team solution left on the shelf, especially our teams are still juggling a fragmented workflow: managing translations through comments, duplicate Figma files, and a disconnected Google Sheet dictionary. This experience reinforced the value of strong implementation planning early in the process - and the need for design advocacy even after handoff.
Personal growth and insights
Working on this project expanded my design thinking in several ways:
-
Designing for myself as a user: This was the first time I designed something that would be used personally by me - I had deep knowledge of the end user and their pain points, needs, and goals, and I was able to really customise the plugin for mine and my teams' specific needs.
-
Working with a new design system: This project really stretched my versatility - I had never designed within Figma’s plugin system before, so I had to get up to speed fast. Working with unfamiliar components and constraints pushed me to think differently, adapt quickly, and still create something clear and user-friendly. I had to rely on my prior use of other Figma plugins and researching what was out there. It was a great reminder that good design isn’t about sticking to what you know - it’s about being flexible and figuring things out.
-
End-to-end problem ownership: This was really an A-to-Z project, from identifying a workflow problem, researching and testing existing tools, proposing a tailored solution, designing it, and preparing a dev handoff.