Figma to Qt
A Figma plugin that turns designs into QML code for teams building embedded interfaces with Qt.
- Role
- Lead designer, end to end
- Period
- June 2024 to 2026
- Team
- Me as lead designer, one UI designer, a product owner, a UX writer, and seven engineers today, twelve over the life of the project.
- Platform
- Figma plugin, browser-based Live Preview, QML output for Qt
- Outcome
- Shipped V1.0 in 2026 and replaced Qt Bridge as Qt's design-to-code tool for Figma. [N] users on Figma Community.
What it is
Figma to Qt is a Figma plugin that turns designs into QML code for teams building embedded interfaces with Qt. I have been the lead designer since day zero, from the MVP through the betas to the V1.0 public launch in [April 2026, confirm the exact date] and the releases that followed. I covered research, UX, plugin UI, the playground file, documentation and training.
The problem
In embedded HMI teams, the designer works in Figma and the developer works in QML. Between the two there is a lot of manual work. The developer rebuilds every screen by hand from a static design, and small differences pile up. In regulated industries like medical and industrial, those differences matter, because what ships has to match what was approved.
[One thing I saw happen between a designer and a developer during research. Anonymised, no company names.]
The constraints
Three things shaped almost every design decision.
The first is space. A Figma plugin lives in a small panel next to the canvas, so every screen had to work in a narrow column.
The second is the Figma sandbox. A plugin can only do what Figma allows, which is why the live preview runs in the browser instead of inside the plugin panel.
The third is QML itself. It has rules that designers don't know about and shouldn't need to study. Shapes and effects are always rendered as images. Swapping an instance inside a component is not supported. Neither of those is obvious while you are designing.
Three design decisions
Before designing anything, I ran a benchmark of the Figma to code plugins on the market. Most of them don't target QML, but the problem is the same. I mapped everything in Miro: which features each one supported, what worked well, and where they broke. Two of the biggest pieces of the plugin came out of that study, the Issues panel and Live Preview. [One concrete finding from the benchmark.]
01Tell designers what will break, before they exportThe plugin already knows what will fail, so it should say so before the developer finds out.
before
Qt's previous tool, Qt Bridge, had nothing like this. A designer exported, and the problems showed up later on the developer's side. In my first rounds of testing with the MVP, poor error communication was one of the main pain points. People didn't know why something failed or what to do next.
why
The plugin can detect most of these problems, so the designer shouldn't have to learn QML to avoid them. The other option was to document the rules and hope people read them. My research kept showing that people skip documentation.
after
I designed the Issues panel as one of the first features of the plugin. It groups problems into Errors, Alerts and Info, with search and filters, and it points to the layer that needs fixing. Most issues can be fixed from the panel itself, one at a time or in bulk. After launch I learned that the panel alone wasn't enough. People tested with their own files and never opened the tab, so issues went unnoticed. That led to a second round of work on how to bring issues to the user.
02Put the learning material inside Figma, and let people break thingsPeople skip documentation, so the file they practise on has to be the lesson.
before
The first playground file was very raw, a sample design with little explanation. People skipped it, tried the plugin on their own files, hit errors and got confused. Release notes didn't help because almost nobody read them.
why
In my benchmark, the best example I found was a sample project that lived inside Figma instead of on a documentation page. The designer is already in Figma, so the lesson should be there too. With each beta we saw the same mistakes repeat, and I realised the file could teach those directly.
after
Across Beta 2 and Beta 3 we rebuilt the playground as a learning file. It has examples of what not to do and a few flaws placed on purpose, so the user can trigger an issue, see the warning, fix it and understand the rule. For V1 we rebuilt it again as a medical HMI, an infusion pump, because that is the kind of product our users work on. It is public, and it opens in Figma in one click.
03From automatic sync to manual sync in Live PreviewI argued against this change until the evidence showed up, and then the hard part was the interface, not the decision.
before
Live Preview updated automatically every time the design changed. Early on, a request came in to make it manual. I went back through my testing sessions, found no evidence that users wanted that, and pushed back.
why
Later the evidence did show up. Auto sync was interrupting people in the middle of their work, and there was no good way to pause it. So I changed my position. The harder part was the interface. We had a play and pause control, but that metaphor only works for a continuous stream. With manual sync, the preview is a snapshot that the user asks for.
after
After several rounds with the developers and the PM, sync became the main action in the header and play and pause went away. The user chooses between automatic and manual, and the rest of the product respects that choice. When we added code editing in Live Preview, a user on manual sync gets one warning and then we leave their setup alone.
Working inside a design system
The plugin UI is built on Qt's internal design system. I didn't create that system, I used it. When the plugin needed a component that the system didn't have, I designed it in a branch and then merged it back into the main library. Working this way kept me from inventing patterns that the system already covered.
Results
Figma to Qt had its first public beta in September 2025 and went through three beta rounds before V1.0 launched in [April 2026, confirm the exact date]. It is free on Figma Community and has [read the live number] users. It replaced Qt Bridge for Figma, which is now a legacy plugin supported until October 2030. I ran [N] usability sessions myself across the MVP and the betas, with designers and designer-developers, and co-led [N] one-hour discovery interviews with HMI teams.
What I would do differently
I would test with people's own files much earlier. For a long time I tested with files we had prepared, and those hide the real problems. The finding that issues went unnoticed only came when people brought their own designs.
I would make the playground a learning file from the first beta. We treated it as a demo for too long, and we paid for that in repeated support questions.
08 · TRY IT