The screen has quietly become part of the product itself. A driver begins forming an opinion about a car as soon as they touch the centre display. Someone choosing between two ovens may compare the control panels as closely as the heating elements. And an experienced excavator operator will usually have a firm view on which machine has the better cab interface. 

Most HMI projects don’t come unstuck at the pixel level, though. They come unstuck much earlier. A framework gets picked before anyone knows the memory budget. Compliance scope gets agreed after the architecture is frozen. A design signed off on a 27-inch studio monitor turns out to be unreadable on a 7-inch panel in direct sunlight. By the time those problems surface, the hardware is in tooling and the options have narrowed to bad and worse. 

This guide explains what HMI development involves: the main project types, the lifecycle from requirements to field updates, the software stack, framework selection, design for real hardware, industry standards, realistic budgets and timelines, and the choice between building in-house and bringing in a partner. 

It’s written for product managers and technical leads. You won’t need to read any code. 

What is HMI development? 

HMI development is the process of designing, building, and optimising the interface through which a person operates a machine. It covers the display, the controls, and the software underneath that connects a user to an embedded system. In practice it draws on UX design, embedded engineering, hardware integration, and safety compliance in roughly equal measure. 

Most people arrive at the term picturing a control panel bolted to a production line. That’s one version of it. But the same discipline produces digital instrument clusters, chart plotters on a yacht’s flybridge, the touchscreen on a coffee machine, an infusion pump’s display, and the interface in a crane cab. Anywhere a person tells a machine what to do, or a machine reports back, something had to be designed and built for that exchange. 

HMI, UI, and UX: the difference that matters 

The three terms are often used interchangeably, but they are not the same. 

• UI is the visible, interactive surface: the screens, buttons, and states. 

• UX is the whole experience of using the product, including everything that happens off-screen. 

• HMI is the interaction layer between a human and a machine, and specifically one where the machine has physical consequences. 

HMI inherits its methods from UX practice. What sets it apart is the constraints. A mobile app runs on hardware that gets replaced every three years, connects to the cloud, and can ship a fix on Tuesday. An HMI runs on silicon chosen two years ago for its unit cost, might never see a network, and could still be in service in 2041. When it fails, a vessel loses its engine readout or a driver loses their speedometer. 

Types of HMI 

By deployment, you’ll encounter standalone panels, embedded HMIs built into the product itself, networked stations connected to a supervisory system, web-based interfaces, and companion mobile apps. By input method, the field has widened well beyond touch. Physical controls and rotary encoders remain the safer option in gloved or high-vibration environments, while voice, gesture, and multimodal combinations are becoming increasingly common. 

Two kinds of HMI project, and why the difference matters 

Before anything else, work out which sort of project you’re running. Many discussions of HMI development collapse the two, which leads to advice that fits one context and fails in the other. 

	Industrial and control HMI	Embedded product HMI
Where it lives	Control room, plant floor, machine panel	Inside a shipped product: vehicle, vessel, appliance, device
Typical approach	SCADA and PLC platforms, configuration-led	Custom software on fixed silicon, code-led
Hardware	Often a generic industrial PC or panel	A fixed bill of materials, chosen for cost
Dominant standards	IEC 62443, ISA-101, IEC 61508	ISO 26262, IEC 60945, IEC 62304, CE and FCC
Update model	On-site, controlled, scheduled	Over the air, to a fleet already in the field
Service life	Long, but serviceable in place	10 to 15 years, often with no physical access

On an industrial project, you’re largely configuring a mature platform. The vendor has solved rendering, alarm handling, and historian integration. Your work is data modelling, screen design, and integration, and if you need more processing power you can usually specify a bigger box. 

On an embedded product project, you’re engineering software against a hardware budget that was fixed months before you were involved. There is no bigger box. If the UI needs 40MB of RAM and the board has 32MB, someone is redesigning something, and it won’t be the board. The architecture you commit to in month two will still be there a decade later, carrying features nobody has thought of yet. 

Spyrosoft works mainly in the second category: HMIs that ship inside vehicles, vessels, machines, and devices. Most of what follows applies to both worlds, and we’ll flag where it doesn’t. 

The HMI development lifecycle

The lifecycle below has seven phases. At each stage, the most expensive mistakes tend to be inexpensive to prevent early and difficult to correct later. 

Discovery and requirements

You’re establishing three things: who uses this, under what conditions, and against what constraints.

User profiles matter more than personas here. A trained operator working an eight-hour shift needs a different interface from a driver glancing away from the road for a second and a half. Operating conditions need to be written down as specifics: direct sunlight at 100,000 lux, gloved hands, salt spray, vibration, temperature range, one-handed operation.

Hardware constraints belong in this phase as numbers rather than adjectives. Display resolution and brightness. The SoC and its GPU, if it has one. Available RAM and flash. Power budget. Boot-to-first-frame target. “It should feel fast” is not a requirement. “First meaningful frame within 800ms of power-on, full UI within 3 seconds” is.

Compliance scope should be agreed here. If it is deferred, later architectural and design decisions become much harder to change.

Output: functional specification, hardware brief, compliance plan. The mistake that costs most: starting UI design before the target hardware is known. Every hour of design work done against unknown constraints is an hour you may throw away. 

Architecture

Now the decisions with the longest shadow. Operating system: a real-time OS for deterministic, safety-related behaviour, embedded Linux for richer feature sets, or Android where an app ecosystem matters. Rendering strategy: GPU-accelerated, software rendering, or a hybrid where the safety-relevant layer is drawn independently of the rest. Data flow: how signals reach the interface, whether over CAN, NMEA 2000, Modbus, OPC UA, or MQTT, and what happens to the display when they stop arriving. 

Safety-related functions need to be separated from everything else at this point. A telltale that must render within a guaranteed time cannot share a process with the media player. Get that separation wrong and certification becomes disproportionately expensive, because everything in the same partition inherits the highest safety requirement in it. 

Teams building safety-related systems commonly work to a V-model, where each development stage is paired with the verification stage that proves it. Auditors expect clear evidence of this relationship, which is why requirements traceability needs to be designed in rather than reconstructed later. 

Output: architecture document, with the rationale recorded. The mistake that costs most: no partitioning between safety-related and convenience functions. 

UX and UI design 

Wireframes against the real form factor, not a laptop screen. Prototypes running on the actual panel, in the actual environment, as early as you can manage it. A design system tuned to the display technology, the viewing distance, and the lighting the product will live in. 

Usability testing belongs here too, with people who resemble your users rather than colleagues who already know where everything is. For vehicle interfaces that means a simulator or a test vehicle. For marine, it means a screen you can carry onto a deck at midday. 

Output: approved design system and an interactive prototype. The mistake that costs most: signing off designs viewed only on a desktop monitor. 

Implementation

Three layers get built in parallel. The interface layer in your chosen framework. The integration layer that connects it to system signals and translates protocol messages into something the UI can bind to. The platform layer underneath: board support package, drivers, boot sequence, update mechanism. 

Deploy to the target hardware from the first sprint, not the first release candidate. Teams that develop purely against a desktop simulator discover their frame rate problem in month seven, which is roughly the worst possible time to find it. 

Output: a running build on real hardware, updated continuously. The mistake that costs most: treating on-target deployment as an integration activity rather than a daily habit. 

Testing and verification

HMI testing spans more ground than most teams expect. Functional testing of every state and transition. Usability validation, which for medical devices is a regulatory requirement rather than a nice-to-have. Environmental testing across temperature, humidity, vibration, and UV exposure. Performance measurement against the budgets set in phase one. Safety verification for anything ASIL or SIL rated. Hardware-in-the-loop rigs so you can simulate the rest of the system and provoke failure states you can’t safely create in the field. 

Automated regression on target hardware is what makes a 10-year support commitment survivable. Without it, every maintenance release becomes a manual test campaign. 

Our guide to HMI testing strategies for embedded systems covers how to structure this in practice. 

Output: a test evidence pack, which for regulated work is a deliverable in its own right. 

Optimisation

Profiling, then fixing what the profile actually shows rather than what you assumed. Common wins: collapsing overdrawn layers, replacing runtime image scaling with pre-sized assets, cutting texture memory, reworking animations that force full-screen redraws, trimming the boot sequence, and reducing wake-up frequency to protect battery life. 

This phase is where the framework choice from month two either pays off or presents its bill. We’ve written separately on HMI performance optimisation on resource-constrained hardware.

Release, updates, and the long tail

Field update architecture is a day-one decision that most teams defer. How does a new build reach a device that might be on a fishing vessel in the North Atlantic? What happens if an update fails halfway? Can you roll back? Can you stage a release to 2% of the fleet first? 

Then there’s the decade that follows. Hardware components go end-of-life. Toolchains age out. Engineers move on. Maintainability isn’t a vague virtue here, it’s a specification: documented architecture, modular code, no undocumented dependencies, and a build that a new team can reproduce from a clean machine.

Where AI actually compresses this timeline

Every phase above carries a certain amount of manual scaffolding. Rebuilding a design system in code, screen by screen. Writing the same test harness you wrote on the last project. Wiring a prototype to fake data so someone can finally see it move. That scaffolding is where AI has genuinely changed the economics, and it’s worth being precise about which parts, because the claims in this area have got loose.

Design to code. A design system exported directly into framework code instead of a developer reimplementing it from a specification. The gain shows up at the handover between phases three and four, historically one of the slowest and most error-prone transitions in the whole process.

Generated test coverage. Test cases and regression suites derived from the requirements and the interface definition itself, rather than written from scratch. On a project with hundreds of screen states, this is the difference between testing what you had time for and testing what you specified. Our HMI test centre is built around this.

Working demos in days rather than sprints. Put those two together and the front of the project changes shape. Where the hardware and an existing accelerator are a good fit, we can often have an HMI running on a client’s own device within one working day. That moves the first serious conversation from a slide deck to something the team can test.

What it does not compress is equally important: certification evidence, environmental testing, usability validation with real operators, and safety analysis. These activities are bounded by physical testing, regulatory expectations, and human evaluation. AI can reduce surrounding engineering effort, but it does not remove the evidence required for an ISO 26262 assessment. Its value is giving teams more of the schedule for work that cannot be automated.

HMI architecture: the five layers

It helps to picture the stack, because most technical conversations you’ll have with your engineering team are really about which layer a problem belongs to.

Hardware. Display technology (TFT, OLED, e-paper), touch sensor, physical controls, processor, memory, and the thermal envelope that governs how hard any of it can work.

Operating system and board support. The OS itself, plus the drivers that expose the display, touch controller, and communication peripherals. This layer is invisible when it works and all-consuming when it doesn’t.

Framework and rendering. Qt, Flutter, Slint, LVGL, or a game engine. Handles the render loop, animation, input events, and layout. This is the layer people mean when they say “we chose Qt”.

Application. Your screens, states, business logic, and data bindings. The part that behaves like conventional software development.

Connectivity. How the interface talks to the rest of the system, and what it does when that conversation breaks. CAN and Automotive Ethernet in vehicles. NMEA 2000 at sea. Modbus, Profinet, and OPC UA in industrial settings. Bluetooth Low Energy, Wi-Fi, and Matter in the home.

A useful diagnostic question when something goes wrong: which layer owns this? Stutter during a transition is usually framework or application. Stutter that only appears after 40 minutes of use is usually thermal, which means hardware. Input that lags under load is often the driver. 

Choosing an HMI framework 

There’s no correct answer, only a correct method. Here’s the field as it stands. 

Framework	Best fit	Main strength	Watch out for
Qt (QML and C++)	Automotive, medical, marine, industrial	Mature tooling, safety-certified variants, a vendor with 30 years behind it	Commercial licence cost
Flutter	Consumer devices, Android-based products	Fast iteration, excellent animation, large talent pool	Wants a capable GPU; the embedded story is still maturing
Slint	Memory-constrained IoT devices	Very small runtime footprint, Rust foundations	Smaller ecosystem and community
LVGL	MCU-class hardware	Runs where little else will, permissive licence	You build more of the surrounding tooling yourself
Unity and Unreal	Premium 3D clusters, showpiece interfaces	Photorealistic rendering	Hardware cost, licensing model, team skills
React Native	Android Automotive, connected appliances	Familiar JavaScript ecosystem	Poor fit for anything on a safety-related path

Our comparison of the top embedded HMI UI frameworks goes into the technical detail. For a decision, five questions do most of the work. 

What’s the silicon? This is the hard gate. Available RAM, flash, and GPU capability eliminate options before preference gets a say. An MCU with 512KB of RAM rules out most of the table. 

What compliance level applies? Safety certification narrows the field fast, because you need a framework with a certified variant, documented tool qualification, and a vendor prepared to support an audit. This is why Qt dominates regulated work. 

What can your team maintain in 2036? Not what they’re excited about now. Framework choice is a hiring decision with a 10-year horizon. 

What’s the total licence exposure? Model it across the product’s life and expected volumes, including royalties. Free at prototype stage and free at 200,000 units are different propositions. 

How will designers hand work to developers? Teams underestimate this until they’re manually recreating a design system by hand. Tooling that exports directly into the framework saves months across a product’s life. 

Spyrosoft is a Qt Premium Partner, and we also build in Flutter, Slint, LVGL, Unity, and Unreal. That mix isn’t hedging. Different products genuinely need different answers, and we’d rather tell you a framework is wrong for your hardware than sell you the one we know best. For a closer look at the two most common finalists, see Flutter vs Qt for embedded HMI and our deeper piece on Qt HMI development. 

Design principles that survive contact with real hardware 

Design for the environment, not the office 

Your interface will be used in glare, in the dark, with wet or gloved hands, on a surface that’s vibrating. Contrast ratios that look elegant in a design tool disappear at midday. Touch targets sized for a fingertip fail for a hand in a work glove, which needs somewhere around 15mm minimum. Anything that depends on a subtle colour difference will be lost on a screen at half brightness. 

Cognitive load is the enemy 

Hick’s law says decision time grows with the number of options presented. Fitts’s law says the time to hit a target depends on its size and distance. Both become more consequential in a moving vehicle, where visual attention away from the road must be kept brief. 

Practical consequences: put the primary action where the hand naturally rests, make it large, and hide the settings nobody uses in an emergency behind one deliberate tap. Progressive disclosure isn’t about elegance here. It’s about how many things a person can process while doing something else. 

Specify the failure states 

What does the screen show when a sensor drops out, a bus goes quiet, or a value arrives outside its plausible range? A gauge that keeps displaying the last known number is actively dangerous. A blank field is confusing. An explicit “no data” state is correct, and it needs designing, testing, and signing off like any other screen. 

Teams usually specify these late, which is why they’re so often inconsistent between screens. Put them in the requirements. 

Never rely on colour alone 

Colour vision deficiency affects a meaningful share of users, particularly men. Anything critical should therefore use more than colour alone, for example colour plus shape, text, sound, or haptic feedback where the hardware allows. This is established practice in safety-conscious interface design. 

Consistency is a safety feature 

If navigation lives bottom-left, it lives bottom-left on every screen, in every variant, in every language. Muscle memory is what lets an experienced operator act without looking, and inconsistency destroys it. Design system discipline isn’t polish. It’s error prevention. 

HMI development by industry

Automotive 

You’re building instrument clusters, infotainment, head-up displays, ADAS overlays, and increasingly passenger and rear displays. The binding constraints are glance time, boot time (drivers expect the reversing camera before they’ve finished putting their seatbelt on), functional safety for anything the cluster reports, and a support commitment measured in a decade and a half. 

Standards stack up here: ISO 26262 for functional safety, ISO 15005 and 15008 for interaction ergonomics and legibility, and UN Regulation No. 155 with ISO/SAE 21434 for cybersecurity, which has been mandatory for new vehicle type approvals in the EU, Japan, and South Korea since 2022. Qt and Android Automotive dominate; Unreal appears in premium 3D clusters. 

Further reading: automotive HMI design for instrument clusters and infotainment, ISO 26262 compliance in automotive HMI development, our piece on MicroHMI architecture for Android Automotive, and our automotive IVI and cluster platform. 

Marine 

Chart plotters, engine and vessel monitoring, and integrated bridge or yacht control systems. Sunlight readability is the defining problem, followed closely by the fact that the vessel may have no connectivity for weeks. Everything has to work offline, and the interface has to remain legible through polarised sunglasses at a shallow viewing angle. 

NMEA 2000 integration is near-universal. Certification runs through IEC 60945 for environmental and EMC requirements, and the Marine Equipment Directive for EU type approval. See our work on marine HMI with Qt and NMEA 2000, the yacht control panel accelerator, and our guide to HMI for marine navigation systems. 

Consumer electronics 

Appliances, wearables, smart home hubs, and personal devices. The constraint here is commercial rather than regulatory: the bill of materials is squeezed hard, so you’re delivering a premium-feeling interface on modest hardware. Nobody reads the manual, so the interface has to explain itself in the first 10 seconds. And the product has to survive being used by everyone in the household. 

Compliance is mostly CE and FCC marking, with accessibility requirements tightening in several markets, and the Cyber Resilience Act now applies squarely to connected devices in this category. More in HMI for consumer electronics and our consumer electronics work. 

Industrial and heavy machinery 

Machine panels, supervisory stations, and cab interfaces for excavators, cranes, and agricultural equipment. Alarm management is the discipline that separates good from bad here: a screen that raises 40 alerts during an incident has told the operator nothing. ISA-101 exists largely because of this. 

Functional safety runs through IEC 61508 and its SIL levels, cybersecurity through IEC 62443, and you’ll almost always be integrating with equipment older than the interface you’re building. 

Medical devices 

Device interfaces, monitoring displays, and diagnostic equipment. What makes medical distinctive is that usability engineering is itself regulated. Under IEC 62366 you must demonstrate, with evidence, that the interface doesn’t induce use errors. IEC 62304 governs the software lifecycle, ISO 13485 the quality system, and in the US, 21 CFR Part 11 covers electronic records. 

The practical effect is that documentation and formative testing run alongside development from the start, not after it. 

Safety, compliance, and cybersecurity 

Compliance is where HMI budgets go to be surprised. Not because the standards are unreasonable, but because teams treat them as a final gate rather than an architectural input. 

Standard	Domain	What it governs
ISO 26262 (ASIL A to D)	Automotive	Functional safety of road vehicle systems
ISO 15005 and 15008	Automotive	Driver interaction ergonomics and display legibility
UN-R155 and ISO/SAE 21434	Automotive	Cybersecurity management and engineering
IEC 61508 (SIL 1 to 4)	Industrial	Functional safety of electrical and electronic systems
IEC 60945 and MED	Marine	Environmental and EMC requirements, EU type approval
IEC 62366 and IEC 62304	Medical	Usability engineering and software lifecycle
IEC 62443 and ISA-101	Industrial	Automation cybersecurity and display design practice
Cyber Resilience Act (EU) 2024/2847	Any product with digital elements	Vulnerability handling, reporting, secure-by-design requirements
Machinery Regulation (EU) 2023/1230	Machinery and heavy equipment	Health and safety, now covering software, connected systems, and AI
CE and FCC	Consumer	Market access

The regulatory calendar you’re now designing against 

Three dates are worth putting in front of anyone planning a product launch into the EU. 

Date	What changes	Who it catches
11 September 2026	Cyber Resilience Act reporting obligations begin. Actively exploited vulnerabilities and severe incidents need an early warning within 24 hours and a full notification within 72	Any product with digital elements on the EU market, including products already sold
20 January 2027	The Machinery Regulation replaces the Machinery Directive, with software, connected systems, and AI explicitly in scope	Machinery, heavy equipment, and the interfaces in their cabs and panels
11 December 2027	Cyber Resilience Act obligations apply in full: essential cybersecurity requirements, conformity assessment, CE marking, technical documentation	As above

The Cyber Resilience Act is the one HMI teams tend to underestimate, because it attaches to the product with digital elements rather than to the vehicle or machine around it. If your interface reaches the EU market, you’ll need a software bill of materials, a documented vulnerability handling process, and an update path that still works years after launch. That over-the-air architecture decision from phase seven stops being an engineering preference and becomes a legal requirement. 

Note the reporting duties in particular. They apply to products already in the field, so a device you shipped in 2024 is in scope from September 2026 whether or not anyone budgeted for it. 

What compliance actually asks of you 

Traceability, first. Every requirement links to a design element, and every design element links to a test that proves it. Retrofitting this onto a finished codebase is one of the least enjoyable projects in embedded software. 

Then safety analysis: FMEA and fault tree analysis to establish what can fail and what happens when it does. Then documented evidence, because at audit it isn’t enough to have tested something, you have to show how. At higher safety levels (ISO 26262 ASIL C and D, IEC 61508 SIL 3 and above) your development tools themselves may need qualification, and an independent assessor becomes mandatory. 

The one decision that determines whether this is affordable 

Partitioning. If safety-related functions share memory space and execution context with everything else, then everything else inherits their safety requirement, and you’ll be certifying your media player. Separate them properly, and you certify a small, well-understood component while the rest of the interface develops at normal speed and cost. 

That decision is made in week three of architecture. Not in month 14. 

What HMI development costs and how long it takes

Very few people publish numbers here, which is unhelpful when you’re trying to build a business case. Here’s an honest starting point, with the usual caveat that scope, region, and hardware maturity move these figures considerably. 

Project shape	Typical duration	Indicative budget
Single-screen embedded panel, no certification	3 to 4 months	Low five figures up to around £100k
Multi-screen product HMI, custom UI, baseline compliance	6 to 9 months	£100k to £300k
Safety-certified automotive or medical HMI	12 to 24 months or more	£500k into the millions

What actually drives the cost: 

1. Number of screens and, more importantly, states. Forty screens with two states each is a smaller job than 10 screens with 20 states each. 

2. Hardware maturity. Building against a stable, available board is straightforward. Building against a board that’s still changing means rework. 

3. Certification level. The jump from uncertified to ASIL B is significant; ASIL D is a different category of project. 

4. Integration scope. Every protocol and every legacy system adds surface area. 

5. 3D and animation ambition, which drives both engineering effort and hardware requirements. 

6. Localisation and variants. Twelve languages with right-to-left support and four trim levels multiply the testing matrix. 

7. The support commitment you’re taking on afterwards. 

And the three things that wreck schedules: hardware arriving late or changing after design sign-off, requirements churn after the design freeze, and compliance evidence assembled retrospectively. All three are avoidable. None of them are avoided by working faster. 

Build in-house or bring in a partner?

An honest read, including the cases where you shouldn’t call us. 

Build in-house when 

The interface is your competitive advantage and your roadmap is long and stable. When the HMI is the product experience, and you’ll be iterating on it for years, that capability belongs inside the company. 

You already have embedded and framework expertise on the team. If people have shipped a Qt or Flutter product on constrained hardware before, you’re most of the way there. 

You can absorb the ramp-up. A capable team learning a new framework and a new domain typically needs six to 12 months to reach full productivity. If your launch date can carry that, in-house is often the better long-term economics. 

Bring in a partner when 

You need a capability you don’t have and can’t quickly hire. Safety certification experience, Qt at scale, NMEA 2000, Android Automotive: these are narrow specialisms with slow, expensive learning curves. 

Time to market is the binding constraint. An experienced team can begin productive work immediately instead of spending the first months building unfamiliar capability. 

You’re validating a concept before committing headcount. Building a working prototype with an external team is a cheaper way to test an idea than hiring for it and discovering the idea was wrong. 

The domain has a steep learning curve, and avoidable mistakes can cost more than the initial capability gap. 

The hybrid most companies land on 

A partner builds the architecture and first release; your team takes over maintenance and iteration. It works well, but only on one condition: the code that comes back has to be documented, modular, and genuinely handover-ready. Write that into the contract, with acceptance criteria, rather than raising it at the kick-off meeting and hoping. 

Or start from something that already runs 

The build-versus-outsource framing hides a fourth option. For several common product categories the interface doesn’t have to start from an empty repository, because a domain accelerator already exists and can be adapted. 

We maintain a few of these: 

• Wavey, a gesture-controlled in-vehicle infotainment and instrument cluster system 

• The yacht control panel, bringing propulsion, navigation, power, and alarms onto one rugged touchscreen 

• LifeTrack, for medical-grade monitoring interfaces 

• HomeOps and Smart Shower, for connected appliance and smart home interfaces 

• The multimodal HMI accelerator, for products combining touch, voice, and gesture 

The list matters less than what it changes about the first conversation. Instead of evaluating an approach only on paper, you can assess a working system on your own hardware. In suitable cases, that can happen within a working day. Whatever you decide about building or outsourcing afterwards, you make the decision having seen something run. 

Ten questions worth asking any HMI partner 

1. Which frameworks do you actually specialise in, and what’s your partner status? 
2. Which certified products have you shipped under the standard that applies to us? 
3. Can we speak to a reference client in our industry? 
4. Who owns the IP, the toolchain, and the build system at the end? 
5. How do you produce test evidence, and what does the pack look like? 
6. Do you run continuous integration on target hardware? 
7. What are your documentation and handover standards? 
8. How do you keep a codebase maintainable across a 10-year lifecycle? 
9. What’s your team continuity like, and who stays with the project? 
10. What in our current specification would you push back on?

That last question is the useful one. Anyone who agrees with your entire brief either hasn’t read it or won’t tell you when you’re wrong. 

Where HMI development is heading

AI is moving onto the device. Voice control that doesn’t need a connection, interfaces that adapt to how an individual uses them, anomaly detection running locally. The interesting constraint is that inference has to fit inside the same memory and thermal envelope as everything else, which is why quantised models and dedicated NPUs are becoming standard parts of the hardware conversation. 

Multimodal input is becoming a baseline expectation in many product categories. Touch is increasingly combined with voice, gesture, and physical controls, chosen for the context rather than applied uniformly across the product. Our view on the future of multimodal HMI covers where this is going. 

Products are becoming software-defined. When features arrive after purchase, the interface becomes the delivery mechanism, and the update architecture stops being an afterthought. 

3D rendering is becoming viable on a wider range of hardware. Capabilities that once required premium silicon increasingly run on mid-range automotive SoCs, changing what teams can consider for mainstream products. 

None of this changes the fundamentals. Interfaces still have to be legible in sunlight, fail safely, and be maintainable a decade after the people who wrote them have moved on.