How might we build AI experiences that preserve drivers’ trust in their vehicle?
By designing AI that’s personalized to the driver, with an interface that adapts to what’s safe in the moment.
00
Adding AI to a car doesn’t add a feature. It changes what the car is.
The cabin is a highly sensitive system. The driver, the passengers, the road, the instrument cluster, and the media all share the same limited attention. Every attempt at delight comes second to safety.
A car is also permanent in a way most products aren’t. Once you commit to a vehicle, you’re committing to years of daily drives in that experience. Changing your mind isn’t easy, and walking away is expensive. So even the smallest friction compounds over time.
The throughline
The bar for in-car AI is stricter than a chatbot. It can’t compromise safety or driver control—it can only operate within those boundaries.
01
Defining the boundaries of adaptation
It started with a design sprint whose brief asked how the car should adapt to passengers. The designers came back with lots of ideas, like making road trips more fun or traveling with pets easier.
I took a step back. We were coming up with features before understanding what drivers would allow the car to change. An idea could sound helpful and still cross a boundary. We needed to understand where adaptation was consistently welcome, where it depended on the situation, and where it wasn’t welcome at all. Then we could design features within those boundaries.
I built a framework to map those boundaries, and led the designers in creating concepts that tested real scenarios against it.
Scroll sideways, or click to see the full tree
02
AI has to strengthen the car’s rules, not change them
What I found after testing was that drivers accepted adaptation when it met two expectations they already had of the car: keep me safe, and keep me in control of the cabin. When the two conflicted, safety won. These findings are the basis for the model behavior rules I’m now developing independently. Safety sets the boundaries, and the driver stays in control within them.
1Keep me safe
| What drivers showed | Proposed model behavior rule | Example |
|---|---|---|
| Proactive actions: Drivers were most comfortable with the car acting on its own for safety. For anything else, acceptance hinged on understanding why and being able to cancel it easily. | For safety, act without asking, but only if the action is low-risk and easy to undo.
| Trigger: Windshield fogs up.Action: Turns on the defogger.Message: “I’ve turned on the defogger to clear the windshield.”Easy to undo: The driver presses the defogger button they already use. |
| Decision load: What became unsafe was the pile-up of decisions. Drivers were worn down by being asked to decide multiple times in a short window or being given dense, hard-to-parse information while driving. | Give just enough to decide, and let the driver ask for more.
| Request: “Find coffee on my way.”Single choice: “There’s a coffee shop 3 minutes ahead, right on your route. Want to add it?”Driver: “Anything else?”Follow-up: “One more, 6 minutes ahead, with a short detour.” |
2Keep me in control of the cabin
| What drivers showed | Proposed model behavior rule | Example |
|---|---|---|
| Timing: Suggestions were most welcome before departure or as the trip began, before driving felt underway. Those moments felt less like interruptions. | Offer nonessential help before the drive gets underway or at the end of the trip.
| Trigger: Service is due; the drive is ending.Message: “Your car is due for service. Want me to open the service scheduler in the app?” |
| Passenger preferences: Drivers welcomed suggestions based on group needs, like a kids’ station with a child in the back or larger text for an older passenger. Suggestions based on an adult passenger’s taste got mixed reactions. | Lead with group needs. Handle individual taste lightly.
| Accepted (child in the back): “Want to switch to a clean kids’ station?”Mixed (adult friend up front): “Want a shared playlist for the two of you?” |
03
Even if intelligence increases, visibility doesn’t scale with it.
We then brought a live LLM assistant into the car. Across 14 simulator sessions, drivers used it through voice, the center screen, and the instrument cluster. From those sessions, I defined the interface strategy for an in-car assistant like this one.
With free-form language, drivers made more complex requests, but their attention on the road didn’t grow. The assistant was doing more without being able to show more. Drivers needed to know what it was doing and step in when needed, without managing every step.
So every piece of information goes to the lightest channel that works:
- Instrument clusterCritical information and safety actions. The assistant reaches it only through things the car could already do.
- Center screenWhat the driver needs to act on or decide with, plus navigation.
- Not shownWhat the driver can hear, feel, or doesn’t need in order to decide.
A few of the resulting design rules:
04
Putting the rules into an experience
I built two coded prototypes on simulated in-car displays, with spoken audio and captions. Each brought the behavior rules, screen responses, and vehicle state into one interaction.
These prototypes aren’t high-fidelity designs and don’t reflect the OEM’s implementation. They’re built to show the multimodal design rules and how they work together. For high-fidelity design work, see the B2B case study, or ask me.
05
When things go wrong
The first prototype explored three situations requiring different responses: a failed action, unavailable information, and rising driving demand.
06
When the assistant takes more initiative
The second prototype followed one daycare commute through four levels of initiative. The trip stayed the same; the assistant’s permission to act changed.
As autonomy grows, control does not disappear. It moves from commanding each action to supervising a routine.
