Overview

We have delivered the FIRST in-vehicle e-commerce solution in the world running on, as of 2021, 20 million vehicles.

User Goal

I want to transact with merchants during my drive, so that I maximize my driving experience.

I want my vehicle telemetry, as I choose to provide it, to be used to shortcut merchant task-flows, so that I can more quickly and efficiently complete transactions.

I want driver distraction approved merchant task-flows, so that I and other drivers can confidently operate my vehicle safely while driving.

I want contextual and behavioral merchant task recommendations, so that I can seamlessly interact with merchants without needing to launch them within the app library.

Business Goal

Create new after sale opportunities for OEMs by leveraging vehicle telemetry and merchant relationships.

Strengthen a merchant’s relationship with their existing users and provide new opportunities for user acquisition.

Provide new sticky user experiences that launch into new business opportunities via Xevo Glass.

Challenges

Driver Workload Testing

Every OEM leverages a 3rd party testing agency. This is to remove any chance of bias. These tests are expensive and can block a release if anything fails. If something fails, then we are sent back through the arduous design process requiring internal and external stakeholder approvals.

Every designer on my team, including myself, must be an expert in what is and is not viable for Drive (vehicle gear position) task flows. At a glance this includes character count, image usage, interactions, messaging, accessibility, and total task flow time. A user, in general, is only allowed 12 seconds to complete any task while driving.

Merchant APIs

McDonalds, Domino’s, GrubHub, Shell, Exxon, Chevron, Parkwhiz, PaybyPhone and all other merchants haven’t built APIs for 3rd party consumption. How do we create a consistent user experience for all merchants when they all have different task flows, APIs, security, preferences, voice of the user, brand guidelines, and feature support? How can we leverage what these merchants have already built to reduce any investment (cost) on their team to support in-car functionality? Some merchants support external payment and a lot don’t. All have different forms of authentication. We have been taking a fragmented merchant landscape and adapting them into a highly constrained ecosystem.

OEM Head Units

Head Units are a mixed bag of hardware and software stacks. Performance varies greatly. Within a single model year an OEM can have 10+ Head Unit models with different hardware and software. For those that do run android they lock the ability to build responsive design solutions. Some HU systems have proprietary software languages that use projection services. Overall, nothing is standardized and nearly every HU model has a unique set of challenges.

OEM, Merchant, and Internal Approvals

It can be challenging getting three companies on the same page. I have had to deal with this a lot throughout my career. 3 different design teams, 3 different engineering teams, 3 different quality assurance teams, and 3 different management teams. Building a foundation with thorough requirements and detailed specifications are critical. The more data you have to justify your decisions the more likely you want receive push-back.

Mental Models

Users have well established mental models for e-commerce task flows. These mental models have been formed over years of pattern development. We, unfortunately, can’t meet all those expectations 1-to-1 due to the factors listed above: Driver Workload Testing, 3rd party Merchant API support, and Head Unit limitations. We have to deliver a subset of the expected functionality for a merchant and new task flows that work within the vehicle.

Managing The Team of Designers

Developing a system comprised of process and tools where designers can produce consistent design assets at an effective pace was crucial. When you have 6 designers working across different projects under the same product umbrella things can quickly become out-of-sync without structure. So, what did I do about this?

1. Created company wide design process workflows that detail initial merchant engagement, requirement documentation, approval of requirements, task/ticket construction, design ideation, design team peer reviews, internal stakeholder reviews (Dev, QA, Marketing, BI, Management), external stakeholder reviews, design hand-off, and build reviews.

2. Developed new methods for managing design documents within our internal repositories. This made documents more accessible to everyone in the company.

3. Developed new templates for design documentation. This insured all material produced by my team captured all required information needed for all dependent teams.

4. Arguably one of the largest benefits to these processes and tools was how it empowered our designers and leveled out skill gaps between them. Turning a designer that normally would feel less-than into a designer that was on equal footing. This gave designers a comfortable environment to develop and grow.

OEM Impediments

There has been and is a lot working against the success of this product.

1. No top-funnel advertisement or messaging that educates users because of OEM restrictions.

2. No federated accounts with an OEM profile. This forces users to go through a Market binding process before they can see the full suite of applications.

3. Most merchants do not support tokenized payment or federated accounts, which forces users through linking flows for each merchant.

4. Contextual notifications and recommendations are just now becoming available.

5. Most Head Unit systems are locked 2-3 years before the vehicle launches. Access to voice, maps, notifications and other core accessibility functions are not available without a CR to the hardware provider. The cost of the CR prevents the OEM from making the request.

6. OTA updates are rare and expensive.

7. Most apps sit behind a an expensive and poorly marketed connectivity package.

8. The list goes on…