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 touchpoints? And a million other questions to have, when you start from scratch. We battled ambiguity as a team: 

• We generated a high number of features through design exercises. Visualized sample user flows, app architectures, and component behaviors. This approach provided us with a variety of ideas to start; also quickly surfaced shortcomings and strengths.

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

• We rigorously prioritized the MVP experience and feature set to its core. We ran it by early access partners and had hard conversations about scope and minimum but lovable user experiences.

We observed how different global driving conditions and end-user behaviors affected product needs. I advocated enabling flexibility for developers to empower them to answer their unique user and product needs. We built a framework with templates, components, and capabilities that support the creation of unique app architecture, branding, and user flows.

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 our first driver-distraction framework. The main goal was to make it easy for developers to adopt, yet it had to be minimal enough to build.

We heard feedback that the MVP version was quite limited, especially around the content limitations. Conducting further research and design, we opened up the framework slowly but safely. It helped enable an increasing number of app categories and developers.  

We started the design phase with high ambiguity in every single area. Early on, I saw that as a UX team we needed to understand the technical complexity to a degree. This was not a traditional interface design problem. This was a development kit; APIs and capabilities the 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.  

The technical lead and I constantly optimized our process as the 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 to gain continuous insights and feedback. All this enabled us to explore, design, build and iterate with high confidence. 

The 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 when the underlying technology of the car platform changed. So, I firmly advocated enabling single app design across platforms as our next significant goal (alongside planned features). This meant: 

• Efficiency for developers with limited resources. 

• A fast-growing app ecosystem for car manufacturers with minimal effort.

In this phase, we had to solve for contradicting needs of car manufacturers. They wanted to customize the apps for consistency of the overall infotainment system. However, customization that affect the structure of an app was a risk for the developers using the unified library. I led the team to develop and get buy-in for a strategy focusing on the UI layer while leaving the app user experience intact. 

Increased Android Auto usage, and app ecosystem growth: 

• Within the first few months of the public release, we got 400+ apps published.

• Increased usage in several countries where we previously had a small market share (Korea, Brazil, North Europe, etc.).

SDK efficiency and clear developer design guidance: Extremely positive developer feedback. Apps are built in a matter of days. 

A solid design strategy that set a scalable foundation for growth: 

• Launched on Automotive OS platform with minimal design/engineering effort.

• Able to add IoT category instantly and open up to all POI apps (fueling, restaurant search, etc.) rapidly. The rideshare category was announced.