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 art for the 2 brand new app categories: Parking and charging. And very few for the navigation apps. For UX, we saw two distinct directions and we were divided on it:

1. Create a set of templates and app flows that are highly prescriptive. Pros: A well defined scope of experiences that we could test for safety, and potentially higher quality app experiences. Cons: Giving developers less flexibility, and risk of creating a too narrow and strict library.

2. Create a UI toolkit that enable developers to create any UI pattern and app flow they need. Pro: High level of flexibility for developers. Cons: Potential for lower quality end user experiences, harder to understand and test for safety, and more work for developers to start from scratch.

To understand the breath of user needs and features, I audited mobile apps from the 3 categories. I created sample app architecture and user flows. During the audit, I observed a high number of common patterns between apps in all categories. Using that knowledge, I collaborated with my team to develop the final direction we took:

Create a set of templates with enough flexibility to let developers pick & choose which component or UI elements 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. And, we could create a driver distraction framework as the bounds of the experience developers may create was known enough to be evaluated.

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

During our collaboration with early access partners, we observed how different driving conditions and user behaviors across the globe affected their product needs. All throughout the design & development phases, we strived to enable as much flexibility for developers as we could so they could answer their user and product needs.

Understanding the variety of needs, I made sure one of our main design goals was enabling 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. I worked closely with developers and safety experts to make this flexible framework a reality.

Another important part of the design exercise was designing components. Generalizing components for a variety of apps, while enabling just enough flexibility was challenging. I depended on balancing user and developer needs to come up with information hierarchy.

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 certain countries where Auto used to have little presence in.

Developer feedback has 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.