Automotive HMI Design: Principles, Trends, and Challenges

Automotive HMI design is the design of everything drivers and passengers use to understand a car and tell it what to do: the instrument cluster, the centre screen, the head-up display, steering-wheel buttons, physical switches, voice, sound, haptics and the phone app that talks to the car. It is not dashboard styling. A car dashboard is not a tablet mounted in a vehicle, because the person using it already has a more important job, and that job is happening at 70 mph.

Most car dashboard UI design inspiration misses this completely. Scroll any gallery and you’ll find glowing dials, glassy cards, a map rendered like a sci-fi film and a playlist in a font thinner than a hair. Beautiful. Now find the hazard lights on it while a truck drifts into your lane.

At ANODA, we design dense interfaces around the moment of use. The pattern in cars is familiar from other dense products: the team designs the screenshot, not the moment of use. In a SaaS dashboard that mistake costs you churn. In a car it first costs attention the driver doesn’t have, and then it costs money: the test drive that quietly ends in “we’ll think about it”, the dealer visit for a problem that turns out to be a sentence, the connected-services subscription nobody activates and the over-the-air update you ship to undo last year’s clever idea.

The practical job is deciding what goes where and testing it before hardware freezes the interaction model. Design, human-factors and safety teams need one model of states, priorities and controls they can evaluate together.

Why ANODA starts with the scenario before the cockpit render

An impressive cockpit render does not tell a team how a driver changes a destination, handles a failed voice request or understands an assistance state. Discover those gaps after hardware decisions are fixed and every redesign crosses more teams, variants and release plans. More screen space does not solve the missing interaction model.

ANODA offers the design work that makes those decisions concrete: scenario maps, information priority, parked and moving flows, interaction architecture and testable prototypes. We work with your hardware, engineering and safety specialists on the requirements each prototype must meet, so the next review can examine behaviour rather than debate a screenshot.

Bring us the task that is too hard to complete, the alert drivers misread or the companion-app setup they abandon. We will turn it into clear flows and states your team can evaluate before committing to the next implementation. Discuss your automotive product with ANODA.

What automotive HMI design actually covers

HMI stands for human–machine interface. In a vehicle it is the whole conversation between people and the car, in both directions: what the car shows, says and vibrates, and every way a person can answer back. The screens are the loudest part of that conversation. They are not the whole of it.

Each surface has a job, and trouble starts when a team forgets which job belongs where:

• Instrument cluster. Directly behind the steering wheel, in the driver’s line of sight. Speed, warnings, driver-assistance status, range, the next navigation step. Things the driver needs while driving, and very little else.
• Head-up display. Information projected into the view through the windscreen, so the eyes barely leave the road. The most valuable real estate in the car and the easiest to clutter.
• Centre display, or infotainment. Navigation, media, phone, climate, settings, charging. Reachable by driver and front passenger, which makes it a shared surface with two very different users.
• Steering-wheel controls and stalks. What the driver uses without looking: indicators, wipers, cruise control, volume, voice activation.
• Physical switches. Hazard lights, climate knobs, gear selection, emergency call. Findable by feel, in the dark, with gloves on.
• Voice. Good for complex input like destinations and messages, useless if it needs three attempts.
• Sound and haptics. Chimes, spoken prompts, vibration in the seat or wheel. The only channels that don’t need the eyes at all.
• Passenger and rear displays. Entertainment and comfort for the people who aren’t driving.
• Companion app. The phone app that plans the trip, warms the cabin, shows charge, locks the doors and carries the relationship after the driver walks away.

Think of a restaurant kitchen during service. The grill doesn’t plate desserts, finished food leaves through the pass, and nobody puts the dishwasher next to the fryer. When every station can do every job, you don’t get flexibility. You get the soup after the dessert and somebody burned.

That’s why “automotive UI design” is a slightly misleading phrase: it makes the job sound visual and single-surface. The real design question is allocation: which information and which action lives on which surface, in which driving state, through which channel, and what happens when that channel fails.

A car dashboard is not a tablet mounted in a vehicle

On a tablet, the screen is the task. The user sits, looks, reads, taps, scrolls and changes their mind. Attention belongs to the interface, and a good interface earns more of it.

In a car, the screen is a side job. The main job is steering a two-tonne machine between other two-tonne machines, pedestrians and cyclists. Every second the driver spends looking at the display is borrowed from the road, and the road doesn’t pause while you find the fan setting. Designing a car screen like a tablet is writing a novel for someone running on a treadmill at full speed. The prose may be wonderful. The reader will still fall off.

The physical context makes it worse:

• Motion and vibration. Fingers miss on a moving road. A tap target that works on a desk becomes a coin toss over a potholed street.
• Reach. The centre display sits at arm’s length, often at the edge of comfortable reach. Precision drops as the arm extends, and the driver’s body turns away from the road.
• Light. Low winter sun, headlights at night, polarised sunglasses, reflections on glossy glass. Contrast that looks crisp in the design studio vanishes at four in the afternoon in November.
• Shared users. Passengers reach for the same screen. Several drivers share one car. A rental driver meets the interface for the first time on a motorway slip road.

This is where teams lose money without noticing. They benchmark the car against phones, add features at phone speed and judge the result in a design review on a 27-inch monitor. The review goes well. Then a buyer takes a test drive, can’t change the fan speed without three taps and two glances, and says “we’ll think about it”. You paid for the showroom, the marketing, the lead and the salesperson’s hour. The screen lost the sale in eight minutes.

Driving state changes information priority

A tablet has one context: someone using a tablet. A car has several, and they change what matters from one minute to the next:

• Parked. The driver can look, read and explore. Setup, detailed settings, long lists and video belong here.
• Pulling away and manoeuvring. Cameras, sensors, gear state and surroundings. Everything else should get out of the way.
• Cruising. Speed, the next navigation step, assistance status, and short, glanceable media or climate adjustments.
• Dense traffic and complex junctions. Even less. Guidance at the right moment, warnings, and silence for everything that can wait.
• Warning or emergency. One message: what happened, how serious, what to do now. Nothing competes with it.
• Charging or refuelling. A parked state with its own jobs: charge progress, cost, time remaining, something to do while waiting.

Medicine sorted this out long ago. A triage nurse doesn’t see patients in the order they walked in. She sees them in the order in which things can go wrong. A good HMI ranks information the same way: by consequence in the current state, not by what the product team is proudest of. The music visualiser can wait. The cyclist can’t.

In practice, each important screen is a set of states, not a single layout. Navigation parked means full search and route options; moving, it means the next step, a few destinations and voice. Some tasks shouldn’t be available on the driver’s screen while moving at all: typing on a keyboard, scrolling long lists, reading long text, watching video.

The objection we hear is always the same: “Users will be annoyed if we lock things.” Some will. Annoyance is a design problem you can solve with a clear reason and a voice alternative. A crash is not a design problem you can solve at all. And the lockout message is a design surface in its own right. “Not available while driving” with nothing else is a closed door. “Say the address, or finish when parked. We’ll keep what you typed” is a door with a sign on it.

Glance time and cognitive load: the budget nobody writes down

Every in-car task has a price in glances. The driver looks down, reads, decides, maybe taps, looks back at the road, checks a mirror, looks down again. Designers who have never measured this think of tasks in taps. Drivers pay for them in seconds with their eyes off the road.

There is published guidance on that budget. The Visual-Manual Driver Distraction Guidelines from the US National Highway Traffic Safety Administration, published in the Federal Register on 26 April 2013, use a test with 24 participants: at least 21 must have a mean off-road glance of no more than 2 seconds, no more than 15% of their glances longer than 2 seconds, and total eyes-off-road time of no more than 12 seconds for the task. They are voluntary guidelines, not a regulation, and they aren’t the only reference. But the numbers make the point better than any principle: 12 seconds in total, for a whole task. Plenty of infotainment menus spend that finding the right tab.

A goalkeeper could check his phone during a match. He just can’t do it during a penalty, and he doesn’t get to choose when the penalty comes. That’s glance time. Every glance has to be short, and every glance has to be complete: the driver should get what they looked for in one look, not assemble it across three.

Glanceability has concrete rules, and none of them is “make it minimal”:

• One question per glance. “How fast am I going?” “Which exit?” “Is the assistant on?” If one glance has to answer two questions, one of them loses.
• Stable positions. Speed always lives in the same place. Warnings always appear in the same zone. The eye learns where to look, and learning is the cheapest glance reduction you will ever buy.
• Size and contrast for the worst light, not the studio. Test in low sun and at night, with sunglasses on.
• Numbers over charts where precision matters. “86 mi range” beats a beautifully curved battery arc when the question is “Will I make it home?”
• No motion without meaning. Animated backgrounds, pulsing highlights and flourishes pull the eye whether the driver wants them to or not. The eye is wired to notice movement. Your brand animation is spending the driver’s attention on your behalf.

Cognitive load is the other half of the bill, and it’s the half that hides. A driver can have their eyes on the road and their mind in a menu. Voice reduces glances, but a conversation that goes wrong loads the mind just as heavily: the driver rehearses the command, listens to the reply, spots the mistake and plans the correction, all while nominally watching traffic. Anyone who has argued with their energy supplier’s automated phone line knows the feeling. Now picture doing it while merging.

The cluster is where teams quietly overspend the budget, because every department wants a slot. The render looks rich. On the road it reads like a newspaper front page at 70 mph. We see the same thing in dense dashboards of every kind, not only in cars: when everything is important, the one thing that matters this second arrives last.

Alerts and warnings: stop crying wolf

Modern cars talk a lot: lane departure, blind spot, speed limit, tyre pressure, seatbelt, charging complete, update available, “take a break”. Each alert was added by a team with a good reason. Together they are a choir, and nobody can hear the soloist.

The boy who cried wolf didn’t lose his audience because wolves were unimportant. He lost it because the alarm sounded the same every time and meant nothing most of the time. Drivers learn the same lesson from their cars. When chimes are frequent and mostly trivial, people ignore chimes or switch the feature off. Then the one warning that matters plays to an empty room.

An alert system needs a hierarchy before it needs visuals:

• Information. Something changed, no action needed. Visual only, in its usual place, no sound. “Charging complete.”
• Advisory. Something to deal with soon. Visual, perhaps a single soft tone, dismissible. “Washer fluid low.”
• Caution. Something that affects the drive. Clear visual, a distinct tone, stays until acknowledged or resolved. “Tyre pressure low.”
• Warning. Act now. The strongest visual in the driver’s line of sight, a distinctive sound, possibly a haptic pulse, nothing competing with it. “Brake now.”

Three rules hold the hierarchy together. Sound and vibration are reserved for alerts that earn them, so they keep their meaning. Prioritise warnings by urgency and consequence, keeping any still-relevant critical condition visible; the vehicle’s safety requirements determine what can queue or be suppressed. And every alert above information level answers three questions: what happened, how serious it is and what to do now.

That last rule is where most warning copy falls apart. “Check system” is a school report that says “See me”: technically communication, emotionally a threat, practically useless. The driver doesn’t know whether to pull over, drive to a garage or carry on. So they panic, ignore it or phone the dealer. The dealer books a workshop slot, the technician finds nothing wrong with the car, and the manufacturer pays for a visit caused by three words.

Physical controls versus touch: bring the buttons back, but not all of them

For a decade the direction looked settled. Buttons were old, screens were modern, and a clean dashboard with one big pane of glass photographed beautifully. It also moved the fan speed, the demister and occasionally the glovebox into menus. Somewhere, a cost engineer was very happy with the bill of materials.

A physical control has properties a touchscreen can’t fake. You find it by feel, it stays where it is, and it clicks back at your fingers. You can use it without looking, which is the whole point in a moving car. A touchscreen button has none of that. It is a picture of a button, and you need your eyes once to find it and again to check you hit it.

Hiding critical functions in a screen is making a lifeguard log in before he can jump in. The system is modern, secure and consistent, and somebody is still in the deep end during the two-factor authentication.

The industry is correcting course. Euro NCAP, the European new-car safety rating programme, announced on 26 November 2025 that its 2026 protocols bring new assessments of the human–machine interface, evaluating the placement, clarity and ease of use of essential controls, including the availability of physical buttons for commonly used functions. When a star rating starts asking about buttons, minimalism stops being a purely aesthetic decision.

But the lesson isn’t “buttons good, screens bad”. That’s the same thinking in reverse, and it ends in a cockpit that looks like an aircraft’s overhead panel. For every function, ask four questions: how often is it used, how urgent is it, is it needed while moving, and does it have to work without looking?

• Physical, always in the same place: anything safety-critical or instant. Hazard lights, indicators, wipers, horn, emergency call, gear selection, demisting.
• Physical or on the steering wheel: frequent adjustments in motion. Volume, temperature, fan, cruise and assistance controls, next track, voice activation.
• Touch with a voice alternative: occasional in-motion tasks with a short path. A recent destination, a favourite station.
• Touch, parked: rich, rare or detailed tasks. Settings, driver profiles, charging schedules, app setup.

Touch still has its place. It’s flexible, updatable and fine for things you do rarely and while stationary. The mistake was never touchscreens. The mistake was putting all your eggs in one basket and making the basket a sheet of glass that needs your eyes.

Voice, haptics and multimodal fallback

Voice is the obvious answer to glance time, and it helps: saying “navigate to the office” beats typing it. But voice mishears accents, road noise, children in the back and foreign names. It can’t show options at a glance, and it turns a quick adjustment into a conversation. And when it fails, the driver’s reflex is to reach for the screen, in motion and annoyed, which is exactly what voice was supposed to prevent.

Haptics are the quiet partner: a detent on a knob, a pulse in the wheel for lane drift, a buzz in the seat on the side of the hazard. They need neither eyes nor ears, and they’re worthless once overused. Buzz for everything and the body tunes it out.

The design principle is redundancy with priority. Every critical function should be reachable through more than one channel, and every critical piece of feedback should reach more than one sense. Think of a tower block with a lift and no stairs. The lift is faster, modern and works nearly all the time. The day it doesn’t, everyone finds out what “nearly” costs.

A multimodal design documents, for each key task:

• The primary channel in each driving state: voice in motion, touch when parked, a physical control for the instant cases.
• What happens when the primary channel fails: a misheard command, a cancelled request, a noisy cabin.
• How the car confirms the action: a tone, a short spoken confirmation, a visible change in a stable place.
• How the driver undoes it without looking.

Voice assistants with large language models behind them are the newest reason to get this right. An assistant that can “do anything” in the car is a waiter who promises the kitchen can make whatever you like. Lovely, until you order. The driver still needs to know what it can do, when it has done it and how to take it back. A confident wrong answer about the nearest charger isn’t a chat quirk. It’s a detour with a flat battery at the end.

Personalisation and context-aware adaptation without the magic tricks

Personalisation in a car starts with the sensible: seat, mirrors, climate, favourite destinations and media for each driver profile. Then comes adaptation. The car notices you call home every weekday around six and suggests it, warms the cabin before your usual departure, surfaces the charger you use on long trips. Done well, it removes steps. Done badly, it’s an interface that rearranges itself while you drive.

Imagine a keyboard that shuffles its letters to wherever it predicts your next finger will land. Clever on paper. In practice you type blind, as everyone does, and get gibberish, because the keyboard decided the E belonged somewhere else today. Muscle memory is the driver’s most valuable glance-saving asset, and adaptive layouts delete it.

The line we draw is simple:

• Adapt content, not positions. A suggestion can change. The slot it lives in doesn’t. Critical controls and status never move.
• Suggest, don’t act. For anything with consequences, the car offers and the driver confirms. Silent automation of non-trivial actions is how you get a car that turned the heating off “because you usually do”.
• Give the reason in a few words. “Your usual 6 p.m. call” is understood at a glance. An unexplained suggestion is noise, and it makes the next suggestion less credible.
• Make it easy to switch off and hard to get lost. A clear profile, a visible reset, no hidden learning the driver can’t see or correct.

The commercial temptation is to use personalisation for upselling: a premium navigation offer in the cluster halfway through a drive. It’s the fastest way to teach a driver that suggestions are adverts, and after that they ignore the useful ones too. You paid to build a recommendation engine and trained your customers to look away from it.

Driver assistance and automation: who is driving right now?

Advanced driver assistance systems, usually shortened to ADAS, change the HMI’s core job. Adaptive cruise, lane centring, assisted parking and more capable systems on some roads mean the interface no longer just shows the road and the car. It has to show a relationship: what the system is doing, what the driver is responsible for and when that changes.

The most dangerous moment isn’t when the system fails. It’s when the driver and the system each think the other one is in charge. Picture two teachers on a school trip, each certain the other is counting the children. Both are experienced, both are responsible, and a child still gets left at the museum. That’s mode confusion, and it doesn’t need a bad driver or a bad algorithm. An ambiguous icon is enough.

Assistance HMI has to answer, at a glance, in the cluster or head-up display:

• Is the system off, available or active? Three states, three clearly different visuals. “Available but not active” is where most of the confusion hides.
• What is it controlling? Speed only, speed and steering, or more.
• What does the driver still own? Hands on the wheel, eyes on the road, supervision.
• Is a handover coming? When the system needs the driver back, it has to say so early, escalate through sight, sound and touch, and confirm when the driver has taken over.
• Why did it change? If the assistant disengages because the lane markings disappeared, the driver should hear why, not just watch an icon turn grey.

Driver monitoring adds another layer: cameras that check whether the driver is watching the road. The interaction is delicate. Too sensitive, and the car nags someone checking a mirror. Too polite, and it misses a driver who is falling asleep. Calibrating that is human-factors engineering and safety validation, not UI polish, and nobody should pretend a well-drawn icon replaces it. What design owns is clarity: the driver always knows what the car expects of them.

Mode confusion doesn’t need a bad driver or a bad algorithm. An ambiguous icon is enough.

Passenger experiences and the companion app

Passengers are real users, and cars increasingly design for them: passenger-side displays, rear entertainment, separate climate and media. The HMI question is containment. Whatever entertains the passenger must not recruit the driver. A film playing in the driver’s peripheral vision is a magician’s assistant: her whole job is to make you look in the wrong place. Passenger displays need viewing-angle control or content rules, and shared surfaces need to know who is touching them before they allow anything that would distract the driver.

Then there’s the car’s life outside the car. The companion app plans trips, warms the cabin, shows charge and locks the doors. It’s also where the manufacturer’s relationship with the owner lives after the sale, and where connected-services revenue quietly succeeds or dies. Every owner who never activates the app, because the showroom setup asked for an account, a pairing code, a stack of permissions and a subscription decision in one sitting, is a customer you paid to acquire who never reached the part you hoped to charge for.

The best companion experiences move work out of the car: choose the destination on the sofa, not at the traffic lights. The handoff has to be reliable: a destination sent from the phone should be waiting in the car, not lost in a sync error the driver discovers on the motorway.

Software-defined vehicles: the interface keeps changing after the sale

Software-defined vehicles have changed the rules for HMI teams. Features arrive after delivery, bugs get fixed over the air, and the interface a buyer tried in the showroom may not be the one they drive next spring. That’s powerful. It’s also a promise to keep the product coherent across years of updates, screen sizes, trims and hardware generations.

An over-the-air update that moves a control is the clocks going forward: harmless on paper, and everyone is late on Monday. The driver built habits on the old layout. Change it without warning and you’ve reset their muscle memory midweek, on the road. Updates that touch the HMI need the discipline of a redesign: release notes the driver actually sees while parked, fixed positions for critical functions and a way to learn the change before it matters.

The constraints behind the scenes shape the design as much as any principle:

• Hardware cycles are long, software cycles are short. Screens, knobs and processors are fixed years before launch while the software keeps moving. Design has to decide early what is physical and what may change.
• Performance is a UX feature. Start-up time, the delay before the camera view appears, frame drops in the map. A beautiful transition that stutters reads as broken.
• Variants multiply. Screen sizes, trims, languages, left- and right-hand drive, markets with different rules. Without a shared design system and clear component rules, each variant drifts until nobody knows which one is the reference.
• Many teams, one cockpit. Embedded software, hardware, safety, brand, connected services and suppliers all touch the same interface. Without a shared model of states and names, each one builds a sensible piece of an incoherent whole.

This is where the money leaks: changes after hardware freeze, variants designed one at a time, defects nobody can reproduce because nobody wrote down how each state behaves. The fix is boring and effective: one written model of states, priorities and channels that design, engineering and safety all read the same way.

Prototyping and validating HMI under real constraints

A design review on a monitor is not validation. It’s trying on a raincoat in the living room: it looks the part, and you’ll find out whether it works when the weather arrives. HMI has to be tried in conditions close to the real thing: the right screen size, at the right distance and angle, with the driving task competing for attention.

Validation works as a ladder. Each rung costs more than the one below and catches different problems:

1. Task and state mapping. Before any pixels: the driver and passenger tasks, the driving states, which tasks are allowed in which state and the priority of information in each. Most bad HMI decisions are already visible on paper.
2. Interactive prototypes on real screen geometry. Clickable flows on a display of the correct size and position, in a seating mock-up or a parked car, not on a laptop.
3. Simulator studies with a driving task. Participants drive a simulated route while completing tasks, and glance behaviour, task time, errors and driving performance are measured. This is where glance budgets stop being theory.
4. Human-factors evaluation and the safety process. Specialist testing against the guidance and rating protocols that apply to the vehicle and market, run by the people accountable for safety.
5. On-road studies and post-release monitoring. Controlled on-road studies where appropriate, then real-world signals after launch: features switched off, alerts dismissed, support contacts, workshop visits where no fault was found.

ANODA makes the task mapping and interactive prototypes concrete early, so specialist evaluation starts with a clear interaction model. We map the scenarios, design the interaction architecture and build prototypes ready for testing, and we plan targeted UX research for driver and passenger scenarios before a team commits to an interaction model. We align prototype scenarios and acceptance criteria with your automotive human-factors and safety specialists, then use their findings to refine the interface.

Automotive HMI trends worth your roadmap, and the ones to question

Most lists of automotive HMI trends are bells and whistles in a nice font. Here is how we read the current ones, with the question each should answer before it earns a budget line.

Notice the pattern. Every trend adds capability, and every one of them can spend attention the driver doesn’t have. The trend that wins isn’t the one with the most gasps in the reveal video. It’s the one that makes the next glance shorter.

Where to start with your automotive HMI

If you’re designing a new cockpit, a connected-vehicle product or a companion app, start with decisions, not visuals: the task list, the driving states, the priority of information in each, the channel allocation and the alert hierarchy. That’s the core of our automotive product design work, and the foundation for end-to-end UI and UX design of every screen that follows. Skip it and you’ll be back at the drawing board after hardware freeze, which is the most expensive drawing board in the building.

If the product already exists and people struggle with it (drivers switching features off, alerts nobody understands, a companion app few owners activate), start with an interface audit of the existing flows and fix the riskiest failures first.

Every quarter you don’t fix it, you choose it: the confusing alert keeps booking workshop slots, the nagging assistant keeps getting switched off, and the unused app keeps not selling the subscription it was built for.

A car interface is judged in the two seconds a driver can spare. Design for those two seconds, and the showroom gets a lot easier.