Building a Rider App Platform Team
The Lyft rider app is bigger than it’s ever been, with dozens of designers working on the core rideshare flow. With each new feature and improvement there became more overlap between teams’ work. The question arose: “With limited screen real estate, how do we scale?”
Problems at scale
Having worked on the pickup experience, I’d previously contributed custom components to our ever-expanding library. Over time I noticed that similarly custom treatments from other teams were making designing for the panel component — and maintaining consistency—particularly tricky.
Newly introduced surfaces like the banner allowed for introducing different communication use cases, but quickly became inundated as the popular alternative to managing the complications with a hardcoded ride panel.
Finally, without clear guidance on how to manage overlapping of features, we ended up with UI often lacking a clear focus or opinion, unable to clearly articulate the most crucial piece of information in any given view.
The vision
The ride panel as a legacy component lacked clear ownership, and its code utilized both client and server. Thus, the goal was not only to clean up the visuals, but also update it to be entirely server-driven, and ultimately a self-service product which any team could easily plug into.
How we got there
Lyft’s Product Language (LPL) team designs for the atomic components utilized across the company’s various platforms, and its documented principles were the perfect starting point to propose a formal ride-screen platform team.
Referencing LPL principles, an app-wide audit, and a vision for a more robust ride-screen service, the case was made cross-functionally to invest in cleanup, updated documentation, and a roadmap for gradual migration.
The proposal
In defining the current states of the ride and categorizing the content within each state, the panel rows were broken down into the following:
- Critical — Used to convey information prioritized over the map, and includes imagery or large-formatted text. Used sparingly based on ride state.
- Instructional — Communicates an upcoming action. Information displayed here should be immediately actionable in the current ride state.
- Primary — Default state conveying informative content relevant to the ride, and appears the most frequently. Unlike the critical row, should not compete with map for screen real estate.
- Secondary — Visually subdued in comparison to instructional and primary. Content should remain concise.
All of these could be modularly swapped in and out depending on the state of the ride, as opposed to having to define and hardcode each permutation.
Each row was styled in collaboration with designers who introduced or had previously worked on it, and then componentized in the Figma library. Usage of the rows, their potential interactions, and a catalogue of when and where each row appeared was also documented and shared out.
Within this documentation was an emphasis on maintaining a holistic view of the ride panel, both in its collapsed and expanded state. Doing so would keep the most relevant information above the fold and at the top, with more optional flows discoverable below the fold.
Building upon the foundation
This standardization got us thinking about the future of the panel real estate, but also made us question the state of some legacy components which lacked attention over the years. One such example was the action button row, which received exploration into different visual treatments.
Other teams were able to design for expanded panel space that was previously underutilized, resulting in a new and improved in-ride content feed. New panel interactions like inline banners, pagination, and optional flows have also been introduced.
What this unlocked for us
In addition to the creation of a cross-functional platform team which now owns the ride screen…
📈 Experimentation rate: What was once 2–3 weeks of work was now possible within days, allowing for quick experimentation in updated copy and other lightweight visual changes
⏱ Conditionals: Changes in time, distance, etc in response to dynamic environmental factors became a possibility with this server-driven approach. We could now communicate shifting content based on real-world factors.
💾 A single source of truth: A shift from 2 slightly deviating client codebases to 1 unified server codebase, as well as collaboratively maintained design documentation.
As Lyft continues to scale it becomes increasingly important to identify areas of overlap and opportunities for collaboration early on. Keep an eye out for future improvements to the ride panel architecture! Interested in learning more? Let’s chat.
