7 Embedded HMI Mistakes That Delay Product Launches (and How to Avoid Them)

The screen is often the last thing finished on a machine and the first thing a customer judges. Whether it is an EV instrument cluster, a medical device touchscreen or an industrial control panel, the human-machine interface (HMI) is where months of engineering become something a user can see and touch.

It is also where launches quietly slip. Most delays don't come from one dramatic failure. They come from a handful of early decisions that look harmless at the time. Here are the seven we see most often, and what to do instead.

1. Designing the UI before knowing the hardware

A design that looks smooth on a laptop can stutter on the target board. Animations, gradients, blur effects and large images all cost GPU time and memory, and embedded processors vary widely.

Instead: confirm the processor, GPU, display resolution and memory budget first, then design within them. Build a small performance prototype on the real board in the first weeks, not the last.

2. Treating UX design and engineering as separate phases

When designers hand over static screens and developers rebuild them from scratch, details get lost: spacing, states, transitions, error cases. Every round of "that's not what we designed" costs a sprint.

Instead: have UX designers and HMI engineers work from one shared component library. In Qt/QML, design tokens (colours, fonts, spacing) and reusable components keep the build faithful to the design without manual rework.

3. Ignoring the states nobody draws

Designs usually show the happy path. Real devices spend a surprising amount of time in other states: booting, low battery, lost connection, sensor fault, firmware update, wrong input.

Instead: list every system state up front and design each one. A warning screen that is clear under stress matters more than a beautiful home screen.

4. Slow boot and first frame

Users and regulators notice when a display takes too long to show something useful. For vehicle clusters, critical telltales must appear within tight limits after power-on.

Instead: set a boot-time target early, measure it on every build, and design a lightweight first screen that loads before the full interface.

5. Mixing business logic into the UI layer

When calculations, state machines and device communication live inside UI code, every visual change risks breaking behaviour, and testing becomes slow and manual.

Instead: keep a clean split. The UI layer (QML, for example) handles presentation; the backend (C++ or a service layer) handles logic and data. This makes the interface easier to change and the logic easier to test automatically.

6. Skipping usability tests in real conditions

An interface that works at a desk can fail in sunlight, with gloves on, at an arm's length, or on a vibrating vehicle.

Instead: test early prototypes where the product will actually be used. Check contrast in bright light, touch target sizes for gloved hands, and how quickly a user can find the one action that matters most.

7. Planning for version one only

Products change after launch: new features, new markets, new languages, white-label variants for different customers. An HMI built only for launch day becomes expensive to evolve.

Instead: plan for themes, translations and over-the-air updates from the start. A modular component library lets you ship variants without rebuilding the interface each time.

A simple checklist before you start

• Target hardware and performance budget confirmed
• Every system state listed and designed
• Shared component library between design and engineering
• Boot-time target defined and measured on every build
• UI and logic layers separated
• Field usability tests scheduled
• Theming, localisation and update path planned

How Claysol helps

Claysol is a UI/UX and HMI engineering consultancy. We are Qt/QML specialists, but not limited to Qt: we design and build embedded interfaces for vehicles, medical devices, industrial machines and consumer products, from UX research and visual design through to optimised code on your hardware.

If your HMI project is starting soon, or one is already running late, talk to our team about a design and performance review.