Overview
TomTom Digital Cockpit platform enabled carmakers, system integrators, and digital service providers to design, build, and run in‑vehicle experiences on a shared, secure foundation.
Instead of building a new infotainment system for every car line, the platform allows services to be built once and scaled across multiple brands and vehicles—while giving carmakers full control over UX, safety, and customization.
Instead of building a new infotainment system for every car line, the platform allows services to be built once and scaled across multiple brands and vehicles—while giving carmakers full control over UX, safety, and customization.
The UX Strategy was to create a seamless and engaging in-car user experience with a voice-first approach, integrating users’ digital lives and ensuring a comprehensive cockpit experience centered on safety. This encompassed everything from the Infotainment system to the Cluster Display and passenger interfaces. It involved the system UI Framework, Notifications, System feedback & Acknowledgments, as well as multimodal interactions like Voice, Focus UI, and touch. We designed key domain applications, including Navigation, Entertainment, Communication, Settings & Personalization, and Climate controls.
The challenges
Here's some background on the user-facing issues in the automotive industry.
Digital cockpits often fall short in user experience: content isn’t always up to date, and vehicles quickly become outdated. Despite OEM efforts—adding more screens and interactive services—current HMIs are still outperformed by smartphones.
Drivers and passengers struggle to integrate their digital lives into the cockpit in a safe and comfortable way, as the cockpit isn’t connected to their broader digital ecosystem. Usually, the ecosystem inside and outside the car are disconnected, resulting in an unfamiliar user experience and a lack of digital continuity.
Although OEMs are introducing innovative safety features, road fatalities are increasing due to driver distraction from smartphones. This problem is compounded by the fact that owners of vehicles with advanced safety systems often switch them off because they don’t trust the systems or find them too intrusive.
The challenge wasn’t designing another in‑car experience.
How do you design a reference digital cockpit platform for OEMs—one flexible enough to be customized per brand, but opinionated enough to set a strong UX direction from day one?
How do you design a reference digital cockpit platform for OEMs—one flexible enough to be customized per brand, but opinionated enough to set a strong UX direction from day one?
My role
My role at TomTom was divided into three distinct areas, requiring careful balancing to ensure success and impact throughout the project. Initially, I served as a Lead UX Designer, contributing directly alongside the team.
As the team expanded, I shifted my focus to creative leadership, where I defined strategies, explored new opportunity areas, and engaged with business leads. I managed a team of designers—including specialists in interaction, visual design, voice, and research—providing guidance, inspiration, and coaching.
Additionally, I was part of the TomTom UX management team, helping to improve processes and oversee talent acquisition.
This project began entirely from scratch.
Founded the design team, clarified our core values and workflows, defined processes, and promoted collaboration across all stakeholders—including product managers, developers, marketing, and sales. Established the vision, strategy, and design principles. Designed, developed, and launched the initial MVP. I’d love to say it all began with a sketch, but that wasn't the case. We began with a human-centered approach.
A good foundation: The UX framework
The first six months were all about the foundation —the UX framework. After setting our Design principles, we aimed to translate the Vision and UX objectives into concrete Design concepts. During the first six months, we designed, tested, and iterated extensively.
Our goal was to create a System that is user-friendly, provides drivers with relevant information, delights users through fluid and seamless interactions, and adapts to various screen sizes and orientations.
We incorporated additional iterative feedback from user testing and drive testing. This was crucial for evaluating the product's usability and safety while driving—something very difficult to verify from a desk. I won’t delve into all our research methodologies and processes, but I can highlight the approach used in designing the UX framework.
The Experience
TomTom Digital Cockpit brings order to a traditionally fragmented cockpit,
A flexible UX framework leveraging modular, customizable components to support scalability, reduce design debt, and empower teams to deliver cohesive yet adaptable user experiences.
A unified, holistic system
Vehicle feedback, infotainment, navigation, communication, productivity, and ADAS are designed to coexist—not fight for attention. Each app understands its role within the larger system.
Multi‑modal interaction by default
Users can interact via touch, hardware controls, or voice—depending on context. IndiGO integrates out‑of‑the‑box with personal assistants like Alexa and Cerence, and carmakers can extend them with custom skills that connect directly to vehicle functions.
Platform, not just product
IndiGO allows third‑party services to be developed, tested, and demoed in a fully working infotainment environment—without building a custom IVI system just to show value.
Build once, scale across brands and vehicles.
Internal Stakeholder Tensions & Constraints
As we transitioned from building a standalone infotainment system to designing a true platform‑based digital cockpit, new tensions emerged—some expected, some surprising. Very quickly we realized that the shift from product to platform required a fundamentally different mindset, not just in engineering but across UX, product, and our conversations with automakers.
The UX vs. Engineering Negotiation
Internally, the biggest friction point stemmed from our dual mandate: Engineering needed to focus on APIs, documentation, modularity, and enabling third‑party services. UX needed to explore, define, and demonstrate what great in‑car experiences could look like.
The Digital Cockpit couldn’t succeed without a robust, well‑architected platform—but without a reference HMI, automakers couldn’t truly understand its potential. So the question became: How much UX is “just enough” to inspire OEMs without over‑prescribing or boxing them in?
This created a constant negotiation cycle: If we invested too heavily in defining UI and interaction patterns, engineering struggled to keep pace with platform foundation work.
If we leaned too heavily toward APIs and documentation, our customers—automotive HMI teams—couldn’t visualize the experience or evaluate driver usability.
If we leaned too heavily toward APIs and documentation, our customers—automotive HMI teams—couldn’t visualize the experience or evaluate driver usability.
Every milestone forced new trade‑offs. We had to build the platform and simultaneously express the platform through a coherent, opinionated UX—knowing that most OEMs would eventually customize or replace large parts of it. Balancing these two forces became a core part of my role.
The Dual-Customer Challenge
One of the most unique challenges we faced was operating with two different types of customers, each with their own needs and expectations. On one side, our direct customers were automakers and their HMI teams—UX designers, researchers, and engineers who needed flexibility, ownership, and deep customization. On the other, we had the end customer: the driver, whose needs were centered around safety, usability while driving, and a frictionless in‑car experience.
Rather than conflicting with each other, these perspectives simply required different types of learning and different modes of thinking. We had to constantly shift between understanding how OEM HMI teams evaluate tools and platforms, and understanding how real drivers behave, perceive risk, and interact with a cockpit under real‑world driving constraints.
This dual focus meant that every discovery cycle was doubled: we interviewed OEM teams to understand workflows, customization expectations, and system integration processes; and in parallel, we observed and tested with drivers to ensure the cockpit experience was intuitive, safe, and responsive behind the wheel.
The tension wasn’t between drivers and OEMs—it was in our own need to serve both effectively, without over‑optimizing for one at the expense of the other. This led us to expand our deliverables beyond screens and patterns into experience‑level guidance, component‑level customization documentation, clear definitions of what the platform allowed vs. what OEMs could freely adapt
This balance—deep driver insight on one side, and deep OEM support on the other—became essential to demonstrating the value of the platform while still enabling carmakers to build their own branded, differentiated experiences.
What we achieved
TomTom Digital Cockpit enabled carmakers to ship high‑quality digital cockpits faster, with less risk and lower cost, while retaining full ownership and control over their software.
By providing a strong, opinionated reference platform, IndiGO gives OEMs a clear UX starting point that already addresses real driver needs—safety, clarity, and continuity—while still allowing deep customization and brand differentiation.
At the same time, drivers benefit from a more intuitive, less distracting in‑car experience, and digital service providers gain a scalable path to market with realistic testing and demo capabilities.
The result is a sustainable ecosystem that balances user trust, OEM flexibility, and platform scalability.
But Why It Ultimately Failed
After three years of validation, co‑design sessions, on‑site workshops with automakers HMI teams, and extensive road‑testing with engineering partners, we uncovered a hard truth: Large automakers valued modularity and scalability, but they valued design ownership even more.
Companies like Stellantis and Volkswagen appreciated the platform—but the more we showcased the UX, the clearer it became:
No matter how flexible the system was, it was never flexible enough.
Automotive HMI teams wanted control not only over theming, layouts, component configuration …but also over interaction models, flows, transitions, and system‑level behaviors.
Even when we offered wide‑ranging customization—feature toggling, modular layouts, support for different screen sizes, multimodal interaction, theming layers—large OEMs still felt constrained by the reference implementation. They wanted to start with their own vision, not ours.
Meanwhile, smaller OEMs—premium, niche, or low‑volume manufacturers—were excited about IndiGO. For them, a fully working, customizable digital cockpit that could be deployed quickly was a breakthrough. But these customers represented low commercial volume, and ultimately couldn’t justify the ongoing investment required to maintain a full digital cockpit platform at TomTom scale.
In the end, the tension was structural:
• Large OEMs want maximum flexibility → The platform felt too prescriptive.
• Small OEMs want speed and turnkey solutions → The platform was perfect, but volume was too small.
Maintaining a customizable, vehicle‑grade cockpit platform is extremely costly.
This mismatch between customer needs, market economics, and platform overhead is what limited the long‑term viability of the product.