1. starting in ambiguity, and validating ideas early

The needs and end goals were known. But, where to start and how to scope the problem was 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 with the direction to take for developing the library capabilities. To understand the breadth of user needs and app features, I audited mobile apps from the 3 categories. Created prototypes of sample architecture and user flows for in-car apps.

I observed a number of common UI patterns and components between all experiences. Using that knowledge, I collaborated with my team to develop the final direction:

Create a set of templates with enough flexibility to let developers pick & choose which component they want. Idea was to start here and open up the capabilities as needed. This approach meant we had a finite set of UI features to build (fast) that were based on known user needs and tasks.

From there on, we developed an initial set of templates and component rules. I worked with early access partners to get their input via weekly meetings. This tight collaboration enabled us to get deep insights on developer and end-user needs, constantly validate our hypothesis and iterate fast.

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

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

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 was components. Generalizing components for a variety of apps, while enabling enough flexibility was challenging. I depended on balancing user and developer needs to come up with the information hierarchy and rules.

For example on routing card, there were several viable layout options. Research showed that users primarily needed the immediate step (distance and road/exit name). This was also the most common implementation by developers. We learned that lane guidance was only important in some countries and to some developers/users. I designed the component to feature immediate step as the first and mandatory section; and lane guidance as the second and optional section.

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

impact

There are currently 200+ apps built with the library. By enabling a set of global developers, we observe user growth in various countries where Android Auto used to have small market share in.

Developer feedback have also been very positive. Partners reported building apps with very little handholding, 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 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.