Alchemy by Leban Hyde

Role:

Lead UX Architect

Duties:

Subject Matter Expert, Mobile
Information Architecture
Interaction Design
Visual Design

Company:

Xtime, Cox Automotive

Duration:

2020–2021

Platform:

Hybrid (React Native, Tablet)

How a rideshare service was integrated into the check-in experience on tablet, providing additional customer amenities, improving workflow efficiencies, and boosting revenue.

Overview

Rideshare is an add-on feature for the Xtime platform, designed to Service Department users to hail rides for their customers while the vehicle is being serviced. This feature already existed on service appointment scheduling app for desktop. The ask was to port the same feature over to Engage, a tablet-based app for expediting the check-in process for service appointments.

Kick-Off

This was a more tactical project, since the third-party integration already existed on the desktop experience. All the initial problem discovery and market validation had already been handled by the previous project leads.

My role was to primarily drive solution discovery, make recommendations for mobile/tablet, and design the experience accordingly. Subsequent meetings with Lyft were necessary along the way to ensure a seamless experience across products as well as account for edge cases.

Challenges

Third-party team collaboration
Cross-product integration
Cross-platform experience

Problem Definition

Who

Service Advisor (Dealership user)
Consumer (Dealership customer)

What

Allow the Consumer to not have to wait at the dealership
Pick the Consumer up from the dealership
Bring the Consumer back to the dealership

Where

At the dealership, service department
Location of choice within certain constraints set by the dealership

When

During a service visit, after check-in
After service is complete

Why

So that Consumer is not “held hostage” at the dealership during a service visit
To improve the overall service experience for the consumer, positively impacting the brand
Improved workflow efficiency by integrating with tablet app
Revenue share potential, increase in profit

In addition, since this was a tactical exercise, we also needed to answer the following questions specific to the current experience in Engage:

How to present the Rideshare UI?
How to access the Rideshare UI?
Should Transportation Options be moved in the workflow?

Solution Discovery

For implementation to be successful, we had to address these initial questions:

Where in the existing workflow do we surface the rideshare experience?
How will we apply mobile standards to the rideshare experience with considerations for tablet?

But first, to know where we’re headed, we needed to know where we’ve been…

Current State: Task FLows

For both apps, Scheduling and Engage, the primary use cases were the same, as stated in the problem definition above…

During a service visit, after check-in
After service complete

Current task flow for Check-In and Service Complete | Rideshare + Scheduling — Current task flow for Check-In and Service Complete, Scheduling app.

Current task flow for Check-In and Service Complete | Rideshare + Engage — Current task flow for Check-In and Service Complete, Engage app.

Current State: Service Blueprint

Default screen, From Dealership | Rideshare + Scheduling — Default screen, From Dealership. Rideshare, Scheduling app.

Current State: Rideshare - Dealer Side

Request Accepted | Rideshare + Scheduling — Request Accepted. Rideshare, Scheduling app.

Current State: Rideshare - Consumer Side

Comparative Analysis

Similar to the desktop experience in the Scheduling app, it was clear that a similar experience would be need for the Engage app. But brought into alignment with mobile standards — specific to tablet for iPadOS and Android.

Comparative research for modals on tablet, iPadOS

Comparative research for modals on tablet, Android

Feasibility Analysis

In addition, the UI for the original integration was built for the web, whereas Engage was a tablet app. However, Engage being built on a hybrid platform — React Native, which leverages web technologies — meant that we might explore potential code reuse. As such, we were faced with the follow questions.

Port over the existing web UI, reusing the side drawer pattern?
Rebuild the modal as native UI, using a tablet-specific pattern?

A major concern for the reusability of the side drawer in conjunction with the virtual keyboard. As form inputs were a necessary part of the ride hailing experience, the virtual keyboard would be active during most of the task.

Wireframe illustrating keyboard-to-screen ratio, iPadOS & Android — Keyboard-to-screen ratio, iPadOS & Android

The virtual keyboard was the dealbreaker (see below), so we opted for number two:

Rebuild the modal as native UI, using a tablet-specific pattern.

Wireframes examining the interaction design between the side drawer UI and the virtual keyboard — Side Drawer vs Virtual Keyboard

Initial Wireframes

Building off of what we learned from the previous investigation (above) and addressing issues with the virtual keyboard, the following wireframes were explored…

Wireframes exploring possible solutions for the ride summoning form and virtual keyboard — Gang-Up Modal (Dialog), Gang-Up Full-Screen, Gang-Up Stepper

Delivery

After several rounds of conversations with product and engineering — and the project be paused and resumed multiple times — the following experience was delivered in close collaboration with the team.