1. starting in ambiguity, and validating ideas early

The needs and goals were somewhat known. But, where to start and how to scope the problem was highly ambiguous. There was no prior examples for the 2 new app categories, parking and charging. And very few for the navigation category.

We were struggling to find the right direction for library capabilities. To be able to make an informed decision, we needed to better understand the breadth of user needs and app features.

I audited various apps; created prototypes of sample architecture and user flows. During this exercise, I observed a number of shared UI patterns and components between all apps. Using that knowledge, I collaborated with my team to develop the final direction: Create a set of templates, that contain a set of components and flexible enough capabilities.

Idea was to start small and open up capabilities as needed. This approach helped us scope and build fast, to start learning and iterating.

From there on, we developed an initial set of templates. We also started working with early access partners to get their input via frequent meetings. We were constantly asking questions, validating our hypothesis and changing direction as needed.

This tight collaboration gave us deep insights about end-user needs, enabling us to design and build the right set of features. I was the main design point of contact with partner developers.

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

While working with early access 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. This meant that any template could be used for the start or end of a task; and the same task could be designed via different template sequences. This approach came with its own unique challenges, especially for safety. I worked closely with engineers and safety experts 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.

Another important part of the design process was components. Generalizing components for a variety of apps, while enabling enough flexibility in capabilities was challenging.

An example component is routing card, which had several viable layout options. Research showed that drivers primarily wanted to see the immediate step (turn icon, distance and road/exit name). This was also the most common implementation by developers. However, we learned that lane guidance and next steps were only important in some countries and to some developers/users. I designed the component to feature immediate step as the first and mandatory section, while making other information optional and secondary/tertiary in the hierarchy. This enabled all navigation apps to use the component as needed.

Design process took multiple cycles to get all the variations and rules right. In the end, initial template and component designs evolved as a result of tight partnerships with developers, and fast iterations, experiments we made as a team.

impact

There are currently 350+ apps built with the library (growing weekly). By enabling a set of global developers, we observe user growth in countries where Android Auto used to have small market presence in.

Developer feedback have also been very positive. Partners reported building apps even in a matter of days. Signaling our success in creating an efficient and simple way to build car apps.

What’s next?

Other than the healthy backlog of features we have, at Google I/O 21 we announced that Car app library is soon being enabled on Android Automotive OS. Bringing our growing car app ecosystem to all car platforms.

From early on, I have been advocating for a unified library across all car platforms; as app-related user and developer needs rarely differ. With this strategy, developers can design a single car app and deploy it across platforms. I am currently leading the efforts to make this vision a reality.