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 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. The pros were the known scope for us that we could also test for safety, and very much defined end user experiences. Con was that this gave developers less flexibility and created the risk of too narrow and strict a 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. Con was that this may have created lower quality end user experiences, was much harder to understand/test potential distraction and potentially way more work for developers.

I audited mobile apps from the 3 targeted categories to understand the breath of user needs and features. Created sample architecture user flows for potential apps. During the audit, I observed a high number of common patterns between apps in all 3 categories. using that knowledge, I proposed a middle ground: 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 that were based on known user needs and tasks, which enabled us to move fast.

• It meant less work for developers as they’d not need to start from scratch as they would on a 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).

From there on, I developed an initial set of templates and component rules for each template. Then, the product manager and I worked with early access partners to get their input on this set of designs 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.

—-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.

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

All throughout design & development phases, we strived to create as much flexibility for developers as we could. When we ran designs by partners from north Europe and Korea, we realized how the different driving conditions and user habits truly affected the app experiences. The only sustainable way forward was enabling developers to create what they need for their unique needs. Therefore, flexibility became a priority.

One important part of the design exercise was designing components. Generalizing components (so we can build and test usability and safety) while enabling flexibility for app requirements was challenging to say the least.

Example above shows routing card component, an app could create this in many different ways. When generalizing the component, i depended on user needs and most common use cases we learned from developers. For example, we knew from our own research that users first and foremost looked for the most immediate step (distance and road/exit name) for directions. This seemed to be the most common implementation by developers. 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 and country they drove in. When present, it was relevant to the current step, so I made it second section and kept it optional. Then we realized the need in Korea for large images for lane guidance and added an option to show those. During open testing we saw non-partners develop apps without current maneuver. WE inquired and realized that sometimes street/road name was not present on minor roads in Russia.

All of these learning and iterations resulted in a fairly flexible component that a developer could use to alter for their user needs.

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.

ADD QUOTES AS A SLIDE

impact and developer feedback

developer feedback is positive “efficient to develop. easy to use”….

Partners and internal teams can build with minor hand-holding.  

• SpotHero built an app 3 weeks after first drop. Sygic within a week. 

• System team created Settings app within hours, commented on ease.

we learn form usage: cover many usecases… it is growing without us having to look at all usecases,

200+ apps, with steady growth

2,5 million monthly active users. ???

WHAT DO USERS SAY? REDDIT, PRESS ETC???

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