1. starting in ambiguity, and validating ideas early

The needs and end goals were clear. 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.

We saw two distinct directions for how to approach the UX, and the team was split on it:

1. Create a set of templates and flows that are highly prescriptive and could only be used for certain use cases. Pros were: Known scope, that we could test for safety, and the defined end user experiences apps could create. Cons were: Giving developers less flexibility and the risk of a too narrow and strict library.

2. Create a UI toolkit that enable developers to create any pattern and flow they need. Pro was: High level of flexibility for developers. Cons were: Potential for lower quality end user experiences, harder to understand/test potential distraction, and potential to be creating more work for developers.

I audited mobile apps from the 3 categories we decided to target, to understand the breath of user needs and features. Created sample architecture and user flows for potential app experiences. During the audit, I observed a high number of common patterns between apps in all categories. Using that knowledge, I proposed an alternate approach: 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 rules 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.

• It meant less work for developers as they’d not need to start from scratch.

• 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 for each template. Then, we 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

When we ran designs by partners from different parts of the world, we often realized how the different driving conditions and user behaviors affected the app needs and experiences. All throughout design & development phases, we strived to enable as much flexibility for developers as we could.

One important part of the design exercise was designing components. Generalizing components for a variety of apps while enabling enough flexibility was challenging to say the least.

Above are examples of how an app could architect the information hierarchy of routing card in different ways. When generalizing this component, I depended on balancing user needs and use cases from developers. From research we knew that users first and foremost looked for the immediate step (distance and road/exit name). This seemed to be the most common implementation by developers as well. I placed that information as the first section. Some apps did not have lane guidance but when present, it was relevant to the current step.I made it the second section while keeping it optional.

As we got feedback from developers, we learned about various needs we needed to incorporate into the design. Some examples how the components design evolved:

• In Korea and Japan, drivers needed to see large images on complex junctions. I proposed to add this as an option (complex lane guidance) that could be used instead of the simple lane guidance when needed.

• My initial understanding of component sections was correct but the rules around what information is necessary needed some improvement. We loosened up minimal information needs as needed, even making the component itself optional.

The design process took multiple iterations to get all the variations and rules right. In the end, my initial designs evolved with our tight partnerships and teams’ fast iterations. Resulting in a component that developers use for the most core task in the car, getting clear directions.

3. building a safety framework for a flexible system

We wanted to enable developers to create their own app architecture and user flows using the templates. Which 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. The pre-defined task flows have been the best way to test for driving distraction on auto.

I collaborated with safety researchers and other team members to explore various models for a generalizable UX-restriction framework, as library had no way of knowing how exactly tasks would be implemented by developers .

After trying multiple models, we decided on a constrained system that was designed to be compliant around the world, that we could build, validate and open up as we learned.

I worked with partners to understand if primary and secondary tasks could be built successfully. Even if it was easy to build, this framework had to enable meaningful car app experiences first and foremost. Once developers saw the benefits of making flows shorter for drivers, they easily made most the tasks work within the bounds of the framework.

This framework worked fairly well for the first release; all developers successfully built on the library. However, it resulted in too-constrained experiences where users could not access as much content as they needed to even when parked. As it was built to be iterated, team is currently ideating and researching new features.

impact and developer feedback

There are currently 200+ apps built with the library. By enabling a set of global developers, we see user growth in certain countries where we used to have little presence in. And, we get a steady growth without active outreach to developers.

Developer feedback has also been extremely 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 for Android Automotive OS. Bringing the growing car app ecosystem to all car platforms.

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