Many discussions about automotive HMI focus on what information should be shown to the driver. I think a more important question is: why should the driver trust the system in the first place?
The answer is simple. Because the driver remains responsible for the vehicle. Even today, most cars on the road operate at Level 2 automation. The vehicle can assist with steering, acceleration, and braking, but the driver is still expected to monitor the environment and take control at any moment. Levels 4 and 5, where the vehicle can fully handle driving without human supervision, are still not part of everyday reality.
— Do you see the vehicle ahead?
— What vehicle?
This creates an interesting challenge. The system wants the driver to trust it. At the same time, the driver knows the system is not perfect. Traffic sign recognition misses signs. Maps become outdated. Sensors are affected by weather, lighting, dirt, and countless edge cases. That is why trust cannot be built through promises. It must be built through transparency.
Not every HUD element is equally valuable. A HUD should only display information that provides a clear benefit to the driver. A speedometer is a good example. It helps the driver understand their current speed and stay within legal limits.
In theory, if a vehicle could determine the correct speed limit with 100% accuracy under all conditions, we might not need a speedometer at all. The interface could become much more intuitive. Video games have explored this idea for years. Think about a character diving underwater in GTA. Most players do not constantly monitor numbers to understand when the character is running out of oxygen. Instead, the game communicates danger through visual effects, sound, and changes in the environment. The player intuitively understands that action is required and it is time to surface.
A vehicle could theoretically do something similar. Instead of showing numbers, it could simply communicate whether the current speed is appropriate or whether the driver should slow down. The problem is that real-world systems are not perfect. Traffic sign recognition does not detect every sign. Map data becomes outdated. Temporary roadworks appear. Edge cases exist everywhere.
As long as the system cannot determine the correct speed limit with complete confidence, the driver still needs access to the underlying information. The speedometer remains visible not because it is the ideal interface, but because it allows the driver to verify the system’s interpretation and maintain a sense of control.
Trust is not created when a system hides complexity. Trust is created when a system helps people understand its limitations.
Let’s take Adaptive Cruise Control as an example. Imagine the driver activates ACC and starts following another vehicle. A simple question immediately appears: does the system actually see the car in front of me? How should the driver decide whether to intervene or allow the system to handle the situation?
Humans naturally transfer their understanding of trust from other people to machines. Imagine sitting in a passenger seat. You ask the driver: “Do you see the vehicle ahead?” If they answer confidently and react smoothly, you relax. If they brake at the last possible moment, your trust disappears. If they answer, “What vehicle?”, you become nervous instantly.
The vehicle must answer the same questions, not with words, but through behavior and interface design. It must communicate: “I see the object.” And just as importantly: “I am already responding to it.”
In one HUD project, we had access to the relative position of the vehicle ahead. Within the limits of the available ADAS data, we could highlight the detected vehicle directly in the driver’s line of sight. The message was simple: “Don’t worry. I see it too.”
But this introduces another important design question. What happens when the system fails? The answer should be obvious. If the system no longer detects the vehicle, the highlight disappears. The interface is effectively telling the driver: “I don’t see it anymore.”
And that uncertainty becomes valuable information. The driver understands that they may need to take over.
“No highlight means no pedestrian.”
This is where many concepts become dangerous. I often see examples where pedestrians are highlighted at crosswalks. At first glance, it looks helpful. But what happens after months of use? The driver starts associating the highlight with the existence of a pedestrian. Eventually, the absence of the highlight be comes a signal too: “No highlight means no pedestrian.”
Until one day the system misses someone. The pedestrian is there. The highlight is not. And the driver has already stopped actively searching because the system has trained them not to.
This is the question I always ask when evaluating any new indication: what happens if the system does not display it? And what happens if the system should display it but fails? If the answer creates dangerous driver behavior, the concept needs to be reconsidered.
That is why I ask three questions whenever designing a safety-critical interface:
- How does the system earn the user’s trust?
- What information helps the user feel in control?
- What happens if the user becomes dependent on the indication and the indication fails?
Sometimes the most important design decision is not what to show. It is deciding what should never become a source of trust in the first place.
Author
Alexey Dmitriev