Back to projects

Automotive UX / Safety-Critical Interaction

Did anyone test this while actually driving?

Overview

A short case study about one incoming call interaction in a Volkswagen T-Cross, likely a 2023 model, and why the UI should change when the car is moving.

2 min read

My role

UX research Automotive UI Interaction design

Timeline

2026

The current interaction uses a small target in the middle of a visually busy infotainment screen.

Project Takeaways

What I explored

How a common infotainment interaction changes when the user is driving instead of sitting still.

What I learned

The issue was not the touchscreen itself. The issue was a tiny decision target in a moment where precision should not be required.

What I'd do next

I would test the design in motion and compare glance time, reach effort, and how quickly the driver can return attention to the road.

Problem framing

Car infotainment systems often inherit mobile UI patterns without fully adapting them to the driving context. That becomes a problem when the driver needs to make a quick decision while the vehicle is moving.

This case focuses on one small interaction: an incoming phone call on the center console screen. The car was a Volkswagen T-Cross, likely around the 2023 model year.

Design question: if the system knows the vehicle is moving, why does the call UI still ask for precise tapping?

Observation

I noticed the issue as a passenger when my father's phone rang. The phone was connected through Bluetooth, so the call appeared on the infotainment screen.

To answer or decline, he had to reach forward and hit a small button accurately while driving. He managed it, but the interaction made the wrong thing difficult: not the decision, but the physical precision required to execute it.

What I ruled out

Voice commands are the obvious answer, but not a complete one. They can fail in noisy environments, require the driver to remember the right phrasing, and still create cognitive load.

Removing touchscreens entirely is not a practical near-term answer either. These systems are already in cars. The better question is how the UI should adapt when the driving context changes.

Solution

When a call arrives and the vehicle is moving, the call UI should take over the main attention area. The caller should be easier to identify, and accept or decline should become large, low-precision targets.

The navigation or media context does not need to disappear completely. It can shrink into a secondary strip while the call is active, then return to the previous layout after the call is answered, declined, or missed.

The proposed version gives the call the priority it needs and makes the action targets easier to hit while driving.
  • Larger caller area: the driver can identify the call with a shorter glance.
  • Larger accept and decline targets: less precision is required while reaching forward.
  • Context-aware priority: the UI changes only when the vehicle is moving and the call needs a decision.

Reflection

Not every design issue needs to wait for a worst-case outcome before it gets fixed. This one is not technically complex. It requires the product team to treat an incoming call while driving as a different context from an incoming call while parked.

The how is straightforward: reduce precision, increase hierarchy, and help the driver return attention to the road faster. The harder part is deciding that this moment deserves priority.