We had the big picture, but we also had a huge knowledge gap: What do developers need from an SDK? What do end-users (drivers) need from the app experience in the car vs. on other touch points? And a million other questions you have, when you start from scratch. We battled ambiguity together as a team, some useful things we did: .

• To gain developer and end-user insights, we conducted developer interviews, secondary research and even early user studies that eliminated quite a few of the complex directions we were excited about.

• We generated a high number of features through design exercises: visualizing sample user flows, app architectures and component behaviors. This provided the variety needed for a meaningful start; and quickly surfaced shortcomings and strengths of directions.

• We rigorously prioritized the MVP experience and feature set. We ran these by early access developer partners, having hard conversations about scope and minimum but lovable user experiences.

discovering need for flexibility & creating a framework around safety

We observed how different global driving conditions and end-user behaviors affected product needs. I advocated to enable flexibility for developers, so they could answer their own unique user and product needs. We built a template/component set and capability framework that supported creation of unique app architecture and user flows.

Biggest challenge was ensuring driver safety while giving developers flexibility. I collaborated with safety and product researchers to generate a driver-distraction framework that was easy to understand and incorporate. MVP version was quite limited, with feedback and further research we iterated on it to keep attracting an increasing set of app categories & developers.

build, test, iterate… with confidence

We started the design phase with high ambiguity in every single area. Early on, I saw that the UX team needed to understand the technical complexity to a degree. This was not a traditional interface design problem. This was a development kit; the APIs and capabilities engineering team was building needed design input as much as the pixels on the user interface. We needed to dive deep and work closely with our engineers.

Technical lead and I constantly enhanced our process as team and product matured. For the most part, we designed in sprints, prototyped via design tools & code (with engineers), and tested in the car with users. We also had weekly sessions with early access partners for continuous insights and feedback on designs/APIs. All this enabled us to explore, design, build and iterate with high confidence.

Expanding to the OS platform

Library enables developers to build a single app and deploy it on multiple car platforms - Android Auto Projected and Android Automotive OS.

User context and needs did not change, even if the underlying technology changed from phone projection to embedded car OS. So, I firmly advocated for enabling single app design across platforms as our next big goal (alongside planned feature development).

• This meant familiar interfaces for end-users, while providing huge efficiency to developers - most with limited resources.

• Car OEMs, new partners, got a fast-growing app ecosystem with minimal effort.

A challenge was the contradicting needs OEMs had. For example, they wanted to customize the app UI for consistency of the infotainment system. However, customization that affected structure and basic functionality of an app was a major risk. I led the team to develop a customization strategy which maintained app user experience intact and got buy-in from the major partners.