1. starting in ambiguity & building a scalable foundation

Goals were identified, but where to start and how to scope the problem was highly ambiguous. There was no prior examples for parking and charging apps on car platforms; and only a single developer SDK in the market.

Team dove right into prototyping and explorations, but instantly struggled with lack of a clear UX strategy and first set of capabilities to build. We needed to better understand the breadth of user needs and app features for the initial categories. And very importantly, needed to establish a design foundation that could expand to more developers and multiple platforms.

To set a clear design and product vision, I led the team to do several exercises: audit mobile and native car apps in the market, conduct secondary research to gather knowledge from internal teams, create prototypes to use in cars and generate multiple directions for library design capabilities. These exercises quickly educated us and resulted in informed hypothesis.

During this phase and especially with audits, I observed a number of common UI patterns and components between all apps. Which instantly eliminated too-flexible and too-wide directions, guiding us to the final idea: Create a set of UI templates that contain a set of flexible (yet restricted within guide rails) components and content rules.

Once we had a clear strategy, we needed to validate and get the scope right. Idea was to start small and open up as needed.

After developing an initial set of capabilities, we started working with early access partners. We were constantly getting feedback and iterating designs (and APIs) as they built with early library. I led this tight collaboration process as the main design contact. Which provided deep insights on developer and end-user needs, enabled fast problem solving, and got us to make hard decisions efficiently to get to the first set of features. All with an eye on the goal of ecosystem scalability.

Library recently got released on Automotive OS platform (beta) and added support for multiple new categories (all POI apps and coming soon Rideshare apps) with minimal effort. Showing how I helped envision and build a product foundation that can be deployed on multiple platforms, and easily supports a growing ecosystem of app categories.

2. Design for flexibility that meet global end-user and developer needs

While working with partners, we observed how different global driving conditions and user behaviors affected product needs. We strived to enable as much flexibility for developers as possible, so they could answer their own unique user and product needs.

From early on, I advocated to enable developers to create their own app architecture and user flows. To allow this, we had to design to support capabilities such as:

1. Any template could be used for the start or end of a task: Started with a restricted set that made sense based on initial explorations. After discussion with developers and further explorations, we opened this up and enabled any UI template to be a starting point. This resulted in a healthy variety in app experiences and answered variety of use cases we have not even considered initially.

2. Same task could be designed via different template sequences: Conducted several studies to support this idea which ultimately gave developers immense freedom to create their unique user flows.

3. Developers could pick any component to create app navigation structures: Started with allowing and designing a small set of patterns to be used as app navigation (lists and grids). Testing led us to understand this was not essential to constrain. Furthermore, it was extremely difficult to enforce in code. We ended up making recommendations for best practices, but leaving it up to developers to leverage several different components as needed.

While building for flexibility, we also had to consider global driver safety guidelines. As driving is always the primary task for drivers. I worked closely with researchers and engineers to create a generalizable safety framework that was embodied in the SDK. As a result, we empowered developers to create car apps without being driver distraction experts.

As our goal was to start small, design process was an exercise in finding the sweet spot to provide just enough flexibility - especially for first release. Decisions needed to consider safety, scope, quality of the end experience, and equally importantly usability of the SDK (content rule enforcements in code, APIs etc.). We achieved making these hard decisions in a fast-pace fashion by creating an open, collaborative and agile team culture & process.

impact

Fast growth: 

• 400+ apps, 4.5 m MAU. These numbers grow weekly.

• Increased Android Auto usage in multiple countries where we previously had small or no market share (Korea, Brazil, North Europe etc.).

Positive developer feedback, apps built in a matter of days. Signaling success in creating an efficient and simple way to build car apps.

Launched on Automotive OS platform with minimal effort.

Opened up to all POI apps (fueling, restaurant finding etc.). Ride share category coming soon.