Short answer
A Figma screen is a design input, not an embedded application. A practical workflow converts the visual structure into an embedded UI, defines interaction and state, implements it in LVGL or Qt/QML, maps the design to hardware constraints, and validates the result on the target display and processor.
The useful deliverable is a working screen flow with documented hardware assumptions. Start by choosing one important product workflow and defining how it should behave.
The practical workflow
Figma screens
Identify the screens, reusable components, typography, colors and assets. Record the intended display resolution and orientation. Include loading, disabled and error states where they affect the operator.
Interaction and state
Define what a tap, drag or long press does; which data changes a screen; and how the interface handles connection loss or invalid input. Turn screen transitions into an explicit state model with expected feedback.
LVGL or Qt/QML implementation
Map the interface to framework widgets, layouts, events and application data. Supported design import or code-generation tools can accelerate part of the handoff. Application behavior, device integration and unsupported effects still need implementation and review.
Assets and layout adaptation
Prepare fonts, images and icons for the target. Check licensing, glyph coverage, touch target sizes, scaling and orientation. Simplify expensive visual effects where the hardware budget requires it.
Hardware mapping
Connect the UI workload to the processor, RAM, storage, display interface, touch controller and operating system. Check the BSP, graphics support and required product interfaces before committing to a platform. Use the MCU, MPU and SoC architecture guide to frame the choice.
Real hardware validation
Run the important flow on the target display and representative processor. Measure touch response, frame rate, memory use and boot behavior. Record the hardware, software version, workload and acceptance criteria so the result can be repeated.
What transfers, and what needs engineering?
| What transfers from Figma | What still needs engineering | What needs validation |
|---|---|---|
| Screen hierarchy, layout intent and component states | Framework layouts, navigation and state transitions | Resolution, orientation, clipping and readable text |
| Colors, fonts, icons and image assets | Target formats, font coverage, asset loading and caching | RAM, storage, rendering cost and visual fidelity |
| Interaction examples and prototype links | Event handling, data bindings, device I/O and failure behavior | Touch response, important flows and recovery paths |
LVGL or Qt/QML?
LVGL is a useful starting point for focused embedded interfaces with constrained resources, including RTOS-oriented products. It can also run on Linux. Qt Quick/QML is worth evaluating when the product needs a richer application structure and the platform supports its software and graphics requirements. Neither choice can be settled from the appearance of a Figma file alone.
Qt for MCUs uses Qt Quick Ultralite, with a different feature and integration model from full Qt Quick. Check the supported target and required UI features before assuming a QML implementation will transfer unchanged. See Qt's framework comparison and the embedded GUI workflow guide.
What hardware information is required?
- Display: resolution, orientation, interface, brightness needs and required refresh behavior.
- Touch: controller, interface, number of touch points and the operating environment.
- Compute and memory: current processor or candidate class, RAM, storage, graphics capability and boot requirements.
- Software: OS, BSP maturity, GUI framework and version, toolchain and update strategy.
- Product interfaces: required I/O, sensors, control links, networking and data sources.
- Constraints: cost, power, size, lifecycle and any hardware that must remain unchanged.
You can begin before every part is selected. Mark unknowns as assumptions and identify which are mandatory. Budget display buffers and assets early: LVGL's display documentation explains how resolution, color format and rendering strategy affect the buffer design.
Useful handoff checklist
- Share the Figma link with inspectable screens and access to the intended design version.
- Name the first workflow to implement, its entry conditions and its acceptance criteria.
- Include component states, navigation rules, data examples and exception paths.
- Identify fonts and assets, their licenses, and required language coverage.
- Provide display and touch details, available hardware and the preferred software stack.
- Separate fixed requirements from preferences and untested assumptions.
- Agree what will be measured on hardware and what remains outside the prototype scope.
How OpenHMI uses this workflow
OpenHMI treats Figma as one input to a larger embedded engineering workflow. OpenHMI Station currently supports a complete prototype path from sketches or Figma designs with uncomplicated logic to ArtInChip hardware. Complex business logic requires explicit interaction and state definitions, integration work and engineering review.
For an implementation path beyond the visual handoff, follow the embedded HMI prototype workflow. If your starting point is a rough drawing or requirement, use Sketch → Prototype.
Inspect János Márta's OrbitMenu LVGL 9 touch control for press, drag and release behavior, and the AI Robot Gesture System for state-driven interaction. The hardware demo collection provides further examples to discuss when defining a prototype.
Frequently asked questions
Can Figma be converted directly to LVGL?
Supported layouts and assets can be mapped into an LVGL project using an appropriate tool or implementation workflow. A working product still needs event handling, state, data bindings, drivers and validation. Review the generated output against the target LVGL version and hardware before relying on it.
Can the same Figma design target both LVGL and Qt?
Yes, the design can be a shared visual and interaction specification. Each framework needs its own implementation, asset preparation and target validation. Check feature support instead of assuming identical code or effects across frameworks.
Do I need to select the processor before starting the UI?
You can define screens and interactions first, provided you establish a plausible display, OS and memory budget. Before finalizing expensive animation, video or integration requirements, validate them on representative hardware.
What if I only have a sketch?
Start by clarifying users, key functions, screen flow and the first workflow to test. The sketch-to-prototype page explains what information is enough to begin.
Technical references
The Qt designer–developer workflow distinguishes UI design files from application logic and production integration. Use these official framework references alongside the hardware and software versions selected for your project.