anroid for cars app library
building a scalable and efficient library to develop car apps
for Android Auto & android automotive OS (Google)
Brief
Develop an SDK (development kit) for car app developers.
End product
The Android for Cars App Library 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.
Library enables developers to build a single app and deploy it on Android Auto Projected and Android Automotive OS platforms (jointly in XXX of cars on the road).
my role
I was the UX lead from the start fall 2019. I worked closely with other discipline leads to set a strong multi-year product & design strategy and create an execution roadmap. During this two year journey, I was the lead product designer also 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 user/product needs and iterating on the design continuously.
making sense of the chaos (setting the strategy)
GOOGLE I/O 2021 announcement. My section “INTRO TO DESIGNING WITH THE LIBRARY” starts at 7:45 mark.
initiAL Product strategy
‘Start small and build well’ was our principle from day one. We had the big picture, but what exactly to build, how/when etc/ were all ambigious. I worked extremely closely especially with my PM partner on this phase. We did initial developer interviews and scope exercises together. instead of writing a finalized PRD, we did a design exercise where we generated as many designs (screens, components, features) as possible. We then used it to create a future, near-future and most importantly an mvp feature list.
Contributed to getting partner agreement on scope and execution details.
Design strategy
xxxx
the meat - building the mvp
exploring global Developer needs and 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.
From early on, I advocated to enable developers to create their own app architecture and user flows. To allow this, we had to design to support capabilities such as:
build/test/iterate
xxx
onwards and upwards: beyond the mvp
Expand to car OS platform and multiple vehicle OEMs
After MVP, we started on releasing on AAOS. This was going to enable developers design a single app, a single UX and deploy on both platforms, reaching a large user set.
I advocated the insight that user context and needs did not change even if the underlying technology changed from projection to embedded car OS.
biggest new challenge here was car OEM need to customize app UI according to the rest of their infotainment. Technology behind customization was not sophisticated enough for my team to plug and play. so, we strategize a whole new way to do it. i collaborated closely with engineers… and we had to sell our approach internally…
new app categories, new developers, evolved distraction frameworks
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).