User Research: Developing Heuristics for Android Auto App Developers

Duration: ~2.5 months



Spring 2019 for UX Research course

Team Members:

Conner Hunihan

Sharanya Soundajaran

My role:

UX Research

Developing screener

Diary Studies

Contextual Inquiry

Tools used:

Contextual Inquiries

Diary Studies

Competitive Analysis



For my course User Experience Research, my team and I were paired with our client Google to perform some research regarding Android Auto. The client said that the problem area was broad, and that they were interested in generally learning more about how to create a better experience for users. From our desk research, one fact stuck out at us. Android Auto is a platform which extends experience on phone onto screen embedded in car. Android Auto allows anyone to develop apps for their platform unlike Apple which only provides ~11 applications on their app-extension-platform to carefully curate the experience.
FinalProject The A_Team (1).jpg

Preliminary Research - The Big Takeaway

Android Auto will only be successful if the independent app designers deliver 'enough' positive user experiences.  When people interact with Android Auto, their experience is defined not by the platform but by the individuals apps. Many of these apps might not have been designed for a car.


Develop a set of heuristics to guide app designers in creating experiences suited for the unique constraints of the automotive environment

Our Process 

We decided to choose a research process which would allow us to gradually hone in on an area of focus and results. We began with a broad, generative method by using diary studies, then moved onto narrower formative methods of contextual inquiry and cognitive load analysis, and finally summative methods of comparative analysis before making our final recommendations.

research process.png

We also developed a research schedule, screeners, recruiting plan, etc.

Generative Method - Diary Studies

diary studies.png

6 participants who documented daily driving experiences via vlogs, photos, and notes over 3 days and uploaded to cloud


Goal: Identify how auto interface needs are different from standard software experience during driving experience


01    During work commutes, some people use car time for professional functions but                have no existing tools for support via their mobile apps

02   In-car functionality extends before & after driving session, as well as between                      sessions

03    The level of cognitive load throughout the driving experience greatly varies, but in              general we can start to identify trends of low, medium, and high cognitive load

Formative Method - Contextual Inquiry


4 ride-alongs where participants were asked to walk me through their thought process while driving and while accomplishing everyday driving tasks

Goal: Understand frustrations of these contexts and measure painpoints

Affinity mapping the results from ride-alongs...



FinalProject The A_Team (10).jpg
FinalProject The A_Team (9).jpg

Formative Method - Cognitive Load Measurement

FinalProject The A_Team (5).jpg

4 participants were asked to fill out NASA Task Load Index surveys which measured their cognitive load during tasks while driving, such as changing radio stations or answering a text message.

We then mapped our results in a two different 2x2 findings matrices


FinalProject The A_Team (11).jpg

Summative Method - Competitive Analysis

FinalProject The A_Team (6).jpg

Feature comparison of different competitors

Understand landscape and define product opportunity

(this research was headed by a team member)

Final Deliverable - Set of Heuristics for Independent App Developers for Android Auto

Primary measures

  • Consider whether the app you are designing would be interacted with only while driving. Some drivers start up apps before they get in the car - others start apps while driving.

  • Limit the number of functionalities that can be ported (borrow from Car Play’s filtering of UX/UI; restrict the temptation for the driver to edit a word document instead of driving)

  • Consider if the app you are designing would ever cross into a high cognitive load moment  - if so, consider finding a way to design for the highest cognitive load moment to reduce safety risks or automate a way to detect when a high cognitive load moment is present

  • Hierarchy of information should be based on immediacy is of paramount importance: immediate things requiring driver response (imminent collision)/blind spot detection > lane departure warnings > media

  • Be consistent in visual and interaction design between phone and head unit (in-car screen) - users find the same things in the same places, with the same icons - contributes towards a seamless switch from phone to car, and familiarity, and conventions reduce cognitive load

  • Introduce non intrusive feedback once action is completed such as sound: apps should not require the driver check for completion

Secondary measures

  • Position warnings in locations easy for quick viewing: on the screen/windshield (as a heads up display), as an alarm or a beep - ensure that it draw people’s attention fast, while leaving no room for ambiguity or error

  • Think of integrating the cluster and the infotainment: a reduction in cognitive load using a more robust ADAS.

  • Consider the relationship between the cluster and phone unit, for example - a portion of the cluster acts as an extension of the head unit (displays the same turn by turn navigation, or the current media being played)

  • Ensure that information on cluster/head unit is contextual to cognitive load, and driver distraction, keep in mind that different cars/driving scenarios emphasize different information (highway driving/driving an electric car)

  • Technical performance can make or break the experience - even more so than outside of the automobile due to heightened danger: laggy or glitchy infotainment greatly put users off, and given that Auto is currently running as a non-native extension on most cars, this is a common problem

  • Design for large hands since delicate, precise interactions are difficult while driving: consider finger widths and distance of eyes from screen (larger fingers need bigger/more space out buttons, and older eyes need larger text)

  • Keep in mind the potential to use software to unify hardware: telltale locations, steering wheel/lever/button layouts across cars/regions currently differ greatly.

  • Consider whether the screen is angled towards driver. Consider also the central knob/mouse pad, etc. and granularity of movement of hardware that translates onto an interaction on the screen

  • Finally, consider country specific guidelines: not just LHD/RHD, but rules about phone use (whether it is illegal to actively use phones/infotainment while driving)/mandates to use specific coolants or pollution reducers (AdBlue)/the differences in shape of traffic signs/units of measurement (mph-kmph/gallon-liter).