“That little island changes everything”

How we designed Lyft Live Activities to elevate the rider experience

Alexander Savard
Lyft Design+

--

Illustration by Alexander Savard

A game changer for rideshare

Of all the things we do at Lyft, choreographing pickups between riders & drivers is one of the most complex and consequential. Nailing this choreography depends on Lyft doing a lot of things well but simply keeping riders up to speed is essential. Failing to deliver the right information, at the right moments can lead to poor experiences for riders & drivers alike.

Fortunately, the Lyft app does a great job at delivering those critical updates. Unfortunately, we can’t actually guarantee that riders will have our app open to see them. Our riders are busy people and we understand they’re often juggling multiple tasks as they prepare for their ride. Our primary challenge has never been what info to deliver but how we can deliver it to distracted riders.

Until Live Activities, push notifications were the only way to deliver critical updates to riders, but for Lyft’s use-case, notifications were far from perfect. The push notification channel is:

  • Crowded—with critical updates lost in a sea of promos & coupons.
  • Fleeting—with critical updates easily missed if you look away.
  • Quickly out-of-date—with stale updates sometimes misleading users.

The problem wasn’t necessarily with notifications, but that specific, critical updates deserve a different delivery channel; one that is deservedly prominent, persistent, and always up to date. With Live Activities, Apple delivered exactly that, creating a highly-dynamic, highly-customizable space that makes those updates easier to access, easier to understand, and easier to act on.

We expect Live Activities to be a good augmentation for many iOS applications, but for specific use-cases like rideshare—where delivering timely updates can make or break a real-world experience—it’s a genuine game changer.

For us, Live Activities isn’t just some new widget—we see it as a whole new way to experience a Lyft ride on iOS.

An ocean of options

The most unique and powerful attribute of Live Activities is their ability to take different shapes in different contexts. Each Live Activity has four possible presentations depending on where it appears:

  • Minimal: One tiny surface floating next to or inside the Dynamic Island; used when multiple Live Activities are active and sharing the space.
  • Compact: Two small surfaces on either side of the Dynamic Island that form a single cohesive view; used when there is only one Live Activity.
  • Expanded: A larger singular surface that expands from the Dynamic Island to display Live Activity updates (or when held down by the user).
  • Lock Screen: Appears on the lock screen and when the phone is unlocked it also appears like a banner notification to deliver updates.

This fluidity is great because it allows Live Activities and the critical info within to permeate throughout the entire iOS experience but it also requires designers to design four different versions of each Live Activity state 😅. This might not be an issue if your Live Activity has one state, like the scoreboard of a sports game, but ours has 26 different possible states…

Covering 26 different ride states, each with 4 different presentations meant designing 104 unique Live Activities.

56 of the 104 Live Activity designs

Designing 104 permutations of anything is intense, but the presentation fluidity presented some unique challenges. Because Live Activities can fluidly switch presentations throughout a ride (e.g. moving from the lock screen to the dynamic island when a user unlocks their phone), there are a near infinite number of paths a user could take through that grid of designs.

Our preview prototype

Looking at the entire grid of designs was helpful to an extent, but we needed a better way to simulate those possible user paths to see if they felt like a cohesive experience.

To facilitate that simulation I built a unique, remote-control prototype in Figma that allows the reviewer to navigate vertically and horizontally through all 126 designs in the grid.

  • The five circular buttons at the top allow the reviewer to traverse vertically, switching between different Live Activity presentations (MIN = Minimal, COM = Compact).
  • The two larger buttons at the bottom allow the reviewer to traverse horizontally along the golden-path (Waiting > Arrival > etc).

(note: blank space at the top allows devices w/o the dynamic island to simulate it)

  • To make this navigation easier I included a drawer menu which allows the reviewer to jump to specific stages of the experience.
  • To help our reviewers recognize which of the 126 designs still needed feedback I created a color-coded system of feedback-flags (“Done”, “Needs Input”, etc)
  • To help reviewers give better feedback on WIP designs I also included a “show alternatives” button which reveals other options under consideration.

While this type of prototype might seem over-the-top, it played an essential role in honing our final designs and accelerated the review process with our team of stakeholders.

Maximizing the minimal

When teaching students how to design a website, we tell them to always design the mobile version first. There are many reasons for this but an important one is that the smaller screen forces you to make tough decisions about what information to prioritize in a condensed space. Designing Live Activities is the ultimate exercise in prioritization-by-concision with the minimal state presenting the most unique challenge:

How do you give riders the critical information they need if you only have a 36px circle?

With space so limited, the decisions about what information to include become more difficult and consequential. Establishing designs for the slightly larger “compact” presentation allowed us to identify which single piece of information is most helpful to riders at each stage of a ride. But after numerous exploration it wasn’t clear that each stage could be effectively minimized.

In critique, two schools of thought emerged for handling the minimal state:

  • Keep it simple: Accept our limitations and just use the minimal state as a placeholder that allows riders a quick path to more info.
  • Why not maximize?: Leverage what little space we do have to communicate as much as we reasonably can.

Ultimately we decided to balance the two schools of thought by looking at each ride stage individually and asking ourselves:
“Can we use this tiny space to effectively communicate?”

At a few stages (like matching & in-ride) we felt the answer was “no” and opted to display the Lyft logo as a simple, consistent placeholder. But during the waiting & arrival stages (when timely updates are more important) we felt the answer was “yes”. As the car approaches, riders will see the number of minutes until they arrive and shortly after they do, riders will see a car icon denoting that their car is here. By comparing this approach to the “simple” alternative you can see how much more information can be effectively conveyed.

Comparing the “Simple” & “Balance” approaches during the waiting & driver-arrival stages.

Visualizing progress

For Lyft, the map is an essential part of the in-app experience, but one we quickly discovered wouldn’t be supported in Live Activities. This technical limitation created an interesting design challenge:

How might we orient riders and visualize ride progress without using a map?

Early progress visualization explorations

After thorough exploration, we found our first approach was also the strongest: to simply flatten our two dimensional map route into a one dimensional progress bar and use it to show progress at each stage of a ride. By combining the familiar form of a progress bar with our standard map elements we were able to replicate much of why users look to our map in the first place.

Progress mechanics

For the portion of the ride when a rider is in the vehicle, creating the progress mechanics was quite straightforward: start the car on the far left and move it each minute until it ends on the far right when they’ve reached their destination. But this same end-to-end paradigm didn’t translate well to the pickup stage.

When a rider is matched with a driver they get an initial ETA telling them how long until their driver arrives. Quickly understanding this ETA is critical for riders but it becomes more difficult if you start the progress bar at 0% each time a rider is matched. This consistency in initial position gives the rider no visual indication of how far away the driver actually is—“1 min away” and “21 min away” look exactly the same—and it also causes the car to move at significantly different speeds depending on the initial ETA (see below).

To address this we divided the progress bar into 10 steps and place the car dynamically based on the initial ETA: 10 minutes away is 10 steps, 3 minutes away is 3 steps, etc. Doing so ensures the car travels at a consistent, predictable speed and gives riders a consistent sense of how far away their driver actually is: if the car is far, you’ve got time; if the car is close, be ready soon.

Final progress mechanics at initial position and 5 minutes after matching.

But in our app the map route-line does more than just visualize driver progress. It also displays:

  • Waypoints when you’ve entered multiple stops.
  • Shared stops when you’re sharing a ride & co-riders are coming/going.
  • Drop-offs when the driver en-route is dropping off someone else first.

We saw an opportunity to take our familiar map visuals and bring that additional functionality to Live Activities.

Doing so elevates this visualization above a simple progress bar and better connects the Live Activity experience to the in-app experience we’ve perfected over a decade.

Lessons for Live Activity design

  • Embrace your limitations: Live Activities are an amazing addition to iOS but they come with significant limitations in size, animation, & functionality. Rather than trying to stretch the constraints (cramming & hacking), lean into those limitations and allow them to prioritize the content you can (and often can’t) serve effectively.
  • You’re not alone on the Dynamic Island: As Live Activities proliferate (and eventually crowd) the iOS ecosystem, this will mean sharing the dynamic island with more apps & functions. With space in minimal presentation so limited, it’s both more difficult and more important for designers to ensure users can identify which Live Activity belongs to their app. For Lyft, consistently utilizing our brand’s unique pink color was invaluable in maintaining identifiability throughout the ride. 🩷
  • What’s important changes: With space so limited you have to make difficult decisions about what content to prioritize but remember that what content is most important often changes throughout the experience. You can communicate more with less space by finding the right content for the right moments and switching content dynamically.
  • Don’t forget about accessibility: This topic is worthy of its own full blog post (and there are many too many facets to cover here) but you shouldn’t let the newness of the feature distract you from making it as accessible as possible. We spent the most time: optimizing each lock-screen design and content to support all dynamic text-sizes in iOS, ensuring all colors are WCAG AA contrast compliant, & refining the voice-over experience to ensure core content is understandable and efficiently audible.

Closing thoughts

Live Activities aren’t for every iOS application but for some they’re a game changer and rideshare is definitely one. We want to extend our gratitude to the Apple iOS team for building Live Activities but also for choosing to empower designers by making them highly customizable.

We couldn’t be more excited at Lyft to be rolling out Live Activities today and are excited to improve on them in the future. Feel free to comment below any thoughts, questions, or feedback you might have.

Special thanks

The launch of Lyft Live Activities wouldn’t have happened without our incredible team on Rider. In particular: Enoch Lau (product), Doug Liebe (data), Julia Green (content), & Max Husar, Artur Stepaniuk, Mykola Bilyi, Evgeniy Syniak, and Vladimir Sviarzhynski (engineering).

I’d also like to give a special thank you to designers James De Angelis & Braden Floris who designed early concepts, and to our design leaders Brian Ng, Megan Ellis, & Linzi Berry.

This article was written by Alexander Savard and edited by Julia Green, members of Lyft’s Rider Design Team. You can read more articles about how we build and maintain design systems at Lyft here. Interested in joining our team? Check out our open roles!

--

--