automotive
Why "Intuitive" Is the Wrong Goal
The word feels like a compliment. It isn't a design brief.
There is a word that appears in nearly every product requirement, every design review, every usability report in the vehicle experience space.
Intuitive.
We use it as a destination. Make it intuitive. We use it as a verdict. This is not intuitive. We use it as a brief. The driver should just know.
The problem is that "intuitive" describes a feeling. It doesn't describe a condition. And when you use a feeling as a design target, you give the team no way to know when they've hit it — or what to do when they haven't.
What We Actually Mean
When a driver calls something intuitive, they're reporting that they never had to think about it. The system kept them in automatic. What made that possible wasn't simplicity — it was the presence of specific conditions that kept deliberate effort off the table. Those conditions can be named. "Intuitive" can't be designed. The conditions that produce it can.
When someone calls an interface intuitive, they usually mean one of three things:
It matched what they expected. They didn't have to learn it — the system behaved the way they assumed it would before they touched it. That's familiarity. It's a real condition, and it can be designed.
It responded immediately and legibly. They acted, and the system answered in kind — fast, unambiguous, without requiring interpretation. That's responsiveness. Also real. Also designable.
It supported their next action without asking them to think about it. They were doing something else — driving — and the system delivered what they needed at the moment they needed it, without cost. That's the whole brief. And it has a name: confidence.
"Intuitive" is a container that holds all three of these. It's what the driver says when those conditions were met without noticing. The problem isn't the word. The problem is using it as a specification rather than a report.
Why It Matters for Connected Systems
Connected vehicle technology adds a layer that changes the brief significantly.
The promise of connectivity is that the vehicle knows more. More about the road, more about the driver's context, more about what the next moment requires. The experience implication — the one that rarely makes it into the data requirements — is that knowing more creates more opportunities to ask more. To surface information. To prompt action. To deliver what the driver didn't know to request.
Each one of those opportunities is also an opportunity to interrupt.
A system that knows a great deal and shares it at the wrong moment is not intuitive. It is demanding. It is asking the driver to receive, interpret, and decide — at the exact moment that attention belongs to the road. The data was right. The delivery was wrong. And the driver's experience of that moment will not be described as intuitive.
This is where the design brief has to go further than "intuitive." The question isn't whether the information is relevant. It's whether the moment the driver is in — the cognitive state, the road condition, the demand already placed on them — makes this the moment to receive it.
The Driver's State Is the Brief
There are two conditions a driver moves through on any given trip.
Solve state The driver needs to solve something specific. Navigation, a system query, a decision that requires the vehicle's input. They are actively using the system. What they need is clarity: the next correct action made legible, fast, without interpretation required. A system that delivers this produces what drivers call intuitive. What it actually produced is dependable, responsive access to a legible next step.
Manage state The driver is managing what they have. They are in the road — monitoring, adjusting, holding their place in a complex environment. They are not using the system. What they need from the vehicle is silence, or near-silence. A system that interrupts this state — even with relevant, useful, correctly delivered information — is not intuitive. It is asking more than the moment allows.
The system that reads both states correctly, that offers clarity when the driver needs to solve and stays quiet when the driver needs to manage, produces confident action. Drivers will call it intuitive. What it actually is: a system that never asks more than the driver's current state can absorb.
That's the brief.
The driver who never noticed the system — that's the success metric. Not the one who said it was intuitive. The one who had nothing to report.
A Word Worth Retiring (From the Design Process, Not the Review)
"Intuitive" is a perfectly accurate word for what a driver feels when a system got it right. Keep it in the usability report. Keep it in the customer verbatim. Let drivers use it freely — it tells you something real when it appears.
Remove it from the design brief.
Replace it with the conditions it describes. Where does the driver need the next action to be immediate and unambiguous? Where does the driver need the system to stay invisible? What does the vehicle know about the driver's current state, and is that knowledge shaping when the system speaks?
Those questions can be answered. They point at things that can be measured, evaluated, and improved. They give the team something to aim at that isn't a feeling.
"Intuitive" is the goal the driver reports after the fact. Confident action is the condition that produces it.