Visionary

Finding Safety



In 2016, Mercedes-Benz began its dive into future connected car services. In the years since, they still lack products that focus on user needs.

I designed a solution for connected car monitoring with the Innovation Team at Mercedes-Benz.

Background



Mercedes-Benz’s future vision revolves around CASE — Connected, Autonomous, Shared Services, Electric.

Our Innovation team was tasked with finding a digital product use for hardware within select models, but this lacked a specific user or problem.

Some information obfuscated for confidential reasons.

Scope



We had 3 weeks to create an MVP that would be reviewed by a GM and potentially be approved to continue product development.

I led design in our team of four interns (1 design, 1 product, 2 engineers), but also conducted user research with my team. We were guided by three Innovation Team managers.

This was presented to and approved by two GMs in August 2019.

The Problem



A New Product Approach



The A-Class' rejuvenated "bottom-up" approach with fitting entry-level cars with more tech features appeals to a younger, new customer.

But the A220 still starts at $32,500. Are these drivers feeling supported in their large investment?

Monitoring Blindspot


For all the cars' expanded control features, do drivers feel safe with their purchase?

Who's Driving?



While customers differed in behaviors, preferences, and contexts, they shared a desire for increased control and assurance.

Only 1 of the 34 customers we interviewed used a dashcam. 7 indicated interest but felt aftermarket solutions were intimidating. By contrast, existing OEM competitors showed more success.

Finding Commonality


Drivers fell into different persona spectrums, but they shared a desire to control for the uncertainties of owning and maintaining a vehicle.

In Summary



Drivers want to take safety measures for their car but lack the means to do so.

A native solution addresses aftermarket issues and fits within MB's CASE product strategy - creating a smarter, safer car ownership experience.

What does providing drivers with control and assurance look like?

Peace of Mind


An OEM monitoring solution adds peace of mind for customers - making their purchase all that much more worth it.

The Solution



Visionary



Visionary monitors Mercedes-Benz vehicles by logging events, pushing notifications, and recording incidents.

Security for Different Contexts



Drivers set how sensitive they need Visionary to be. Turn it off while parking in the garage at home, or increase sensitivity when handing the car off to a valet.

Logging Vehicle History



Visionary logs events in one place, giving users an accurate timeline of events that have happened to their car with text info and videos.

On-Demand View



Users check in on their car at any time with a live stream and incident notifications.

Manual Recording



Drivers have the ability to start a manual video capture or instantly capturing the last two minutes.

The Research Process



User Snapshot



Our team talked to 34 drivers across 5 days to learn about their needs and relationships to their cars.

4 qualities differentiated drivers from each other:

  1. Comfortable Drivers vs. Anxious Drivers
  2. Driving for Leisure vs. Daily Drivers
  3. Alert Drivers vs. Distracted Drivers
  4. Value Car Highly vs. Ambivalent About Car

Spectrums Over Personas



Personas can bias insights towards demographic factors. Our previously defined driver qulaities helped orient motivational-level behaviors and needs.

We identified two main groups:

Type A


These drivers highly value their car, remain alert while driving, and feel the ever-present need for more control over their vehicles.

Type B


These drivers feel comfortable driving and value their cars, but they mostly just seek assurance and reliability.

Specs



Based on user needs, we determined a monitoring system had to have certain qualities:

  • Native: Minimal setup, work across models
  • Connected: Information accessible in real-time
  • Event-logging: Record incidents, note relevant information, and log info in a categorical format

The Design Process



Behavioral Motivations



Which actions are to be taken by users?

  1. Check: Observe status and context
  2. Act: Take action to prevent an incident
  3. Feedback: Receive continued updates
  4. Review: Obtain recourse in case of an incident

Early Explorations



Initial information architecture was drafted, before visualizing first attempts on paper.

The central dashboard became the main focus for checking updates, adjusting monitoring sensitivity, andcapturing video.

Dedicated security and video reviewing functions sat in discrete tabs.

First Attempt


Informal card sorting helped solidify a first pass of IA, which were translated and explored more in-depth with paper prototypes.

Shortcomings



Quick and dirty rounds of usability testing resulted in a number of stepwise improvements.

Incremental Revisions


Cursory usability testing revealed small improvements for the then-called Security mode.

However, I downplayed contextual sensitivity. Situations could be simple: driving versus parking. Or more granular: covered versus street parking. Or even more granular: which street, what time.

Existing designs missed the nuance of driver expectations in specific situations. In response, the next few iterations:

  • split the dashboard into distinct “Park” and “Drive” modes.
  • defined sensitivity of parking modes.
  • combined event log and video library as review actions.

Expanding Context Sensitivity


The challenge was keeping the flow streamlined while expanding capacity to deal with situational needs. (Left) Distinct Drive/Park modes inspired action-based, context-sensitive use. Note the updated monitoring sensitivity slider. (Right) Event Log/Library as post-hoc actions were consolidated.

Visuals



Design patterns moved away from existing MB app designs for internal reasons.

Lo-fi visuals and icons emulated shedding light onto the dark, with dark tones and metallic highlights for contrast.

User-specific details have corresponding car model silhouettes. Color is sparse — blue for status information or yellow for destructive indications.

Defining Visual Language


Above are two early explorations in utilizing a visual system to enhance use.

Design for Assurance



The Drive interface emphasizes manual capturing and on/off for monitoring, cutting down on excess information while in the act of driving.

Alternatively the Park interface’s hierarchy emphasizes monitoring sensitivity and status updates. Drivers can also view visual crowdsourced incident data to assess the safety of a nearby area and adjust sensitivity accordingly.

The event log displays relevant incident information. Functionally users here can flag key incidents, playback and download video, and extract video data — validated by developer teammates’ technical demos.

From these key elements, I formed the flow of Visionary.

Lessons Learned



Design Impact



Design value lies in activating a user-centric approach within a multidisciplinary team. Empowering non-designers helped my delivery of the prototype.

Strong Opinions Loosely Held



Throughout the process, user perspectives were adjusted throughout team meetings. Even though the research wasn’t bulletproof, each small design decision was justifiable through it.

It was important to realize that snapshots of users could change drastically.