Scaling Design: Building Lyft’s plug-and-play payment system
Nothing erodes customer trust faster than a broken payment experience — it needs to work every time. So designing a system of payment components is understandably daunting, requiring a seamless user experience, integration with existing systems, and impenetrable security. Here, we’ll explore aspects of creating a centralized payment system, best practices, and pitfalls to avoid.
In late 2021, our Pay Team at Lyft set out to build a new payment system. We wanted any product team — no matter their payments expertise — to quickly, elegantly, and securely build payment solutions for any use case. Before this, teams independently figured out how to build payments and integrate them with our complex backend. Each team designed, built, and maintained payments according to different requirements. Around this time, our company expanded our product offerings, so multiple teams needed to spin up new payment experiences quickly — something that wasn’t possible with our previous landscape of disparate payment experiences.
Creating a centralized payment system and making it extensible for use cases across Lyft promised many benefits, like scalability, unified user experience, faster development, and stronger security — but how?
Start with systems thinking
Building a payment system helps if you already have a centralized design system. It can be a huge initial investment to create a payment system, and may be fruitless if you lack the process or resources to maintain it. Even if you don’t already have a design system (or your design system doesn’t currently have a lot of adoption) — prioritize usability and sustainability over an exhaustive component set.
For us, this meant asking strategic questions early on like:
- What are the most valuable (i.e. most commonly reused) components or patterns?
- What are the guiding design principles that govern every payment experience at Lyft?
Answering these questions helped us sequence and prioritize the requisite work for this project. Rather than build over-engineered, Frankenstein amalgamations of custom components, we leveraged existing design system patterns like List Items and Dropdowns and composed them into payment components, designed with our payment models in mind.
We also asked ourselves tactical questions like:
- Who will maintain these components long term (i.e. Pay Team or Design Systems Team)?
- Where and how can teams get support for using the payment system?
- What makes the cut for the initial set? What happens if/when teams need more components than the initial set?
Building new things is fun, maintaining them long term — not so much. Clearly defining what long-term maintenance means helped keep our scope clearly defined. A strong partnership also sets up our system up to live on even as products or team members come and go.
Radically prioritize
So you’ve decided to build a system — what next? To build a system that replaced legacy and custom flows, we needed to identify the most common use cases and patterns, or in other words — audit. In all, it took two months to complete an exhaustive audit of our payment experiences, ranging from every “add credit card” flow to the most esoteric payment authorization failure screens. At the end we had A Beautiful Mind-esque visual map we called our Pay Source of Truth.
Systematizing components from an audit is an exercise in taxonomy. It means dissecting screenshots, grouping like elements, naming them, and then creating a short list of components. For us, while some repeating patterns like checkouts and receipts were easy to classify, others weren’t — like variable pricing and deferred payments.
Once you’ve audited, it can be tempting to solve for every use case and replace all your patterns 1:1 with a system solution. This can be a north star goal but don’t make the mistake of conflating an audit with project scope. Instead — radically prioritize what pieces of the audit go into your system.
Our Design Systems team prioritizes using a rough formula:
Evaluating and prioritize each pattern/component through multiple lenses:
- How many times is this pattern/component used? How many teams use it? How visible is it to users? (Demand)
- How much time or effort can we save other teams by systematizing this pattern/component? (Cost Saved)
- What impact will this pattern/component have on the team/users/business with code quality, UI consistency, accessibility, reduced support cost, higher conversion?(Quality Increase)
- Are one or more teams currently working or planning to work on a feature that could use this component/pattern? (Incentives & Deadlines)
Define your governing principles
For all your prioritized use cases, create governing principles. This helps all team members quickly understand the non-negotiable qualities that all payment components must have. For us, these principles were:
- Transparency & trust
- Control & flexibility
- Context
These principles (as well as other shared values we developed) provide team members with the right context and empathy when building payments.
Meet your system users where they are
To maximize the chance your system will actually be used by others in your organization, build your system into their existing workflows and tools. Determine the tools and processes that make up your system, and make deliberate decisions about where they’ll live, be maintained, and grow.
Since we built our payment system on top of our existing design system, we used the same tools — like Figma Libraries, our internal documentation site, and our design systems Slack channel. Regardless if you have design system or not, consider factors like:
- What tools do designers & engineers already use? Where can you house a shared library of components and its documentation?
- How will you collect feedback from product teams, answer their questions, and gather new ideas?
- How will you maintain your components, fix bugs, and communicate updates to the teams already using your system?
- How will you expand your system with new patterns, components, and capabilities?
Work with partners along the way
Don’t make the mistake of building your system in a silo. Instead, find partners as you create your system. We approached designers from five teams (each with an active payments use case), and asked them to beta test our components to make sure they worked in Figma.
But to really ensure your system works, test it in an actual live use case. One of our partner teams and their designer, Eunice, was ready to take this step. Her team committed to designing, building, and launching multiple new products in 2022 using our payment system.
By starting with a smaller set of partners, you can align incentives, meaning:
- We ensured our components were actually usable before making it more widely available.
- We demonstrated our system was scalable for multiple use cases (helpful for getting leadership/stakeholder buy-in).
- Partner teams launched their products in accelerated timelines.
Closing thoughts
While daunting at first, we launched our payment system in 2022 in conjunction with multiple key product launches. In fact, our payment system not only enabled but also accelerated these launches. Since then, we’ve seen incredible adoption. Designers from 13 teams have inserted our components into Figma over 10,000 times, and our components have been integrated into nearly 10 shipped products.
What worked for us may not work for everyone (each organization is unique), but we hope this sparks a conversation around the systems you build for your organization. Do you have questions about payment systems? Does your organization use one? Leave us a comment below!
This article was written by David Wu and Runi Goswami, two members of Lyft’s Design Team. You can read more articles about how we build and maintain design systems at Lyft here.
Huge thanks to the nearly 30 current and former team members who have been involved in this project in special ways. Interested in joining our team? Check out our open roles!
