Automotive UX: Designing In-Car Interfaces

Automotive UX is the design of everything a driver and passengers see, touch, hear and say inside a vehicle: the instrument cluster, the centre screen, the steering-wheel buttons, the voice assistant, the chimes. It borrows most of its methods from ordinary product design. What it cannot borrow is the assumption that the interface has the user's full attention. In a moving car it never does.

This guide covers what changes because of that: the surfaces of an in-car interface and what belongs on each, the HMI patterns that hold up on the road, how voice and accessibility fit in, and the research methods automotive UX teams use to measure whether a design is safe to use while driving.

Why the driving context changes everything

On a phone or a laptop, the interface is the task. In a car, the task is driving, and every interaction with a screen or a control is a secondary task that borrows attention from it. That borrowing is measurable, and regulators and test bodies have put numbers on it.

The clearest numbers come from the NHTSA Visual-Manual Driver Distraction Guidelines for In-Vehicle Electronic Devices, published in 2013. They recommend that a task done while driving should be completable with single glances away from the road of 2 seconds or less, and with no more than 12 seconds of total eyes-off-road time for the whole task. In the guidelines' test, at least 21 of 24 participants must keep the mean glance at or under 2 seconds and no more than 15 percent of their glances over it.

Those two numbers are the closest thing automotive UX has to a design budget:

• The glance budget. Whatever the driver needs from one look has to be readable in under 2 seconds. A screen that needs a longer look to parse is broken in this context, however good it looks parked.
• The task budget. A task that needs more than about six short glances is too long to do while moving. It needs to be shortened, moved to voice, or locked out until the car stops.

The guidelines also name activities that should not be possible for the driver while the vehicle is moving at all: displaying video or images unrelated to driving, automatically scrolling text, manual text entry for messaging or browsing, and displaying text to read such as web pages, social media posts or text messages.

Two more properties of the driving context matter as much as glance time:

• Interruptibility. A driver will abandon a task mid-way when traffic demands it, sometimes for minutes. An in-car interface has to survive that: no timeouts that throw away progress, no state that only makes sense if the previous screen is still in short-term memory.
• Mental load beyond the eyes. A task can keep the eyes on the road and still take the mind off it. Voice interactions in particular can look safe on a glance metric while raising cognitive demand, which is why the research methods later in this guide measure both.

In-car interfaces: the surfaces and what belongs where

A modern in-car interface is not one screen. It is a set of surfaces that differ in how far they pull the eyes from the road and how they can be operated by touch alone.

• Instrument cluster. Directly behind the wheel, closest to the driver's line of sight. It is the place for driving-critical, glance-only information: speed, warnings, driver-assistance status, the next navigation instruction. It should not ask for input.
• Head-up display (HUD). Projected into or near the windscreen, so the eyes barely leave the road. Its strength is also its constraint: it sits on top of the real scene, so anything shown there competes with traffic. Keep it sparse — speed, the next turn, a critical warning.
• Centre display. The infotainment and settings screen. It is the furthest from the road scene and usually the only surface that needs the driver to reach and look at the same time. That makes it the right home for tasks that are rare, done while parked, or done by a passenger, and the wrong home for anything frequent or urgent.
• Steering-wheel and column controls. Operated without letting go of the wheel and, with practice, without looking. This is where frequent driving-related input belongs: volume, call answer, cruise control, voice activation.
• Physical controls on the dash and console. Buttons, knobs and switches that can be found by touch. Climate, hazard lights and defrost are the classic cases.
• Voice. The only input channel that needs neither eyes nor hands, at the cost of cognitive load and recognition errors.

A useful way to allocate functions across surfaces is to sort them on two axes: how often the driver uses the function while moving, and how bad it is if the driver cannot reach it immediately. Frequent and safety-relevant functions go on controls that work by touch. Information the driver needs at speed goes in the cluster or HUD. Everything else can live in the centre display, behind a lockout if it is long.

HMI patterns that hold up on the road

In automotive work the interface is usually called the HMI, the human–machine interface. The patterns below are the ones that keep coming back in guidelines, test protocols and published distraction studies.

Glanceable layouts and large targets

Design every screen that a driver may look at while moving for a single glance. That means one primary piece of information per region, strong contrast, short labels and no dense lists. Targets need to be large enough to hit while the car is moving over a rough surface, with the hand unsupported. Legibility is not a matter of taste here: ISO 15008 specifies minimum image-quality and legibility requirements for in-vehicle displays used while the vehicle is in motion, including character legibility and colour recognition.

Physical controls for frequent and safety-relevant functions

The industry move to put almost every control on a touchscreen has run into evidence and, now, test protocols. A touchscreen has no fixed position the hand can learn and gives no tactile confirmation, so every touch needs a look. From 2026, Euro NCAP's safety rating assesses the HMI itself, including whether commonly used functions have physical buttons. As the European Transport Safety Council summarises, a top rating now expects dedicated physical controls for core functions such as indicators and hazard lights, the windscreen wipers, the horn and the SOS emergency call.

The pattern for designers: keep a small, stable set of physical controls for things drivers do often or urgently, and give each one a fixed location and haptic feedback. Use the touchscreen for the long tail.

Lockouts while moving

Some tasks cannot be made short enough to do while driving, and the honest answer is to lock them out until the car is stopped. The NHTSA guidelines list the obvious candidates: video, text entry for messaging and browsing, and reading long text. A good lockout does three things: it says why the task is unavailable, it offers the safe alternative (voice, or "available when parked"), and it lets a passenger finish the task where the vehicle can tell who is touching the screen. A bad lockout simply greys the button out and leaves the driver guessing, which tends to produce workarounds such as using a phone instead.

Alert hierarchy

A car can produce dozens of warnings, and if they all sound and look alike, drivers learn to ignore them. Build a hierarchy:

• Critical warnings — imminent collision, a brake failure — interrupt everything, combine sound with a visual cue in the driver's line of sight, and are rare by design.
• Cautions — low tyre pressure, a door ajar at low speed — appear in the cluster without demanding immediate action.
• Information — a service reminder, a software update — waits until the car is parked.

Each level needs its own visual and sound treatment, and lower levels must never borrow the treatment of a higher one.

Driver-assistance status and handover

Driver-assistance features such as adaptive cruise and lane centring shift the HMI's job from "help the driver operate a function" to "make sure the driver knows who is driving". Two patterns matter:

• Unambiguous mode state. The cluster should show at a glance whether a system is active, available but off, or unavailable. Grey-on-grey icons that differ only by a small outline fail this test.
• Clear handover. When the system needs the driver to take over, the request has to escalate — visual, then audible, then haptic — and give the driver enough time to rebuild awareness of the road. A handover request that arrives at the last moment is a design failure even if the system disengages "correctly".

Phone projection: CarPlay and Android Auto

Many drivers prefer to project their phone's interface onto the centre screen. That is not just a matter of preference: a 2019 study by Strayer and colleagues for the AAA Foundation, testing five vehicles on the road, found that CarPlay and Android Auto produced moderate overall demand while the vehicles' native systems produced very high demand. For a manufacturer's own HMI, the lesson is that a familiar, consistent interaction model reduces demand, and that the native system has to coexist well with projection: let the driver switch between them quickly and keep vehicle functions reachable while projection is on.

Navigation guidance

Navigation is one of the most demanding in-car tasks to set up and one of the most valuable to get right while driving. Good guidance is glanceable (the next manoeuvre, distance to it, lane advice), timed to the driver's need rather than to the map, and reinforced by voice so the eyes can stay on the road. Waze, one of the apps in our catalog, is a useful reference for compact turn cards and spoken prompts; more in-car examples are collected under automotive interfaces. Destination entry is the opposite case: it is long, so it should happen by voice, from the phone before departure, or while parked.

Voice and multimodal input in the car

Voice is the obvious answer to the glance budget: it needs no eyes and no hands. It is not free, though. A long voice dialogue holds the driver's working memory, and a recognition error forces a correction loop that often ends in a glance at the screen anyway. The AAA Foundation's 2017 study of 30 model-year-2017 infotainment systems found that none produced low overall demand: 12 produced very high demand, 11 high and 7 moderate. Programming navigation was the most demanding task, and some tasks kept demand high for more than 40 seconds — voice-based interactions included.

The patterns that make in-car voice work are the same ones in our guide to voice user interface design, tightened for the road:

• Short prompts with one decision each. The driver should never have to hold a list of options in memory while merging.
• Confirm only what is costly to undo. Calling the wrong contact needs a confirmation; changing the station does not.
• Multimodal, not voice-only. Show a minimal confirmation in the cluster so the driver can check the result with one short glance instead of listening to a long read-back.
• A dedicated push-to-talk control on the steering wheel, so starting a voice task never requires the screen.

ISO 15005 sets out ergonomic principles for the dialogues between a driver and in-vehicle information and control systems while the vehicle is in motion. It is a good checklist for any voice or multimodal flow.

Accessibility in car systems

Automotive UX has an accessibility problem that is easy to miss, because drivers have to meet licensing standards. Licensing does not mean uniform ability. Drivers age, wear varifocals, have reduced hearing or colour vision, and many passengers who use the centre screen have no licence at all. The AAA Foundation's follow-up research on age-related differences in infotainment demand compared younger and older drivers on the same tasks across six vehicles, and AAA reported the systems as especially distracting for older drivers.

For drivers, accessibility and safety point the same way: larger text, stronger contrast, redundant coding (never colour alone), sound that is not the only channel for a warning, and controls that can be found by touch. Our article on accessibility challenges in car systems covers these in more depth, including where current systems fall short.

Automotive UX research methods

Because the core question is "does this interface take too much attention from driving?", automotive UX research leans more on measurement than most product research does. The main methods, roughly from cheapest to most realistic:

Contextual inquiry with drivers

Ride along and watch how people actually use their vehicle: what they set up before leaving, what they touch while moving, what they avoid, and which workarounds (a phone on a mount, a sticky note on the dash) they have invented. It does not measure distraction, but it is the best way to find out which functions are frequent and which matter, which is the input to every allocation decision above.

Occlusion testing

The occlusion method simulates glances without a car. The participant wears shutter glasses, or looks at a screen that blanks, and can see the interface only in 1.5-second windows separated by 1.5-second blackouts. The total shutter-open time needed to finish a task approximates its total eyes-off-road time. The NHTSA guidelines describe an occlusion test with a 12-second total shutter-open limit. Occlusion is cheap, repeatable and good for comparing design alternatives early.

Glance and eye-tracking measures

In a simulator or on the road, eye tracking records each glance away from the forward scene: its duration, its target and the total time the eyes were off the road. These are the metrics the NHTSA criteria are written in — mean glance duration, the share of glances over 2 seconds and total eyes-off-road time — so eye tracking is the standard way to check a design against them.

Task-completion time against the distraction guidelines

The simplest metric is how long a task takes and how many steps it has. It does not replace glance data, but it is an early warning: a task that takes far longer than 12 seconds of looking at a screen while parked has little chance of meeting the eyes-off-road criterion while driving.

Lane-keeping and secondary-task metrics

Distraction shows up in the driving itself. In a simulator, researchers measure how well the participant keeps the car in its lane (for example, the standard deviation of lateral position), holds speed and following distance, and responds to sudden events, comparing driving with and without the secondary task. A detection-response task — pressing a button when a light or vibration appears — gives a running measure of cognitive load, which matters for voice tasks that look harmless on glance metrics.

Driving simulators vs on-road and naturalistic studies

Simulators make it safe and repeatable to test risky situations, and they allow precise control of traffic and events. Their weakness is realism: people drive differently when crashing has no consequences. On-road studies with an instrumented vehicle — as in the AAA Foundation research cited above — trade some control for real traffic. Naturalistic driving studies go further, instrumenting participants' own cars over months, and show what people actually do rather than what they do while watched. Most programmes combine them: occlusion and simulator studies to compare designs early, on-road studies to validate the chosen one.

FAQ

What is automotive UX? Automotive UX is the user experience design of a vehicle's interfaces — the instrument cluster, centre display, head-up display, physical controls and voice — for a user whose main task is driving. Its defining constraint is attention: every interaction borrows time from watching the road.

What does an automotive UX designer do? They decide which functions belong on which surface, design the in-car interface screens and controls within glance and task budgets, define alert and driver-assistance states, and work with researchers to test designs for distraction in simulators and on the road.

What is automotive UX research? It is user research adapted to the driving task. Beyond interviews and usability tests, it measures distraction: glance duration and total eyes-off-road time with eye tracking, occlusion testing, task-completion time, and driving-performance metrics such as lane keeping in simulator and on-road studies.

What is the difference between HMI and UX in cars? HMI (human–machine interface) refers to the interface itself — screens, controls, sounds and voice. Automotive UX is the wider discipline that designs and evaluates the HMI around the driver's goals, context and safety.

Are touchscreens bad for in-car interfaces? Not as such, but they need a look for every touch. They suit rare tasks, passenger use and tasks done while parked. Frequent and safety-relevant functions are better served by physical controls, a view Euro NCAP's 2026 protocols now reward.