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: .

• We generated a high number of features through design exercises. Visualized 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.

• 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 rigorously prioritized the MVP experience and feature set. We ran these by early access partners, had hard conversations about scope and minimum but lovable user experiences.

One of the biggest challenges was ensuring driver safety while giving developers flexibility. I collaborated with safety and product researchers, engineers and PM to generate a driver-distraction framework that was easy to adopt.

We heard feedback that the MVP version was quite limited, especially with the content limitation. Via further research and design, we opened up the limitations slowly and safely, and kept enabling an increasing number of app categories/developers.

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 where the APIs and capabilities engineering team was building needed design input as much as the pixels on the interface. We needed to dive deep and work closely with our engineers.

Technical lead and I constantly optimized 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. All this enabled us to explore, design, build and iterate with high confidence.

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, and huge efficiency for the developers - most with limited resources.

• Car OEMs (manufacturers) got a fast growing app ecosystem with minimal effort.

Some of our new challenges were solving for the contradicting needs car OEMs (manufacturers) had. They wanted to customize the app UI for consistency of the infotainment system. However, customization ideas affecting structure of an app was a risk for the unified library vision and developers. I led the team to develop, and get buy-in, for a customization strategy that focused on the UI layer while leaving app user experience intact and letting OEMs create consistent UI for their customers.