UNDER CONSTRUCTION
Location-sharing
The context
Lyft Concierge allows organizations to book rides on behalf of individuals from a centralized dashboard or API integration. Lyft’s largest customers are healthcare organizations transporting patients for non-emergency appointments. Many of these patients are elderly or from underserved groups.
The challenge
Concierge has a higher no-show rate than consumer rides. In diagnosing the reasons for this higher rate, we learned that we have a no-show rate of 1.5% when a rider’s precise location is tracked, and 10.5% when it’s not.
Only 10% of Concierge riders allow Lyft to track their location, compared to 96% of consumer rides. One of the main reasons is that precise location tracking wasn’t enabled for the mobile web experience; around 60% of Concierge riders don’t have the Lyft app and use our mobile web experience to get information about their rides.
Maps and addresses can be imperfect proxies for a rider’s actual location. In a large apartment complex or hospital campus with dozens of exits, for example, an address does little to help drivers find their passengers. At some point, drivers give up looking for their rider, believing they failed to show for the ride. In fact, that rider may simply be waiting a few doors down. This results in stranded passengers, frustrated dispatchers, and customer dissatisfaction.
The solution
By enabling precise location tracking on mobile web, we hoped to reduce no-show rates for Concierge — a metric that tells us that drivers are finding riders with ease, dispatchers aren’t having to duplicate their efforts, and riders are having a seamless transportation experience.
My role
Building the capability to share precise location was one thing. Letting riders know about it was entirely another — and that’s where I came in.
How might we shine a light on the value of location-sharing to riders while addressing and anticipating their privacy concerns? How might we do so for riders who may be new to rideshare and have varying levels of tech-savviness? How might we do so at the right moment for riders in that brief blip when we intersect with their lives, their health journeys, and personal stories?
Understanding constraints
I first worked with my product and eng partners to understand constraints. For example, I learned that we had one chance to surface the native device prompt, where a user would simply tap “Allow” to enable precise location-sharing. If a user tapped “Don’t allow,” we could never be able to surface that easy native experience again (unless they cleared browser cookies). Instead, we’d have to somehow provide them instructions to update their settings manually — and this varied across browsers and devices.
Identifying placements
Next, I collaborated with my product design partner to identify when and where we could best surface this messaging. We wanted to avoid leaving it to the last minute — in the moments before a driver arrives, riders are often in a rush, sometimes anxious as they prepare for their Lyft ride and (if applicable) healthcare appointment.
I audited the existing text messages, and proposed adding links that would bring them into the web experience earlier. Because we didn’t want to add eng scope by making the text messages dynamic per user (showing different copy for users who have and have not shared location, for example), the copy needed to be generic while also nudging users to click through so they could see our more on-point messaging in the product.
After clicking through, they would see messaging prompting them to share their location — (1) a bottomsheet upon opening Lyft mobile web, (2) a location status on the map, and (3) a banner on the trips hub page.
Testing variants
I spearheaded a DIY, unmoderated copy testing study. This involved developing a set of variants for each placement and corresponding hypotheses. I worked closely with xfn partners to I drafted a script, reviewed by our team’s UX researcher.
that it would be best to started with text messages.