Automatic app for Android Wear

Work-in-progress

AN UNSOLICITED CASE STUDY

Reimagining the Automatic app as a wearable experience

Shridhar Reddy

Role: UX Strategy, Visual design

Wearables and connected devices: a match for the wrist

Wearables are now where the smartphone was at in 2010. Between Apple Watch, Android Wear and Tizen, the hardware is now mature, the OS' are well baked, the hardware is solid.

Designers are still collectively figuring out what designing for wearables is like. Is it an extension of the smartphone or is it it's own thing? 

One of the most exciting uses of a wearable is its use in conjunction with connected products. Below is my reimagining of the Automatic app for Android Wear. This is an unsolicited design.

What is Automatic?

Image sourced from the Automatic press kit.

The Automatic experience starts with the adapter device that plugs into the standard OBD port available in all cars. The adaptor reads all engine data, parses it and sends useful information such as MPG, driving style (braking, acceleration, MPH) and adds useful location information.  

The current app experience

The android app for Automatic is pretty comprehensive as an experience. It nicely surfaces up system data such as speed, fuel consumption, etc and wraps it up nicely to influence driver behavior using common gamification techniques.

Screenshots from the current Android app experience

Automatic already exists in bare bones form for the Apple and Pebble Watches. The current wearable experience is limited to just one functionality: finding out where your car is parked. Pretty limited. 

Image sourced from Automatic press kit

Why Automatic for Android Wear? 

I had an epiphany about wearables during a road trip into the Nevada desert
About 200 miles into a 1000 mile road trip to Nevada, just as we started climbing up to Lake Tahoe, the dreaded check engine light came on. 
However, the Automatic app lit up to show what the error code was. P00423. Something to do with the fueling system. I hit the button on the Find Mechanics nearby - and up showed the Nissan Dealer 50 miles away. I called up the Service department as we drove, and they looked up the code. 
"It is likely something with your fuel system ...check your gas cap... " 
I checked. And indeed, the fuel cap was not screwed in right! I put it on correctly, and then from the app, I turned off the engine code. It never came back on for the rest of the trip.

So, a connected device saved my road trip, and now I want to design the experience to be right on my wrist.

Storyboard of a connected device experience. Drawing by me and Nandita based on a similar experience.

Goals, Constraints, Principles

At the beginning of the project, I set out some goals and the constraints of the design and device.

Goal

Extend the Automatic app experience to the wearable while retaining key functionality.

Constraints

No additional functionality than what is already on the Automatic app.

Adhere to all Android Wear principles

Assumptions

Assume that initial pairing of the device has already been done via the handset.

Assume that wearable can independently connect to data without smartphone connection.

The 3 Cs of multi-device experiences

Based on Michael Levin's excellent book on Multi-device experiences, I used his maxims as my guiding principles for the interaction between the connected device and the wearable. Quotations are from his book.

  • Consistent

    “In consistent design, the same basic experience is replicated between devices, keeping the content, flow, structure, and core feature set consistent across the ecosystem.”
  • Continuous

    “The hallmark of continuous design is that the experience is passed on from one device to another, either continuing the same activity… or progressing through a sequence of different activities… toward achieving the same end goal.”
  • Complimentary

    “The hallmark of complementary design is that devices complement one another… creating a new experience as a connected group.”

4 use cases

I boiled down the entire wearable experience to 4 primary use cases.

1. Where is my car?
2. How much does it cost to drive it?
3. How am I driving?
4. What happens if the car's Check Engine light gets activated?

1. Where is my car?

Where your car is parked is often the most used feature. With the automatic on the wrist, it is the easiest thing to "Ok Google" and then "Where is my car?" and presto, the walking directions pretty quickly.

Notification flow 

Try the prototype - start at the "Parked" 

2. What does my car driving cost per mile?

This is my favorite part of Automatic - being able to look at miles driven and the gas cost. I have intentionally avoided stating MPG figures here and instead focused on correlating the miles driven and Dollars spent. In the long run, I believe this correlation is a better inhibitor of driving than MPG figures. 
In this experience, the Driving today notification pops up at the end of a long stretch.

Notification flow 

Try the prototype - start at the "Drive cost" 

3. How am I driving?

The Automatic app touts the driving score as a key datapoint in influencing driving style. The device beeps whenever braking hard or rapidly accelerating or speeding over 70MPH.  
However, I feel the immediate feedback can be dangerous in the case of braking hard or rapid acceleration. A delayed haptic buzz allows the emergency moment to pass and a gentle haptic buzz on the wrist a few seconds later is safer than an immediate alert sound that might be distracting in a fast moving situation.

Notification flow 

Try the prototype - start at the "Drive score" 

4. What happens if the Check Engine light comes on?

This is perhaps the trickiest use case. For one, a Check Engine light is very obvious - it will show up right on the car dashboard. So why does one need it on the wrist? It helps to read what the problem might be. The actions are likely best executed after pulling over and using the phone to research the problem. I have limited this case study to stop at finding a nearby mechanic.

Notification flow 

Try the prototype - start at the "Engine" 

Next steps : user research

Overall, the experience of having the Automatic app on the wrist seems successful. It is driven more by the notification experience than the menu driven experience. However, only with real user testing will real problems with the wearables come to light.  The general direction of user research should proceed on these lines:

1. Do you find the phone app to be adequate for your needs?
2. Has the Automatic phone app made you a more frugal or safer driver?
3. If you had a wearable app, which of the 4 use cases are most useful for you?
3. Do you care about haptic feedback while driving?