Lyft Comms Platform

Rider Communication Platform

I was tapped to lead design on Comms Platform to define a multi organizational framework on how we communicate with our riders. I drove our content guidelines which informed the work done on the Science and ML side, formed our roadmap with Eng, designed our components, and collaborated with every single team working on the Rider App (as well as a few Driver teams). This system is used by every single team touching the Rider App. As a platform team, our job wasn’t always easy. We often had to strike the balance between maintaining quality in the user experience with not being a blocker for teams. It was incredibly rewarding to collaborate with and see so many teams use our system. 

Success Metrics
• 24% increase in Lux rides at airports
• 14% increase in LyftPink members
• Reduced client development time with scalable component
• Drove incremental rides with Rider Milestone banners
 
 

The Problem

Teams were building the same messaging components for the same needs not knowing another team was building the same thing. This resulted in wasted Engineering and Design time, extra code, messaging collisions between teams, and users being spammed with irrelevant messages. I had a directive from leadership to fix these issues and create a system on how we communicate with our riders.

Riders would often be bombarded with irrelevant messages without regard to what messages they’ve already seen. We needed a framework for our partner teams (every team building into the Rider App), and an integrated logic so riders receive the right message at the right time.

 

The Approach

As a newly formed team, we needed to understand what messages we were sending and at what moments across the org. I used this information to then create the Rider App Content Guidelines. These help teams understand what component to use and where their message should go so we could send the right message to the right user at the right time.

Each team has specific needs. We started off with 7 categories of content (user education / onboarding, new feature / product announcement, marketing / brand moment, etc). Here are two examples of decision trees I included into our guidelines for each category from the Rider App Content Guidelines, on where content can appear for the Promotional and Critical categories as well as what component can be used.

 
 

The Solution

In addition to creating platform guidelines, we also created a number of messaging components. I collaborated with Design Systems to leverage some of their existing components and to ensure our components worked in harmony with the Design Systems components. I also paired closely with the Science and Machine Learning teams to ensure that the logic respected the guidelines so we could send contextual and relevant messages to riders. Here are a few of our components:

 

COVID-19 and In-app Emergency Work

If ever there was a roadmap thrasher, it's a global pandemic. I was the point person on the team working with the COVID-19 taskforce to ensure we could get our messaging out the door. Because Panel Banner was designed to be flexible and mostly server driven, we were able to deploy within hours intead of the 2 week client release cycle (COVID-19 won't wait for a client release anyways). 

When we were asked to shut down two markets and communicate temporarily turning off Shared Rides, we repurposed the "Market Unavailable" experience (i.e., if you open the Lyft app in Antarctica). The "Market Unavailable" experience being repurposed for an in-app emergency experience wasn't ideal but it's what we were able to deploy within an hour. As a Global Pandemic wasn’t something I’d previously stress tested for, we found that we had to add an additional category to our guidelines around Critical Emergencies.