1. Defining an ambiguous scope and validating our strategy with developers

The needs and end goals were clear. However, where to start and how to scope the problem was highly ambiguous. Our trio (product manager, product designer and technical lead) collaborated very tightly during the definition phase, lots of drawings and debating. 

I audited the targeted app categories to understand the breath of user needs and features. I created user flows i predicted potential apps may create. During the audit, I observed a high amount of common patterns between mobile apps in categories we targeted. Developed an initial set of templates which we iterated on it as we learned more.

However, there was still a high number of UI patterns, My product manager and I worked with early access partners to bounce ideas off, ideate on what is a blocker or not, and incorporate their early feedback into designs. This tight collaboration enabled us get deep insights on developer and end-user needs. We still had many hard conversations internally to cut down on scope, with the intention to build only the essential meaningful set of features, and build them really well.

For v1.0 we ended up with 9 templates, since then we added 2 more for v1.1.

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

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

1. Create a highly prescriptive set of templates that gave developers less flexibility, this may have created higher quality apps as the end user experience would be guaranteed,

2. Create a UI toolkit that gave developers high flexibility to create any pattern they need, this may have created lower quality apps as the end user experience would be highly variable with no guarantees.

Seeing pro/cons of each, I proposed a middle ground approach: Create a set of templates, each with a flexible set of rules that would let developers pick and choose what and how many UI elements they want on the screen. 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, so that we could move fast.

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

• We were able to create a driver distraction framework with our safety team, as the bounds of the experience a developer may create was known and could be evaluated (next highlight).

As library was adopted by developers, we got a lot of praise on its efficiency and ease of development. And, we have a growing number of major apps from all around the globe built on it. ADD NUMBER.

One important part of this exercise was designing components. Generalizing components while enabling flexibility for app requirements and needs was a hard problem to solve.

Here on routing card, an app could create a card in many different ways, mostly to mimic their mobile app architecture. When trying to generalize, i depended on user needs while driving and most common use cases. For example, we knew from research that users first and foremost looked for the most immediate step for directions. I placed that information as the first section. Some apps did not have lane guidance as a feature and it was not a must-have for users depending on app they favored. But it was relevant for the current step, I placed it right under current step and we made it optional.

3. building a safety framework for a flexible system

Following the principle of letting apps own their apps’ UX, we wanted to enable them to create their own app architecture and user flows. Which meant a example, an app landing page could be created via any template. Shown below is list, place list and navigation templates all used for a landing view sample. Furthermore, same task flow could be constructed with entirely different templates in two apps.

This flexibility came with a high price, we could not know where a user task started or ended. The pre-defined task flows has traditionally been how safety tests are done. Our new needs meant we had to explore new ways to create safe apps. Plus, our main goal was to ensure that all apps using the library were safety optimized, no work for developers or auto team to test/evaluate.

——-

Even then we still struggled with opening up the rules to be too flexible. For example, we wanted to let apps add actions on our action strip component. We wanted to know what types tasks

Defined a generalizable UX-restriction framework in collboration with another designer, enginner and safetu expert. To ensure apps were Driver Distraction optimized but flexible enough for partners to design meaningful experiences for their users.

——— We had a gizzillion questions. I partnered with researchers to collect existing knowledge from internal teams. Identified where we had major knowledge gaps to shape studies.

Did a quick secondary research technical lead to where to start, who to work with, what templates were needed…

Defined a generalizable UX-restriction framework to ensure that apps were Driver Distraction optimized, yet flexible enough for developers to design meaningful experiences for their users.

research - simulator and in-car research, secondary research

worked closely with safety experts

all that worked meant that developers do not need to think about safety.

result, developers have an enforced set of rules that are simple enough to understand. team constantly evolves these base don backlog of feedback.

developers are abstracted form it because they do not have to be experts in safety to develop apps in the car.

impact and developer feedback

efficient to develop. easy to use

cover many usecases…

200+ apps, with steady growth

2,5 million monthly active users. ???

What’s next?

1. aaos :) see IO talk at

Announced at Google I/O by my product manager and me, Car app library coming over to Android Automotive OS.

I advocated for a unified foundational design across in the library across platforms. User and developers needs rarely differ in car interfaces according to platform. With this vision, developer/designers can create a single car app design and deploy it across platforms.

2. enhance enhance enhance

we have a healthy backlog of features from developers and oems, prioritize and keep developing for needs