Ford brought ANML in to explore how trip planning, navigation, and ADAS guidance could work together across multiple displays in an assisted-driving concept.
The instrument cluster shows driving data, while the center console handles navigation | Source: ANML
The brief was straightforward. Build something usable.
So what turned out to be the problem?
It wasn't the interface. It wasn't even usability.
It was calibration.
This is the exact same problem anyone designing a product has to face, especially when they have to ask a user to trust a machine's judgment.
Confidence Needs a Measurable Standard
Any high-stakes automation interface runs into the same wall eventually.
Too little signal and drivers ignore help that could genuinely serve them. Too much and they lean on it in situations it was never built to handle.
Getting that balance right matters more than any single screen or interaction pattern.
And if the calibration is incorrect, the function will either remain unused or end up causing the mishap it was designed to prevent.
For example, a driver who doesn't rely on lane guidance enough will override it constantly, defeating the point of building it.
Two Screens, One Signal
The Ford concept split information across two places on purpose.
- The center stack carried the overarching journey.
- The instrument cluster carried situational awareness.
In other words, where we're going versus where we're at.
We built that split around a minimalist 3D rendering style, showing only the information a driver truly needed at each moment and cutting the rest.
Less visual noise meant the split itself did the work of communicating trust, not any single flashy interaction.
And that split only works if the two displays stay in sync. A delay between what the cluster shows and what the center stack says breaks the thing we were trying to build in the first place.
Still, timing, placement, and handoff between screens do more for the driver's confidence than any individual interaction does on its own.
Ford's Senior Director, Sudipto Aich, described the goal as building "driver confidence without being overwhelming."
That phrase captures the whole project better than any spec document we, at ANML, wrote.
What Happens When the System Isn't Sure
Most of the design work on a project like this happens outside the state where everything works. Instead, it happens in the uncertain moments.
What does the interface do when the system isn't sure a lane change is safe? What does it show when sensor data conflicts?
Performing well under ideal conditions proves very little, since that is not where a driver's trust actually gets tested.
The Ford prototype was built around a simulated point-A-to-point-B trip specifically so the team could test those degraded states before any of this reached an actual vehicle.
Lane changes, adjacent vehicles, assisted-driving handoffs. Each one had to communicate exactly what the system knew, not what would look most polished in a demo.
Skip that work, and the interface performs flawlessly in every scenario it was tested against. But it fails silently in a circumstance that a real driver does encounter.
The Same Constraint Shows Up Well Beyond Cars
Anyone designing an interface that asks a person to hand over control runs into this. That includes someone behind a wheel. It also includes someone approving a financial transaction.
Medical devices, financial platforms, and industrial equipment all carry the same requirement.
Each has to signal what the product can do, and where its limits sit, without either message drowning out the other.
Still, most IoT and connected-device design treats that requirement as a visual layer, something solved with icons and color coding after the interaction design is done.
If you approach it that way, the product will either undersell or oversell its own capabilities. And that is precisely the gap that erodes trust when a user requires the system the most.
Design the System Before You Design the Screen
Calibrating confidence takes more than interface work. We design it at the system level now, with engineering involved from the start rather than added once the interaction design is done.
A screen can only communicate what the underlying product knows about its own state.
If that information doesn't exist cleanly at the engineering layer, no amount of UI polish fixes it downstream.
A beautifully designed confidence indicator is still a guess if the system behind it cannot actually measure its own certainty.
The Ford project reinforced something we have carried into every automation interface since.
The interaction pattern is rarely the hard part. Building the discipline to say only what the system actually knows is, and that discipline has to start before a single screen gets designed.
