From Figma to Qt: A Comparison Between Manual and Assisted Workflows

We know that one of the biggest challenges for embedded UI/UX designers is to see their design vision through to the final product. That’s why earlier this year, we launched Figma to Qt: a plug-in that helps designers craft, preview, verify, and approve Qt applications without ever leaving Figma.

While this has been our sales pitch since, we also wanted to assess what a design-to-code tool could do to a real project timeline. So, we asked someone to find out.

UXDivers is a product design studio that helps engineering teams build better products through UX/UI design and front-end implementation. Their work spans desktop, mobile, and embedded applications, bringing design and engineering together to simplify complex product experiences.

For their study, they took a real client project: an embedded frost-risk dashboard for The Climate Box (a company that provides microclimatic frost-risk assessment software for the agricultural sector). They built the front-end twice: once entirely by hand in QML; once using the Figma to Qt plugin. Same designs, same target hardware: a Toradex Verdin iMX8M Plus module on a Dahlia carrier board, driving a 10.1-inch capacitive touch display and running Torizon OS.

Then they counted the hours.

In this article, we sit down with Pablo Germano, Co-Founder and Head of Design at UXDivers, to talk about what they have experienced using Figma to Qt in the project, what surprised the design team, and what they would tell another studio thinking about trying this.

Check out the full study by UXDivers

Read Now

Let’s Start With the Obvious Question. What Was the Figma to Qt Study About?

We wanted to answer a question we get asked by clients quite often, and honestly, one we were asking ourselves: Does automated design-to-code tooling save real time on a real embedded project, or does it just move the work somewhere else?

The only honest way to answer that is to do the work twice. So we took a live client project, not a demo, and implemented the front end along two paths. The first was fully manual: every design token, every component, every screen handcrafted in QML from scratch. The second used the Figma to Qt plugin wherever it made sense, with manual work only where the plugin could not support.

The project was for our client, The Climate Box. We selected three screens, chosen because they cover a broad range of UI problems: a main dashboard with an at-a-glance risk overview, a zone detail screen full of charts, gauges, and map visualizations, and a settings screen. With data visualization, navigation, configuration, and status indicators, we feel that’s a reasonable cross-section of what an embedded UI has to do.

So, Does An Automated Design-to-Code Workflow Actually Save Time?

We counted the hours for the two workflows and examined different areas of work, such as front-end screens, complex custom components, backend simulation, and others.

We found that front-end screen and standard components implementation went from 118 hours in the manual workflow to 36 hours in the Figma to Qt workflow. That’s roughly a 70% reduction on that portion of the work, about 3.3 times faster.

The impact on the whole project, including custom components, backend simulation, and everything else, on which the plug-in did not have an effect, was around 20%.

Can You Explain the Difference Between 70% and 20%?

The difference comes from the fact that this particular application is unusually heavy on custom components. The zone map, the risk-by-hour charts, and the gauges: those three things alone accounted for 48% of total project effort, and they had to be built by hand on both paths. The plugin does not generate those and was never meant to.

I want to be clear about that, because it is an important caveat. The plugin’s impact is concentrated in one category: standard screens and standard components. That category accounted for only 28% of this project.

On an application with more conventional layouts, forms, and controls – which, to be honest, is most applications - that 70% front-end saving would apply to a much larger share of the overall work, and the project-wide number would be considerably higher than 20%.

What Were The Main Things You Noted When Using the Plug-in?

The interesting part, for me, is that the plugin changes how you build the Figma file. Not what the design looks like, but how it is constructed underneath.

Four things came up for us.

• Naming: We moved from kebab-case to snake_case throughout, because layer names become QML identifiers and QML does not accept hyphens.

• Text alignment: We had to set an explicit vertical alignment on every single text layer; text inside Auto Layout containers drifted to the top regardless of what the container itself was set to.

• Strokes: Our original design used borders with different weights on each side and varying opacity, but QML’s border property requires a uniform weight and a solid color, so we unified them.

• Shadows: We removed drop shadows from containers because the plugin rasterizes any layer with a shadow, and a rasterized image is not acceptable in a UI that must remain resolution-independent and editable.

None of these was painful, but they are the kind of thing you want to know before you design, not after. A file built without the plugin in mind can be a perfectly good visual artifact and still require real rework before it converts cleanly.

Another small thing we noticed, almost immediately, is that the live preview in Figma to Qt only works when you use Figma in the browser. Our design team lives in the desktop app, so it took as a while to figure that out.
Once we found it, the preview became the thing we used most. It renders a selected element at high fidelity in a separate tab and shows you the generated QML alongside it. Being able to inspect one component, check the output against the design intent, and adjust before exporting anything changed how the designer and the developer worked together.

The feedback loop shrank from “wait for the build” to “look at this now.”

How Did You Decide What to Hand to the Plugin and What to Keep Manual?

For interactive controls, the plugin offers two routes: use its built-in component library, or map your own Figma components to Qt Quick Controls. We tried the built-ins first, but they are structured with fixed frames and manual positioning, and our entire design system is built on Auto Layout. Editing them meant working against their internal structure: recentring a checkbox tick, repositioning a switch thumb, and so on.

Mapping our own components gave us full editorial control and kept the design system coherent. We hit one limitation there: our “select all” checkbox has three states, checked, unchecked, and partially checked, and the mapping only handles two. That one we finished by hand.

For the complex visual components, like maps, charts, and gauges, we let the plugin export them as static image placeholders and swapped in the fully coded components afterward.

There is a better route we have not tried yet, using Advanced Settings to annotate a Figma layer and map it to an arbitrary QML type. That is where we plan to go next. We deliberately did not evaluate it in this study, so I cannot tell you how well it works. I can only say that on paper, it removes the placeholder-swapping step entirely.

Beyond the Number of Hours, What Was the Impact?

Two things I did not expect to care about as much as I do.

The first is fidelity that does not depend on who implements it. A manual implementation can absolutely match the design perfectly, but it is highly dependent on the developer having a strong eye for visual detail. That varies enormously between people and teams. Small misalignments, slightly wrong spacing, the wrong type weight: those things quietly destroy the perceived quality of an embedded UI. Generated output is deterministic. It comes out the same regardless of who runs the export. As a designer, that is a meaningful thing to be able to rely on.

The second is uniformity. Generated QML follows a predictable, regular structure. Hand-written QML accumulates stylistic variation over time: different developers, different months, different habits. On a long project, that difference compounds.

Does Automated Design-to-Device Actually Work? Join the session with UXDivers

Register Now

How Do You See Figma to Qt Helping on Other Projects?

I know that Figma to Qt will work fantastically for applications with a high proportion of conventional UI. Settings screens, forms, cards, navigation, lists. That is where the 70% figure lives, and on most products, that is most of the interface.

Also, I believe it can have a massive impact on larger, more distributed teams. This study was run by a very small, tight-knit team. One designer and one developer who talk constantly and know each other’s working styles. That is close to the best-case scenario for a manual handoff, and the plugin still saved 20%. Where design and development sit in separate silos, or in separate organizations entirely, generated code eliminates an entire class of back-and-forth about spacing, sizing, and color fidelity that would otherwise burn multiple review cycles. I would expect the value to be higher there, not lower.

Did the Generated Code Hold Up on the Actual Hardware?

Yes. We deliberately developed on a desktop for as long as possible, because it ensures faster iteration, shorter builds, and no deploy step in the loop. We treated device deployment as a final validation step rather than a daily activity.

When we deployed using the Torizon VS Code extension and its default Qt 6 template, the only friction was a version gap: the template was on Qt 6.8.2, while we had developed against Qt 6.10.2. The adjustments needed were minor API differences, and funnily enough, they were confined entirely to our hand-written components. The QML code generated by Figma to Qt was unaffected.

On the device, performance was excellent. Navigation, animations, and chart rendering were all smooth, with no perceptible difference from desktop.

Last Question. What Would You Tell a Design Lead Considering Figma to Qt?

Be clear about what it is. The tool can accelerate implementation, but the quality of the experience still depends on understanding users, designing the right workflows, and making sound UI decisions. Designers also play an important role in structuring components and working with developers to decide what can be generated and what needs a custom implementation. That collaboration is central to how we work at UXDivers.

The challenge comes later, when the design evolves and screens need to be regenerated. At that point, the discipline that matters is keeping a clean boundary between generated UI and custom code. The more rigorous the separation, the more freely you can re-run the plugin without fear.

Used with those expectations, it is a real productivity tool, a reliable way to eliminate a large class of repetitive, detail-sensitive work that nobody enjoys doing by hand.

Thank you to Pablo and UXDivers team for sharing your experience. Pablo will go deeper into the Figma to Qt workflow in an upcoming talk in our "Behind Your Build Series". You can register to attend here: Does Automated Design-to-Device Actually Work?

Check out UXDivers' website and stay up to date with their work.