At Stepstone, translations lived outside the design workflow. Designers worked from static content, and keeping designs in sync with the real string library meant manual coordination across tools. During an internal hackathon, I built a system to change that. It won, and the design organisation adopted it.
Localisation happened after design, not as part of it. Text layers in Figma had no relationship to translation keys. When content changed, both sides needed updating separately, with no single source of truth connecting them.
For a product operating across multiple markets, that gap had real cost. Inconsistent content in designs, slow handoffs, and a localisation team working from outputs rather than alongside the design process.
I approached it as a system design problem. The question wasn't just how to sync content, but how to build something designers would actually use without adding friction to their existing workflow.
The solution connected Figma to Supabase through a plugin that kept things simple on the surface while handling the data structure underneath.
Each text layer in Figma was linked to a translation key. That created a direct relationship between what you see in the design and the string it would become in the product. No more guesswork about which piece of UI maps to which translation entry.
The Supabase schema was deliberately simple: projects, strings (keys), and translations per language. Structured enough to be queryable and scalable across products, without requiring engineering support to maintain.
Designers could push updated content from Figma to the database, or pull translated versions back into their designs. The flow worked both ways and removed the manual handoff that used to sit in the middle.
The plugin gave designers a minimal interface: link a layer to a key, push changes, pull translations. No external tools, no ticket to raise. It all happened inside Figma, which meant it actually got used.
The project won. The build was fast and focused on demonstrating the core concept clearly rather than polishing edge cases. That turned out to be the right call. A working system with a clear value proposition was more persuasive than a polished prototype with gaps.
After the hackathon, the system was picked up by the wider design organisation. It became part of how teams approach content and localisation, shifting from a one-off experiment to something in active use.
That shift is the part worth noting. A lot of hackathon projects demonstrate a concept and get filed away. This one changed the workflow.