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
- [start year] to 2026
- Team
- [me as lead designer, one UI designer, N engineers, a product owner and a UX writer. Confirm roles and count]
- Platform
- Figma plugin, browser-based Live Preview, QML output for Qt
- Outcome
- [one line. Example: public V1.0 in 2026, 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. [Confirm the wording of the consequence. Draft: that is why the preview of the generated code opens in the browser and not inside Figma.]
The third is QML itself. It has rules that designers don't know about and shouldn't need to study. [One or two examples from the public documentation, for example layer naming rules or effects that QML can't render natively.]
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. 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
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.
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 [so other teams could use it too. Keep this clause only if other teams did use those components]. 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, confirm] beta rounds before V1.0 launched in [April 2026, confirm the exact date]. Today it has [read the live number] users on Figma Community. 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