Scaling Lyft’s Ride History
This was a project I felt would be worth writing about because my experience with it highlights a lot of modern product design processes quite well. Designers joining organizations today are often asked to redesign an existing feature that has long outlived its purpose, and it can be a tricky act to pull off because you inevitably run up against many headwinds throughout the process. Stakeholders and VPs continually question the priority of the initiative, PMs and Data Scientists want to change as little as possible to ensure valid experimentation results, and you’re left making design decisions without enough context from the purpose and vision of the original design.
Such was the case with Ride History, a view within the Lyft app that I’m sure you’ve accessed at some point. It’s a seemingly innocent screen from the outside as a user, but internally at Lyft, it was messy. There wasn’t a dedicated team or owner for this view and many teams had been shoving features in there without a clear view of how all the information is organized. Many had strong opinions of what the view should and shouldn’t do, while I as the designer expected to “plant the flag” of what the future of this view was as Lyft scaled to be a multimodal transportation app incorporating a lot more than just rides in the view.
Additionally, a good chunk of the work I did on this project did not make it into users’ hands. But still, it’s worth highlighting exactly how much work and thinking goes into something only to get shelved at the eleventh hour due to resource/budget constraints or top-level company initiatives changing. Designers are running into this a lot these days, but it shouldn’t take away from the fact that it’s still valuable, real design work. So I figured it’s worth writing about. Hope you find it insightful.
Context
If you’ve ever lost something in a Lyft ride or if you’ve had to report an issue about a particularly concerning experience in a ride, chances are that you’ve opened up your Ride History to look for the ride and get help on it. Lyft’s Ride History logs all of your past rides and combines rides that were taken in the same day into one charge. In the detailed view of a ride, you can see the route your driver took, see an itemized breakdown of the payment for the ride, and get support for any issues related to the ride.
The problem with Ride History
Having spent the last two years working on the support experience for Lyft users, I learned that nearly 40% of all reported issues on Lyft rides start from Ride History (with the the rest of them coming from the post-ride rating experience and direct outreach from the in-app Help tab). Despite this, Lyft’s Ride History hasn’t changed much over the years, save for minor visual updates. We prioritized a redesign of the view to solve several problems:
1. Ride History hasn’t scaled with Lyft’s evolution:
Lyft’s product offerings have nearly tripled in size compared to five years ago. We now have rentals, Lyft Pink memberships, e-bikes, vehicle repair services, and many new offerings on the way. We’ve been shoehorning all of these into the existing Ride History view without having taken a holistic look at how they all fit together, and it was time to finally address how this surface should accommodate all of these transportation offerings that go beyond a “ride” and branch into broader offerings like service, transactions, and memberships.
2. It’s difficult to find a specific ride in Ride History:
Today, Lyft riders come to Ride History to find a ride to review charges on or get help on, but unless that ride is very recent and is at the top of the view, it’s a bit of a hassle to find it. You’d need to scroll down quite a bit and recall a unique identifier about that ride to quickly identify it in the list. There is also no way to filter the view by ride types or dates to directly jump to a specific ride that you want to. And even if you do find the ride, access to help is somewhat buried and it doesn’t display any outcomes or resolutions that may have already taken place about that ride.
3. Ride History lacked visual consistency:
We display the driver’s profile photo if it’s a regular Lyft ride but we show the respective vehicle imagery for bikes, scooters, or rentals (and a vehicle image looks especially odd in a small format). New offerings don’t have a defined pattern of fitting into this model, so we needed to streamline the visual language of this view. Research has also shown us that the current display of how multiple rides in a day are charged together is confusing to riders, so we wanted to address this as part of the redesign as well.
Our framework
I partnered closely with the Product Manager to define a platform approach for this project, where we would create the template for how Ride History could scale to handle all of Lyft’s offerings. One of our first proposals was to rename the view from “Ride History” to the more generic and all-encompassing “History” so that we can display more than just rides in the view.
We laid out all the different types of rides, transactions, and services that the new “Lyft History” would need to house and conducted several interviews with internal stakeholders at Lyft across all of our lines of businesses to better understand the gaps in the current Ride History experience. Some of the biggest takeaways from these sessions were that there was an overall desire from many teams to use Ride History as an educational surface, increase clarity about potential savings and best practices, and reduce user-initiated chargebacks with their banks by providing a clear path to resolution through Lyft. We sought to address as many of these pain points as we could in our redesign.
Part I: Conceptual exploration
As we embarked on the redesign, it became clear to us that many things were unclear. For instance, the information we currently displayed in each row to identify a ride didn’t seem that useful. We showed the driver’s profile picture, the type of the ride, a Personal/Business descriptor, the pickup time, the total ride length, and the total cost. Are all of these useful in identifying a ride? If we had to narrow it down, what are the top two or three things the riders actually cared about? We decided to run an initial round of research sessions to get answers to these questions, and I started tinkering with some concepts to put in front of users for these sessions.
Initial ideation
One of the most useful exercises you can do at the beginning of each project is to temporarily ignore the business and user constraints. What are all the ways in which you could design this screen? How could this view evolve from just a boring list of rides into something totally different? This kind of freeform ideation helps surface the seeds of ideas that would otherwise never come to light. It’s important to clarify that none of these early concepts were based on insights or data, they were just explorations to test the boundaries of the problem space and spark new ideas as we continued to iterate.
Some of my earliest concepts were intentionally “out there”, one of which was a Google Maps-esque timeline view of rides taken in a given day (Fig 1). This concept loses its utility for people who only take one or two rides occasionally and has the added downside of forcing repetitive user interaction to view older rides, but regardless, there’s something interesting about seeing a breakdown of your day across different modes of transport with Lyft.
Another concept combines all rides you’ve ever taken into one densified historic routemap (Fig 2), logging total miles and places visited before going on to list out all the rides below. It paints a pretty striking visual of the places you most frequently visit and parts of the city that you’ve explored more than others, but it also becomes less useful when the majority of a rider’s rides are between their home and work/school. This concept also falls apart when you’re a business traveler who takes a lot of rides in multiple cities, forcing you to constantly switch regions to view all your rides.
The final concept (Fig 3) groups individual rides into the idea of “trips,” catering to the riders who frequently take roundtrips from their home to a specific place and back, or those who hop around a new city exclusively through Lyft. There’s a strong connection here to how our daily billing model works and aggregates charges, but it forces a big shift in a rider’s mental model to think in terms of grouped trips instead of individual rides. It also makes it more difficult to find specific rides when they’re grouped together as opposed to just seeing them listed out individually.
Filters and search
Returning to reality after some of the big-picture ideation, I decided to tackle the simpler stuff. How would filtering work in this view? What kinds of filters do we even need? Which ones would riders care about the most? Would search work better, and if so, what search queries would a rider use to find rides? We were planning to ask all of this in research sessions, but I was simultaneously putting together some early design concepts for these too.
Our Lyft Product Language design system makes it a breeze to quickly spin up iterations for a design. Working on filters bought up many questions throughout the design process, like what we should even allow users to filter on and whether they should be single-select or multi-select. Exploring filters also swiftly eliminated many of the problematic bigger-picture ideation that I was tinkering with earlier, since filtering out rides from any of those views could break the experience significantly. Simultaneously working on different problems in the same view can help ensure that a solution to one problem doesn’t cause a design conflict with the solution to another problem, especially if they need to work together on the same screen.
Visual display of a ride
Even though the grouped trips exploration didn’t go anywhere, it led to this interesting idea of using a card-based UI to display rides. These containers could cleanly delineate a ride or a set of rides in a given day, and there was something appealing about using larger visual imagery to quickly identify the ride instead of combing through ride descriptors to identify the ride, and so I went down a rabbit hole of explorations to try and display all the primary information of a ride in varying card-based styles.
After working on several iterations of potential layouts, I felt like I had something worth putting in front of users as we interviewed them about identifying rides during research sessions. I landed on a model where regular Lyft rides would show the vehicle imagery along with the driver photo, whereas bike rides, scooter rides, and rentals would show just the vehicle imagery on the right. Giving more visual prominence to the vehicle imagery felt like an interesting approach, and I was curious to see how this would test with users.
As a side note, I sort of ran out of time to try and incorporate the additional types of offerings in here. What would service visits and Lyft Pink membership transactions look like here? Would they fit into this heavily visual redesign? I wasn’t expecting the iteration for individual rides to turn into a deep exploration involving several rounds of iteration and feedback, so we decided to temporarily descope those offerings and come back to them in the second round of design revisions (more on that later).
Concept testing and feedback
I put together an interactive prototype that our amazing UX Researchers tested with real Lyft riders to gauge their reaction to the new designs and better understand how they thought about past rides. The imagery-focused approach seemed to work, but at the detriment of clarity. Riders didn’t seem to understand why some rows were showing driver photos but others weren’t. They didn’t make the connection that rentals only displayed the vehicle image and rides displayed the driver photo in addition to the vehicle image. In short, users weren’t reading the text descriptors but were only looking at images to identify the rides.
We also learned that filters titled “Rideshare” didn’t mean much to riders who exclusively used Lyft for just rides to and from places (which is a significant portion of Lyft’s userbase). They suggested just calling this filter “Lyft rides” or something clearer. Many participants also called out that daily billing total amount and the payment method took up a lot of space on the screen, while also calling out that it’s not immediately relevant to their needs when coming to this view to review past rides. Finally, all participants quickly and instinctively understood the transition of “Ride History” to “History,” increasing our confidence in renaming the view as we added more offerings.
I also presented these designs internally to our Design Leadership Team, which was another great forum for visibility into the work. Their feedback was that this imagery-first approach isn’t quite solving the inconsistent visual language problem, with the images still causing the viewer’s eyes to zig-zag all over the place as they tried to figure out why some rides look different than others. The Design Leadership Team also encouraged me to really question if the vehicle image is a strong visual anchor for riders to recall past rides or not, because we needed to justify the increased visual prominence given to the vehicle imagery. Lastly, they reiterated the transactional and utilitarian nature of the view as a place where riders come to review past charges and get help, which meant that we should likely strive to maintain a receipt-style list of rides with charges on the right side and potentially explore clear, streamlined iconography to represent the variations in offerings instead of using flashy, visually heavy cards that could feel extremely overwhelming in stress cases.
Part II: Refined iteration
As it is with most design work, you won’t get it right the first time. The concept we had was primarily to foster insights and discussion about what we should or shouldn’t be doing in this redesign, so we were now armed with lots of great research findings and internal feedback to properly tackle the design. I split up the work here into three broad buckets to tackle in chunks:
- Daily Billing
- Filtering
- Iconography
1. Daily Billing
I wanted to dive deep into how to visually indicate charges that were combined together. To save riders money on swipe fees charged by credit cards, Lyft aggregates all the rides you take in a single day and charges your card once at the end of the day. The way we display these in Ride History today is not intuitive to users, especially when there’s multiple payment methods being used in a day across personal and business profiles.
In discussions with the Pay team at Lyft, we learned that only high-usage, high-volume offerings would be combined and charged together. Other low-volume offerings like rentals, that have high per-transaction costs but are used infrequently, would never be combined and charged with other rides as part of the daily billing model. Business rides would also never be combined together in daily billing, since those use a different payment method. This added an extra constraint to the Lyft History designs, since the view now needed to work for offerings that may or may not be charged together as a combined charge.
I began exploring ways to maintain the receipt-styling with charges on the right side while also trying to indicate combined charges in some form. I explored several options where we didn’t explicitly call out which charges were combined together (Concept A), called out combined charges in the middle of the rows (Concept B), and pushed the complexity of Daily Billing into an entirely separate view buried one level deeper (Concept C).
Our Pay team partners were quick to point out that we had past research that indicated a rider preference for seeing the exact combined charge amount on the main view, which immediately eliminated the third option (Concept C) as a viable approach. To understand why, let’s paint a picture. Alice, a Lyft rider, takes three rides in a day and is charged a combined total of $60 for those three rides. Alice will see $60 charge from Lyft in her card’s bank statement. If Alice isn’t aware of the fact that it was a combined charge for three rides, she’ll come to Lyft’s Ride History looking for a $60 charge. If she doesn’t see the $60 charge, she’ll dispute the charge with her bank, resulting in a costly and expensive chargeback for Lyft. Many riders want to see the exact numbers they’re seeing in the bank statement matched one-to-one in the Lyft app, so it was essential that we display the combined charges on the main History view.
As I was exploring various ways to display combined charges on the main History view, I was running into several issues. We still needed the individual ride or transaction details to be accessible from the main view, since we needed riders to be able to quickly access the detailed view of a ride. I also needed to clearly indicate to riders that the combined charge is not an additional charge but instead just the total of some of the individual charges in that day that were combined together. This was a tricky design problem. I explored ways to emphasize the combined charge rows more than the individual rides by differentiating the typography and visual density of the rows, but it still wasn’t coming across as clearly as I wanted it to.
While looking for design inspiration, I ran in to some interesting examples of other products trying to indicate related content in a high density view. Twitter uses line connectors to visually link conversation threads, guiding the viewer’s eye to a reply on a specific tweet and making it easier to follow along a train of back-and-forth replies. It even handles accessibility issues well, with screen readers reading out “Replying to…” when they hit the line connector, allowing blind or visually impaired users to follow along with the conversation in the same way sighted users can. So I gave it a shot in my design.
The connector lines seemed to work fairly well as visual links that indicated combined charges. I tried a few variations, some of which looked too much like branching paths while others felt too much like an activity timeline. Overall, I was trying to ensure that uncombined charges would stay separate without the line going through it while the rest of the combined charges would have the line passing through it.
Even with this connector styling, another big problem I seemed to run into with the differentiated density and visual styling for combined charge rows and the individual offering rows was the transition when certain offerings are filtered out. We were adding filters to the view, so what happens when the user filters out an entire type of offering? The “Combined charge” would be inaccurate and wouldn’t match the sum of the charges, so we’d have to remove it. Then what happens to the styling of the condensed offering rows within a combined charge and the default offering rows that weren’t combined? We’d have to maintain two different list item styling as filters are added and removed, contributing to rapidly switching layouts and re-ordering of the rows, adding to even more confusion. So I decided to kill the differentiation between rows and keep it all consistent.
In the final proposed daily billing grouping, I had all the offerings maintain the same styling regardless of whether they were part of a combined charge or not. This way, the only changes when filters are applied would be that the connector lines disappear and the combined charge rows disappear. We’re then left with a static list of offerings that the user filtered by. We don’t have things changing their visual display density anymore based on whether or not filters are applied. This also made good UX sense because once a user starts applying filters, their use case has changed from reviewing combined charges to finding a specific ride.
The Pay team loved the new direction. This visual connector for combined charges made it immediately clear which offerings were and weren’t charged together in a single transaction, while also elegantly maintaining the design language when users applied filters to find individual rides. Overall, I was also pretty content with how it managed to stick to the receipt styling while improving the comprehension of our daily billing model.
2. Filtering
Speaking of filters, this was the next big chunk of work I wanted to focus on. There’s three main use cases we had identified for filters:
- Finding a specific old ride to get help on (or report a safety issue on)
- Finding a specific Personal or Business ride to fix misattribution (for users who may have mistakenly taken a Personal ride on a Business profile, or vice versa)
- Reviewing charges for offerings of a certain type to ensure accuracy (ex: filtering by bike rides to quickly see all bike charges at-a-glance)
Our first goal here was to figure out which filters would be most useful for riders. Thankfully, we had great insights here from our initial round of research. We knew that we’d keep the Personal/Business filter that already existed on the view, since it solved the misattributed rides problem. We wanted to add in a “Type” filter that would allow users to filter by offering type, narrowing down the list significantly when riders filter by a specific transportation mode. We also wanted to add timeframe options to filter the list by, allowing users to select from rides within a date range or just see rides taken before the last year or last few months (with the justification being that recent rides are easily accessible by simply scrolling for a bit). Initially, we assumed that adding a star ratings filter would be useful, hypothesizing that low-rated rides would correlate to rides that likely require support issues, but discarded the idea after some digging into data insights revealed that there was no link between ride rating and support tickets on a ride.
One of the tough design decisions I had to make here was whether or not we should offer a multi-select option in the Type filter, or if they should all be single-select. I could not think of a use case where a rider would want to filter by bike rides as well as rentals to view all of their bike rides and rentals at the same time. Researchers, Product Managers, and Data Analysts at Lyft also backed up my theory that there isn’t a strong use case there, so I decided to keep them all single-select only.
Another tricky filtering decision was the timeframe filter. My first choice here was to offer options in buckets of time going back from a month, i.e, allow filtering by “Older than a month” vs “Older than 6 months,” etc. This confused every single person I showed it to internally, with everyone questioning why we weren’t just saying “Within a month” vs “Within the past 6 months” and were instead offering the reverse. My answer to this was that recent rides within the past few weeks or month could easily be accessed by scrolling down a bit in the view, but finding specific rides that are older required a lot more scrolling, so an “Older than…” filter elegantly solved that problem. Gmail offers a timeframe filter exactly like this for the same reason. Even though people understood it after I explained it, it wasn’t a good sign that it seemed confusing at first sight and always needed further explanation (which is typically an indicator of it needing to be reworked). So I changed this to be a custom date range filter, allowing users to pick specific buckets of time to create their own timeframe ranges to filter by.
The final proposed filters list worked as an “OR” filter within each filter bucket and as an “AND” filter across the filter buckets, i.e., you could only pick one filter within each group and apply them in combination with the other filters. We felt that this MVP set of filters would provide a robust enough set of options for users to filter by and find specific rides. The “All Filters” view displayed the same set of filtering options that could all be selected and applied at once instead of individually triggering the quick filter panels. I also created empty states, along with special variations of empty states for Lyft Pink and Lyft Business, honing in on those team’s desire to use these surfaces aa educational entry points to those offerings. A special thanks to Kevin Kwong from our illustration team for these amazing brand illustrations!
3. Iconography
It was finally time to fill in those empty gray circles with icons. We already had several icon sets in our illustration library, courtesy of LPL. My task here was to just figure how to best incorporate them into this new layout in the way that clearly distinguishes offerings from one another.
There were many ways to go about it, but I ended up liking V1 the most (as did the rest of the team). The filled-in circular frames drew less attention to the outline while still providing a base for the icons, and avoided the issue of looking too much like a route line or activity timeline. The connector lines also played the most nicely with this version, so I ended up sticking with this in the final design. Internal stakeholders encouraged me to stress test this design in states where riders typically use the same offering, say for example, riders who only take Lyft rides and never engage with any other mode of transportation offered on Lyft. We did this, and it revealed another big problem with the design.
For riders who often engaged with just one type of offering (like just Lyft rides), there’s almost no visual differentiation in the view. All of them would have the car icon and all of them would say “Lyft Standard.” At least in the old design, the driver profile pictures provided a bit of visual differentiation (although their usefulness was debatable). Now, we’re relying on the date, time, and price to do all the heavy lifting of differentiating the ride. To address this issue of visual sameness, I shared the designs with the rider team at Lyft to try and come up with a solution.
The rider team had a great suggestion. Instead of solely relying on the mode name of the ride, we could also display the destination address for the ride. According to past research, the requested destination is a strong mental anchor for riders to recall past rides, so this served as an additional piece of differentiation for rides. I was debating whether to keep this as the primary text or display it as subtext, so I had two versions to concept test here.
At this point, I shared out the designs with several internal stakeholders across almost all the different lines of business at Lyft, made some minor tweaks and edits based on feedback, and put together a refined prototype for concept testing.
Concept testing
Our objectives with this round of tests were to assess how well riders understand the new daily billing model in the new designs, gauge how they feel about seeing iconography as compared to the old driver photos, and get a sense for how well they’re able to use our proposed filters to find specific rides. In the concept tests, we had actual Lyft riders go through tasks like looking up all of your bike rides in a given month or finding a business ride you took in February of last year, which were all aimed at seeing if they’d utilize our new features to accomplish the tasks.
All riders understood what the connector lines represented, as they were able to correctly identify which offerings were charged together and which weren’t. All riders found the filters to be intuitive and useful, with some proposing to rename the “Time” filter to “Date” since they initially assumed that time literally meant the time of day, for which they weren’t entirely sure if a filter was necessary. There was no desire from riders for a multi-select option in the “Type” filter, validating our initial assumption that there wasn’t a strong use case to warrant it in the first place. Most of the riders didn’t seem to mind that driver photos were replaced with icons of the transportation mode, with some asking if they could still see the photos in the detail view (which they could) to ensure accuracy.
The destinations visible in the History view also received positive feedback, with riders appreciating the extra level of detail now available in the view. Some were rightfully confused as to whether this was a pickup or drop-off address, especially because the time we show next to it is the pickup time. We addressed this after the sessions by adding a “to” in between the pickup time and the drop-off address so that it now read as “9:06 AM to 250 Geary Blvd,” eliminating any ambiguity about pickup or drop-off times and addresses.
Finally, I worked with our LPL design systems team to streamline the visual styling of the filter buttons. We updated the contrast in the selected state to comply with A11Y accessibility guidelines and created a component system where filter buttons could be used with or without a menu-style option that popped up a quick-select menu on tap. Filter buttons could also be used with or without icons. This redesign was one of the foundational projects that kickstarted the need for filtering across all of Lyft’s offerings.
After making the minor design updates, I presented the final designs a second time to our Design Leadership Team and we also shared the work with our VPs and Directors on our immediate teams. Everyone was on board with the new direction and appreciated our user-centricity and tight collaboration between design and research throughout the process. Overall, it took about six months from beginning to end exploring, refining, iterating, and testing the designs with users while also frequently sharing and communicating progress internally. I’m pretty happy with how it turned out.
Disclaimer: As of Dec 2022, this view is not live in the Lyft production app. You’ll probably still see the old Ride History view in your Lyft app. This milestone of the project got deprioritized due to changing company initiatives, so these designs never quite made it into the implementation phase. More on this at the end of the post!
Part III: Sweating the details
That wasn’t all, though. Throughout this process, I was also simultaneously working on the Ride Details view, which is accessed by tapping into a ride from the main History view. This screen had an entirely different set of problems, so I’m diving into it in a separate section.
Once users had found a specific ride from the main History view, we needed to present the most relevant and actionable information about the ride. Our Ride Details view hadn’t ever changed from the first version that was shipped years ago, so this was a great opportunity to significantly overhaul the experience to better cater to rider needs.
The first thing I did was take a pass at the order and presentation of information in this view. Are we showing the most relevant stuff that riders need to see here? How much are we making them scroll to get to the important things? I blocked off different sections of the screen into “modules” that we could re-order as needed based on the type of offering. We were also planning to use these in research sessions and have riders order the modules themselves based on what they felt was most important in a participatory design exercise.
Something that we constantly heard from internal stakeholders about the Ride Details view is that access to help felt “buried” at the bottom of the screen. So naturally, some of my early explorations involved making the help CTA more prominent and placing it higher up on the screen, along with restructuring the view to better display relevant information about the ride in a logical hierarchy. I experimented with various layouts to see if it access to help would start to feel less “buried” or not. A big question on my mind throughout these early explorations was relevancy: what are the top things that riders care about and need to see here, and how should we best present that information? We decided to dig really deep into these during our research sessions.
The module-based approach of structuring related content into their own section of the view seemed to work really well. The “ride” module scaled neatly from Lyft rides to bike rides to rentals, and the rest of the view was able to evolve according to the needs of every individual offering, so I kept pushing this idea forth. I still had doubts and unanswered questions about the placement and ordering of the modules as well as the prominence of support, but these were all to be answered in concept testing.
Another important factor in the design principles was to ensure that we’d be able to scale this view to handle shared rides. We wanted to start displaying co-riders that may have been in the ride with you in order to enable safety reporting in addition to displaying co-rider pickups and drop-offs on the map. Due to privacy concerns, we eliminated displaying exact pickups and drop-offs on the map, but we continued to show co-rider photos and first names in the Ride Details view to ensure that any safety incident could be accurately reported from the Ride Details view. I experimented with a dynamic reporting flow but eventually scrapped it for a version that pushes uses further into a dedicated reporting flow that can capture the incident details in a more comprehensive manner.
Finally, we were sensing a lot of desire from other internal teams to use Ride History as an educational surface, so I also explored some ways to display informational banners in the relevant offering, showcasing how the view could scale over time to include this. Lyft rides could display other ride modes that the riders don’t frequently use, while bike rides could proactively mitigate riders being surprised by high fees. Having the ability to display these in Ride Details reassured our cross-company partners that this redesign has a lot of potential for rider education.
Refined iteration
In our first round of research sessions, we did a participatory design exercise where we asked riders to order the modules based on the information that they’d like to see. Eight out of ten participants had the exact same ordering, with the Trip information at the top, followed by Payment, Ride, and Help. Most of them called out that they’re used to seeing help links at the bottom of the view in other products, adding that it’s helpful to go through the other modules and verify the information first before deciding to contact help. As a result, I re-designed the view to match their expectations.
I also extended our platform approach to the Ride Details view, ensuring that this module-based framework scales to all of Lyft’s current offerings including rentals, bikes, scooters, self-driving rides, and vehicle service visits. Transactions like Lyft Pink membership fees and Lyft Cash purchases didn’t have a dedicated “detail” view and would instead link out to different sections of the app, so we left that out of the designs. We also heard a desire for riders to want to be able to resend a ride receipt to themselves (which previously required reaching out to a support agent), so we included a way to do this in the new designs.
In response to user feedback, I also added several variations of modules to handle support outcomes. Automated resolutions and assisted support contacts would now display in the view, with fare-related outcomes showing in the Payments module and other support-related outcomes displaying in the Help module. The Ride Details view now dynamically evolved with the post-ride support outcomes instead of just keeping the static receipt-like layout that it formerly had. Overall, the addition of all these features means that riders will be able to self-serve and self-resolve their most common issues or points of confusion instead of needing to get in touch with a Lyft support agent. Tracking this decrease in support outreaches was one of our success metrics for this project.
There are many, many micro-variations of every module here, changing states to handle uncommon scenarios like stops during trips, multiple payment methods, banners and callouts for certain situations that can happen during a ride, and time-based triggers like changing payment methods or tipping that disable and update the UI after some predetermined amount of time. As with the former designs, we extensively reviewed these with all internal teams at Lyft to ensure that it was a scalable solution that we could build new offerings on and got the necessary approvals to finalize and build out the design.
Scaling Lyft History
We broke out the projects into milestones, starting with the Ride Details view and then the Lyft History view. The redesigned Ride Details view made it into the app and is currently live on both iOS and Android (as of Dec 2022). The redesigned Lyft History view did not make it into the app due to changing company priorities. When this project started, Lyft’s priority was to evolve Ride History and scale it to incorporate all of its multi-modal offerings. Six months into the project, the company priorities had pivoted to solving the pressing driver supply concerns. Something had to give, and this was one of the projects on our team that got shelved, unfortunately. We completed the design phase, but the project didn’t make the cut to get into implementation.
Compared to what it looked like before, the History view is far more visually streamlined. Arguably, it feels less “human” than it did before since we don’t display driver profile pictures anymore, but at the same time, the feedback we were getting from riders was that the pictures weren’t exactly useful in recalling the ride. Riders used information like date, time, and destination to recall past rides. More importantly, the view now scaled to handle all of Lyft’s current offerings elegantly while also clarifying how our Daily Billing mechanism works.
I’d like to give a special shout-out to everyone at Lyft involved in this project, without whom it wouldn’t have been possible: Carolyn Buehler, Aneri Chouhan, Elyse Hovanesian, Nicole Pearce, Ella Werthan, Ernesto Lucar, Bomee Park, Jeffrey Chen, Igor Fedulov, Nico Magana, Jiaqi Wang, AnnaMarie Garlin, Chuanxin Hu, David Wu, Gagan Singh, Elizabeth Hamp, Nick Creegan, Stephanie Carpenter, Gemma Morgan, Guillermo Torres, Brian Ng, Rafae Aziz, Jen Williams, Johan Jessen, Megan Ellis, Nayeon Kim, Kari Bergstedt, Cooper Smith, Sravanthi Kadali, Eunice Joung, Eric Burdullis, Ashwin Raj, Audrey Liu, Kevin Kwong, Amanda Schwartz, Conor Buckley, Runi Goswami, Michael Yom, Jeremy Dizon, Linzi Berry, Alex Lockwood, Alina Yehorova, and Ievgenii Pogosian.
Despite the fact that the main Lyft History view did not ship, I’m still really proud of the work we did and how it turned out. In today’s tech landscape, it’s become really common for companies to scrap ongoing initiatives and take on the more pressing challenges instead, which inevitably causes a lot of thrash for designers who have been working on a problem for months or even years. Nevertheless, the designs for this project are ready to go, whenever this initiative becomes a priority for Lyft again. It might require yet another redesign if regulations or Lyft’s offerings have significantly evolved by then, but oh well, you can only control so much as a designer. I’m still happy with the design work I did and how the final design turned out, regardless of whether or not it makes it into the Lyft app.
I hope this has been insightful and has shed some light on the design process for a project of this size and scope; please feel free to reach out if you have any questions about any of it. Happy to answer them! Cheers.
