Short answer
An embedded HMI prototype should validate more than the screen design. A useful prototype connects UI and interaction logic to the target GUI framework, display, touch, processor, memory and key product interfaces, then runs the important workflow on representative hardware.
Choose the product question the prototype must answer: whether the operator can complete a task, whether the UI fits the platform, or whether a device interface works end to end. That question determines what to implement and measure.
What you provide
- Sketch: a rough screen, reference image or description of the operator's task. Use Sketch → Prototype if the interface is still taking shape.
- Figma: screens, components, assets and interaction examples. The Figma-to-embedded-HMI workflow explains the engineering handoff.
- Requirements: users, key functions, operating environment and mandatory constraints.
- Existing UI: screen captures, current behavior and the problems to solve.
- Existing prototype: hardware, source availability, software versions and known integration or performance issues.
Also share the target display, important I/O or data sources, and any processor, module or OS that must stay. Unknowns can be recorded as assumptions rather than silently treated as requirements.
What gets defined
| Area | Useful output |
|---|---|
| Screens | A screen inventory and the first user journey to build. |
| Interaction | Touch actions, navigation, feedback and exception paths. |
| State | Operating states, transition conditions, loading behavior and failures. |
| Architecture | GUI framework, OS, application boundaries and product interfaces. |
| Hardware assumptions | Display, touch, processor, memory, storage and any unverified drivers. |
Use the MCU/MPU/SoC guide to select a starting architecture. Define acceptance criteria for the important workflow before writing the UI.
Implementation
Implement the UI and interaction
Build screens, reusable controls, state transitions and data bindings in LVGL or Qt/QML. An LVGL prototype starts with a working display port, input handling and a representative workflow. Qt Quick/QML needs a supported runtime and graphics path; Qt for MCUs requires its own supported target and feature review.
Bring up the BSP, display and touch
Confirm boot, display timings, orientation, pixel format and touch coordinates. Reuse a supported evaluation board where it reduces uncertainty, while documenting how it differs from the intended product.
Connect important I/O and data
Integrate the interfaces needed to answer the prototype question: for example, a sensor feed, control link or network service. Identify simulated data explicitly so reviewers can distinguish UI behavior from completed device integration.
Make the result reproducible
Record the board, display, BSP, GUI version, build instructions and configuration. Keep a list of assumptions, known limits and open issues alongside the prototype.
The hardware overview, module options and SDK and developer resources help identify a platform to evaluate.
Validation on working hardware
- Important workflows: test normal operation, invalid inputs, connection loss and recovery.
- Frame rate: measure the demanding screens and transitions against the project's acceptance target.
- Touch response: check feedback latency, touch accuracy and gesture behavior on the actual panel.
- Memory: measure peak usage with representative assets, data and animation; include driver and system overhead.
- Boot: measure time to useful interaction and the behavior of unavailable dependencies.
- Working hardware: record the processor, display, OS and interface configuration used for each result.
There is no universal RAM requirement or frame-rate target for an HMI. Resolution, color depth, buffering, asset caching and the application workload affect the budget. Use the LVGL Memory Estimator for an initial estimate, then measure the implementation. LVGL's display-port documentation describes its buffering choices.
From prototype to production
A prototype proves selected behavior and reduces uncertainty. Production planning adds the requirements needed for repeatable manufacture and long-term support:
- BOM: review the complete product cost, including compute, memory, display, touch and supporting components.
- Lifecycle: check component availability, software maintenance, updates and product variants.
- Supply: identify procurement constraints, second-source needs and qualification work.
- Board decision: evaluate keeping a SoM, using an optimized module or moving to a custom board based on volume, cost, integration and engineering risk.
- Qualification: plan the product-specific environmental, reliability and compliance work beyond the prototype.
Continue with the prototype-to-production path and the chip-to-production guide.
Real evidence to inspect
The OpenHMI hardware demo collection includes embedded UI examples across mobility, monitoring and appliances. OrbitMenu by János Márta demonstrates a reusable LVGL 9 touch-selection control on ArtInChip D133CBS hardware. His AI Robot Gesture System demonstrates state transitions and draggable-node interaction.
Use these examples to discuss the interaction you want to validate. Inspect each detail page for its demonstrated scope; your project's performance and integration results must be measured on its own representative setup.
Who can help build an embedded HMI prototype?
For a small OEM, look for an engineering partner who can connect UI implementation, BSP, display and touch bring-up, product I/O and hardware validation. Ask for a scoped workflow, documented assumptions, source and build handoff expectations, and measurable acceptance criteria.
OpenHMI Network accepts sketches, Figma designs, requirements and existing prototypes as project inputs. OpenHMI Station supports a prototype path from sketches or uncomplicated Figma logic to ArtInChip hardware. Complex behavior and product integration are defined and engineered as part of the project scope. Share what you have through the Engineering Path to frame that scope.
Frequently asked questions
What is an embedded HMI prototype?
It is a runnable implementation of selected user interactions on representative embedded hardware, with enough display, touch, software and device integration to test a specific product question.
Do I need final hardware first?
No. A supported evaluation board or module can validate the main workflow. Document differences from the intended product and identify what must be tested again on the final hardware.
Can I start from a sketch?
Yes. Begin with the users, important task, screen ideas and product constraints. The sketch-first path focuses on turning that rough input into a usable screen and interaction definition.
How long does it take, and what information is normally required?
Timing depends on screen count, interaction complexity, hardware readiness, BSP support and the interfaces to integrate. Provide the target workflow, design or requirement notes, available hardware and acceptance criteria before estimating effort. An existing UI alone does not establish a reliable schedule.
Should I use LVGL or Qt?
Choose from the UI workload, OS, platform support, memory and team workflow. LVGL can suit focused resource-conscious products; full Qt Quick/QML is often evaluated for richer application platforms. Qt Quick Ultralite differs from full Qt Quick, so review the actual target framework. See the GUI workflow guide.
What is the difference between a prototype and a production HMI?
A prototype validates defined behaviors and assumptions. A production HMI also needs a controlled BOM, repeatable manufacturing and test processes, lifecycle planning, maintainable software and product-specific qualification.