anroid for cars app library

building a scalable and efficient library to develop car apps

for Android Auto & android automotive OS (Google)

The Android for Cars App Library is an SDK that allows developers to bring their apps into the car screens. It does so by providing a set of templates designed to meet driver distraction standards, and taking care of details such as the variety of car screen factors and input modalities.

my role

I was the UX lead from the start of this program. I collaborated with cross functional leads to set a successful multi-year product strategy and execution roadmap.

During this two year journey I was the lead product designer, providing oversight to a small team of product & motion designers, researchers and writers.

I was also the main design point of contact for global partners (app developers and car OEMs), working alongside them to validate strategy, user/product needs and iterating continuously.

GOOGLE I/O 2021 announcement. My section “INTRO TO DESIGNING WITH THE LIBRARY” starts at 7:45 mark.

Here are some interesting challenges and how I helped the team overcome them:

making sense of the chaos (setting the initial strategy)

We had the big picture, but were missing everything else... What do developers need from an SDK? What do end-users of the apps need from the experience in the car vs. on other touch points? And another million questions you have when you start something.

We battled ambiguity together as cross functional leads; we did developer interviews, scope exercises together. We used design to visualize and strengthen our initial strategy. I created app samples to explore shortcomings and strong parts we had so far.

Instead of writing a finalized PRD for MVP, we generated as many designs (screens, components, features) as possible. We then prioritized our MVP experience and feature set which we validated with developers.

 

the meat - building the mvp

App samples from developers around the world.

Design strategy to support global Developer needs and end-user context

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

To enable this strategy, I led the design team to create a framework to enable developers to create their own app architecture and user flows.

build/test/iterate with confidence

a million deciisons, a million unknowns as it is not the end interface. team at times struggled to make decisions or be confident….

, continuos developement approach. prototypes, working alongside app developers and internal developers daily. test in fast but informed decision making. it was tough but I always planned for and added as much user and developer research into the process as possible, so that our deicisons were informed as well as rapid.


 

onwards and upwards: beyond the mvp

Expanding to the OS platform

Library enables developers to build a single app and deploy it on multiple car platforms - Android Auto Projected and Android Automotive OS.

User context and needs did not change even if the underlying technology changed from projection to embedded car OS. I firmly advocated for enabling single app design across platforms as our next goal. This enabled end-users to have familiar inetrfaces, and provided developers with very limited time/resources efficiency. And, our new user base car OEMs got the benefits of a fast-growing app ecosystem with no effort,

One challenge was the different needs OEMs had, at times these contradicted with other users’ needs. Example, OEMs wanted to customize app UI for consistency of the whole infotainment. I led the team to develop and get bought-in for our customization strategy (from internal leadership and from OEM teams).

Enabling new app categories & developers, —-> evolved distraction framework, adding onto and iterating on designs, new features

Knowing number one user request was more apps, we created a multi-year strategy where we wanted to expand to all app categories (with driver distraction limitations in mind). From our experience building MVP, We knew one of the major constraints was making library driver distraction proof and the strict rules around the globe. ….To support this we needed a anti-disctraction faremwrok that can support all user context globally, I collaborated with researchers to rigorously test for distrcation and evolve our anti-distraction framework.

On v 1.xx we expanded to all poi apps (apps that lets user find gas stations, restaurants etc.). We proved that by adding components on existing frameworks we can support whole new subcategories such as ridesharing.

 

impact 🥳

Increasing product usage and supporting app ecosystem growth:

  • 400+ apps, 4.5 m MAU. These numbers grow weekly. —-> check numbers

  • Increased Android Auto usage in multiple countries where we previously had small or no market share (Korea, Brazil, North Europe etc.).

SDK ease of use & efficiency, and clear developer design guidance: Positive developer feedback, apps built in a matter of days. Signaling success in creating an efficient and simple way to build car apps.

Showing that the design strategy paid off in creating a solid foundation that can expand:

  • Launched on Automotive OS platform with minimal design/engineering effort.

  • Quick turn around on category stragey. Opened up to all POI apps (fueling, restaurant finding etc.). Ride share category coming soon.

thoughts 🤔

What was challenging ——>maybe positive and negative ones

Even though we were working inside a larger team, on multiple areas we were the first team to ever attend at. No path driven for us on multiple avenues, so we had to invent:

This was a product with ambiguous scope but a firm big picture, market timing was unknown. design stragey,, distraction on our hands…

It involved close coordination with external partners (developers, car OEMs). We were designing for multiple users (end-user, app developer, car OEMs) sometimes with clashing needs. Needed to coordinate/collaborate with internal Auto/Google teams.

We were the first horizontal feature team working this way… between had to align our design/product strategy to two different products’ was quite hard.

what i learned…

I LOVE A HUGE CHALLENGE… STARTING A TEAM, A PRODUCT OR PRODUCT AREA, HAVING NO DEFINED PATH…

AND, that you can build anything when you have a tight, open-minded, diverse, respectful and dedicated team. Even as the whole world is falling apart around you (majority of the work was done during the global pandemic).