Learning Led the Way

When I was asked to lead the design system’s typography workstream for Lyft’s latest rebrand, I knew I was stepping into a highly complex initiative that would require both deep learning and strong cross-functional alignment.

Eight years into product design, I understood hierarchy, accessibility, and how to build a solid type ramp. But this workstream wasn’t just about selecting sizes and weights. This meant partnering with brand and agency teams to help shape a new typeface from the ground up — one that would express Lyft’s evolving identity while also creating a more cohesive, legible, and scalable experience across every surface we design for. My role often meant bridging brand ambition with product reality, ensuring creative decisions could translate into an accessible, scalable system that designers and engineers could confidently implement.

Needless to say, imposter syndrome showed up right on cue. It was the kind of assignment that makes you acutely aware of the edges of your knowledge. Would I be able to hold my own in conversations with typographers? What could I meaningfully contribute? And, if I’m being honest, what exactly was kerning?

But instead of shrinking back, I leaned in. Because if there’s one thing I’ve learned, especially now, in the age of AI, it’s that the most valuable skill isn’t knowing everything. It’s knowing how to learn fast, ask better questions, and navigate ambiguity with intention.

“Focus on being a 10x learner, not a 10x doer.” When Zevi Arnovitz, PM at Meta, said this on the Lenny Podcast, I had to pause and replay it. In one sentence, he captured something I’d been circling for years. This mindset has quietly shaped how I move through my career. Feeling out of my depth doesn’t scare me, it excites me. When I’m staring at a new problem space, I’ve learned to recognize the signal: a growth spurt is coming.

And in this case, that growth started with a simple exercise: mapping every typography question I had and turning uncertainty into a learning roadmap. In this article, I’ll share that typography learning roadmap, outlining the key areas that helped me move from surface-level knowledge to systems-level understanding, for anyone looking for a structured way to deepen their typography practice.

Blank slate to action plan

When I need to go deep on something new, I start with what I’ve learned works best: asking questions.

I opened a FigJam and held a brainstorm with me, myself and AI. The only rule? Write down every single question I had about typography. No filtering. No judging. No prioritizing. For typography this looked like:

• What are variable fonts?
• What is the history of letterforms?
• Is accessibility really just about font size, or are there deeper metrics that determine legibility?

But I recommend this approach for literally any big topic you feel imposter syndrome about.

As a systems designer, my instinct is always to zoom out and see the whole landscape. I wanted to surface the unknown unknowns — the gaps I couldn’t yet articulate but could feel.

So I timeboxed it. One week. Because without constraints, curiosity can spiral forever. Every time a typography question surfaced, I captured it. I gave myself permission to stay in inquiry mode and deferred solving anything.

Then something shifted.

The task felt less daunting. The ambiguity became structured. Patterns started to emerge; clusters of technical questions, philosophical questions about taste and brand expression, operational questions about scalability.

By the end of the week, I didn’t have answers. But I had something more powerful: a learning roadmap.

The Learning Roadmap

Now that my questions were organized into themes, I could begin researching without trying to boil the ocean.

What started as scattered curiosity had crystallized into a focused learning agenda. The questions naturally clustered into three areas: foundations, systems, and implementation.

Foundations: understanding typography itself

Before you can redesign a typography system, you need to understand how type works both historically and structurally.

The history of type
Understanding how typography evolved helps ensure a new typeface feels intentional and aligned with the brand’s voice.

The anatomy of letterforms
Knowing the structural parts of type allows designers to evaluate legibility, get playful with forms and collaborate more effectively with typographers.

Accessibility beyond font size
Legibility depends on more than size — factors like contrast, weight, spacing, and x-height all impact readability.

Competitive landscape analysis
Studying how other companies use typography reveals patterns, differentiation opportunities, and potential pitfalls.

Systems: designing typography at scale

A rebrand isn’t just about choosing a font — it’s about creating a system that works consistently across products and platforms.

Variable fonts and their capabilities
Variable fonts enable more flexible, responsive typography while reducing performance costs across platforms.

Typography scales and systems
A rebrand requires a cohesive type scale that maintains hierarchy and rhythm across products and surfaces.

Platform considerations — dynamic type and responsive typography
Typography must adapt across devices and platforms while supporting accessibility features like Dynamic Type.

Implementation: bringing the system to life

Even the best typography system only succeeds if it can be implemented smoothly across design and engineering.

Rebrand migration strategy — from Figma libraries to production code
A new typography system must translate cleanly from design tools to code through tokens, documentation, and rollout planning.

The Impact

All of that structured curiosity paid off.

The typography system we developed launched across multiple products and platforms, reaching millions of users. Along the way, we reduced style inconsistencies, streamlined implementation between design and engineering, and built a scalable foundation for the brand’s next chapter.

This article is the first in a series where I’ll go deep on each of the above themes — the technical rabbit holes, the stakeholder negotiations, and the messy realities of migrating typography across platforms and products.

Did you know early printers used standardized type sizes to create hierarchy long before modern typography scales existed? Up next in this series: The History of Type, where I explore how typography’s past shapes the systems we build today.

Special thanks to Runi Goswami, David Cox, and Justin Gabbard for their time, thoughtful feedback, and editorial support on this article.

Typography Foundations: Building With a Learner’s Mindset was originally published in Lyft Design+ on Medium, where people are continuing the conversation by highlighting and responding to this story.

To celebrate National Dog Day in the U.S., we launched Pet Rides, a new offering that connects passengers traveling with their pets to animal-loving drivers who appreciate having furry companions along for the ride. While our work often prioritizes the core experience, we believe it’s essential to design for a variety of rider and driver needs as part of our commitment to inclusivity. For us, Pet Rides isn’t just a new ride type. It’s about building a better community — where passengers can travel stress-free, not only with friends and family, but with beloved pets like Aulait, Howie, and Harper.

To bring this highly-requested feature to life, we formed a passionate, agile cross-functional team from multiple internal organizations. In this article, we’ll share some insights about what made this crowdsourced project possible, and from a design perspective, how we set up a successful team to craft our user-obsessed Pet Mode experience.

Setting up a lean, effective team

To get the project started, our small, but mighty dedicated Pet Rides team drafted a three-phase plan which prioritized individual responsibilities. Since it started as a passion project and each team member only contributed a portion of their time, this approach allowed everyone to continue focusing on their primary roles across the company, and still meet deadlines for a successful Pet Rides launch.

Phase 1: Early investment and alignment across organizations

In our initial phase, we focused on understanding project feasibility within our target launch timeline, and gathered insights from individual iterations of the pet mode idea from over the years. We shared product requirements along with our proposed user experience designs with various stakeholders across rider and driver teams to garner support. We also set clear expectations for resourcing, and identified what we needed to build a prototype compared with what could be developed for our official launch.

Phase 2: Building and demoing the concept at our company-wide hackathon

We chose our annual hackathon as the perfect opportunity for the team to fully immerse themselves in a project they were passionate about. During the three-day event, we built and tested the core experience, and then created demo videos to pitch the idea and generate internal excitement. Visualizing the concept and demonstrating how the feature would work helped us gain support from more partners, including the product communications and social media teams. It also helped us secure the needed resources for our launch.

Phase 3: Execution management

After sharing our proof of concept, we entered the most meticulous and time-sensitive of our product phases: pre-launch execution. This phase of the project was expertly led by Parul (engineering) and Polly (TPM).

1. We hosted weekly team stand-ups to track our progress, and discussed the feasibility of our launch plans to ensure everything was in place for a successful rollout.

2. The team developed and managed a Gantt chart to monitor task ownership and progress.

3. We also identified gaps in our workflow and brought in resources from other teams, such as support, brand, and communications.

“Pet Mode was a shining example of cross-functional collaboration at its best, with teams across design, engineering, product, science and brand teams working together to get things done with low overhead. The enthusiasm was palpable as all of those involved strived to make the experience as paw-sitive as purr-sible for all of our users! ” — Polly Peterson (TPM)

Crafting the Pet Ride Experience

Our core objective for Pet Rides is to seamlessly connect passengers with drivers who welcome pets in their cars, eliminating the anxiety that stems from having your ride canceled and the stress that it adds to your journey. While the overarching project goal is clear, the nuances of balancing both driver and rider experiences require careful consideration. Here are three key aspects of our design process, where we leveraged systems thinking and a human-centered approach to create the final experience.

The core experience and setting etiquette

When we began to explore ways to convey the essence of a pet ride in-app, we considered various treatments like a feature opt-in, or even as a personalized note to the driver to let them know the rider is traveling with a pet. However, because we understand most passengers are already juggling multiple tasks while on the go, we realized adding extra steps would only increase rider stress levels. The results are a Pet Mode experience that at first glance, closely resembles our other ride options like Lyft Standard, XL, or Extra Comfort.

While iterating, our team continued to return to this core project principle: Pet Rides should be as effortless to request as any of our other ride types. So we focused on simplifying the experience for passengers while ensuring the driver match is seamlessly handled behind the scenes. For those choosing Pet Rides for the first time, we’ve leveraged our new user experience prompt screen to communicate ride etiquette expectations, and to encourage a community that values and respects fellow pet travelers and the Pet Rides experience.

Rides with service animals vs. Pet Rides

As part of Lyft’s philosophy and commitment to accessibility, our content design ensures that passengers traveling with service animals are welcome on any of our ride types, regardless of driver opt-in with Pet Rides.

Bringing delight and empathy to rides

As we began to integrate the Pet Rides mode into our broader rider portfolio, we realized an opportunity to infuse this new service with delight, empathy, and our unique personality that defines the Lyft brand. Another challenge for us: how can we make it feel effortless and natural?

Our design approach centered around the idea that even the smallest of interactions can make a significant impact on the user experience. We started to look for areas within the Pet Rides journey where we could introduce subtle, meaningful moments of delight. Our goal was to create a seamless experience that didn’t just allow for pets, but celebrated the joy they bring when they’re along for the ride. So we asked ourselves:

“Where do riders and drivers engage the most within the interface, and how can these touchpoints reflect the warmth and playfulness of having a pet onboard?”

Our solution was to focus on areas where even a small visual or functional enhancement could evoke a positive emotional response. For example, when a driver chooses to opt-in to giving Pet Rides, we introduced a playful toggle animation that mimics a pet’s movement.

We then turned our attention to the rider’s post-ride experience, particularly the screen where they can rate their driver, add a tip, and pay for the ride. To be more playful, we replaced our usual star icons with paw prints in collaboration with the Lyft Product Language team. These subtle changes connect the Pet Rides experience and are designed to surprise and delight users as they complete their journey, all without disrupting the overall flow.

Pets bring comfort, joy, and a sense of companionship, and we wanted these feelings to be reflected in the Pet Rides interface. Adding moments like this to the feature not only elevates the experience beyond a functional service, it transforms a traditional ride into a journey memorable for both passengers and drivers alike.

Closing thoughts

Pet Rides was created because we care deeply about the Lyft community, and we’re committed to enhancing the passenger and driver experience. This project exemplifies how dedicated, collaborative teamwork can create products that not only function well, but users will love, too. We learned that passion and empowerment can bring great ideas to life, and with the right team, anything is possible.

Here are some key takeaways from our journey building Pet Rides to help you on your own:

• Document and explore ideas early: When you have ideas, put them in a doc and explore your options early for feasibility. This fosters better team communication later, and ensures you are prepared when the timing is right. In our case, I was able to dig through my Figma files and refresh the concept I explored during my spare time. This helped fast-track design reviews, allowing us to spend the hackathon week focusing on building it.
• Communicate and share early: Early communication and idea sharing help you find others who are equally passionate about the project. This fosters relationships, making it easier to onboard teammates and address potential problems. It helped us move the needle when we needed experts for specific fixes in a short amount of time.
• Act fast with a solution-oriented approach: Having the ability to quickly pivot and focus on solutions, rather than dwelling on problems, moves the team forward despite unexpected challenges.
• Build with passion and empower the team: Encouraging passion-driven work fuels creativity and a strong sense of ownership — as you can tell, everyone on our team is a big fan of Pet Rides!

Want to learn more?

Read on for more — or try a Pet Ride yourself!

• From Lyft: https://www.lyft.com/blog/posts/lyft-celebrates-national-dog-day-with-launch-of-pet-rides
• For riders: https://help.lyft.com/hc/en-us/all/articles/8559088908-pet-rides-for-riders
• For drivers: https://help.lyft.com/hc/en-us/all/articles/6797064954-pet-rides-for-drivers
• Service Animal Policy: https://help.lyft.com/hc/en-us/all/articles/115013080048#policyguides

Special thanks

Pet mode came to life through the dedication and passion of our team. In particular, Parul Shukla (engineering), Polly Peterson (TPM), Cathy Li (engineering), and team members Alberto Barradas (engineering), Amira Anuar (engineering), Anya Schulman (social), Andrew Vorakrajangthiti (engineering), Bri Reynolds (social), Brittany Branscomb (product marketing), Casey Gorman (engineering), Conor Buckley (illustration), Ding Luo (data science), Eleni Georgiou (engineering), Emily Williams (support), Hannah Fishman (product), Jason Williams (product marketing), Jill Gonzalez (comms), Jen Winston (social), Joanna Cutrara (content design), Jordan Levine (comms), Lorra Barile (social), Matt Dikdan (content design), Min Kim (engineering), Norma Sutton Harary (engineering), Martina Pillay (product), Qiyuan Bao (engineering), Tisha Woods (DPM), T.J. Daunch (support), Zachary Sy (engineering) and design members Brandon Souba, Brian Wu, Chrysan Tung, Dorington Little, Esin Arsan Karasabun, Kathleen Namgung, Runi Goswami and many others who helped and supported this project.

Finally — a big thank you to our sponsors Audrey Liu (rider), Jeremy Bird (driver), and Siddharth Patil (marketplace)!

This article was written by Gwen Zhang and edited by Nathan Falstreau, members of Lyft’s 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!

A ride for you and your furry friends was originally published in Lyft Design+ on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’m new to the design system’s team at Lyft. After 6 years of working as a feature designer, I decided to make the jump to design systems and I couldn’t have picked a better design system to learn from.

At my last gig, I built out a component library, but I did so as a side project unsupported by leadership and with few engineering resources. Sound familiar? In a world where most designers have to advocate just to spend some time componentizing, I feel very lucky to be at an organization with a mature design system. Our design system, Lyft Product Language (LPL), has org-wide buy-in, a fully stacked team (complete with designers, a design program manager and engineers), thorough documentation and meticulous processes.

Coming from the world of urgent product deadlines, I was accustomed to pushing through the design process at lightning speed. However, my time at Lyft has taught me that design systems and product teams have distinct rhythms. The design system should maintain its focus on delivering high-quality work without being pressured by fast-paced timelines, while product development should continue its momentum without being held back by the design system’s schedule. At Lyft, balancing these two areas is essential to achieving harmony.

For my first LPL project, I was tasked with building a validation message component. Validation messages provide clear and actionable feedback to users, help them understand the context and implications of their actions, and guide them towards resolving any issues or errors. They are typically paired with input components like form fields, but can also be used by non-input components where applicable. It was a relatively simple project, chosen to help me familiarize myself with our distinct end-to-end process.

Although it took some time to wrap my head around spending weeks investigating a small component like a validation message, the LPL process with its many checks and balances allowed me to slow down and ensure that nothing critical was overlooked during the design process. The highly collaborative nature of everything we do facilitated open discussion and review of everything I designed, maintaining the integrity of the system.

The LPL Project Process

Step 1: Project Brief

Every project begins with a detailed project brief, created collaboratively across the design systems team and any other relevant stakeholders.

Since this was my first project, the project brief had already been written. Initially, the validation message component was named “sentiment message.” There was existing documentation using “sentiment messaging” as a term, and some components, like text fields, had their validation messages labeled as “sentiment” in both Figma and web. However, the project brief revealed confusion about the scope of this component. Would it be user-initiated or system-initiated? Could it address empty states? What exactly did “sentiment” mean?

Step 2: Audit

Once a project is green-lit and prioritized on our roadmap, we kick off a crowdsourced audit by sending a call out in our Slack channels across the organization.

During the audit, it became even more clear that the broad nature of the term “sentiment” caused confusion. The expectations of what problems this component could solve were painted with a broad brush because its name lacked specificity. We were trying to solve for too many use cases, thus adding complexity to our discussions on how to design the component.

In this stage, I conducted a competitive analysis, investigated our current naming conventions, and crowdsourced an audit of use cases across the organization.This led us to uncover that while this component had already been built in iOS and web, they each had unique names. Moreover, in Android, they did not have a standalone component built at all.

Naming a component might seem simple, but if not thought through, it can cause confusion, inconsistencies, and difficulties in maintaining clear documentation. Now was the perfect time to get alignment across platforms not only on what we called the component but also on the specific use cases it solved for.

Step 3: Project Kickoff

We utilize one of our biweekly review time slots to hold a kickoff meeting, ensuring the working group is aligned with next steps across both design and engineering.

During the project kickoff, I presented my findings from the audit. With a broad name like “sentiment message” it was not clear whether or not things like help text should be included in the component. By making the name more descriptive we would be able to change the understanding of this component from one that simply conveys sentiment to one that conveys sentiment in response to a user’s actions. During this meeting, the working group agreed to rename the component. Applying systems thinking early on made our component simpler to scope and build. We now knew that we would be removing help text and empty states from the scope of this component. Moving forward, this component would be called “validation message.”

Step 4: Design

In the design phase, we work on solving the root of the problem, designing solutions that meet our quality standards. This phase includes multiple reviews with the entire working group and feasibility reviews within the design systems team.

Systems thinking allows us to identify root causes, feedback loops, leverage points, and unintended consequences. Due to the emphasis on alignment early in the LPL process, I could apply systems thinking at the outset of the project, thereby avoiding potential confusion among system users.

During the design phase, I used systems thinking to consider all different use cases for validation messages. While the component itself is relatively simple, the ways in which it can be applied and the vast number of other components it needs to be nested within can cause complications.

I had to contemplate things like content design (in-product style) or spacing all while considering the nuances between platforms. For example, due to the more complex use cases we needed to address for our web products, I established that we should have the mobile component max out at two lines while the web component would allow for three.

When you have a component that is used by so many other components, flexibility is key. This is why I landed on removing all padding from the component, allowing for any spacing required to be built into any parent components as needed.

Step 5: Design Documentation

We draft design documentation in Google Docs, which may include technical specifications not covered in design reviews. The document is shared in a designated Slack channel for internal review. If comments aren’t resolved asynchronously, we schedule a review meeting. Once approved, we publish it on the LPL site.

Once all edits had been finalized, I wrote our documentation in Markdown. Writing in Markdown via VS Code and using Github were all relatively new to me. So this part of my journey involved asking a lot of questions and doing a lot of Google searches. It’s not rocket science, but it definitely helps to have educational resources at your fingertips. At Lyft, there is hands-on training with Markdown that really helped set me up for success. But it also helped to have a Markdown 101 cheat sheet at the ready!

Step 6: Design Handoff

The design phase ends with an engineering kickoff, where the designer reviews the documentation, interactions, and Figma library with the engineers.

Creating the actual component in Figma was relatively simple. However, integrating it into other components like text fields, text areas, and dropdowns presented some challenges. This was especially true for the web, with its many different input field types.

Design system components have a large impact across other designs, providing opportunities to solve unique problems. This led me to learn new tips and tricks in my tooling and optimize my design workflow.

The first challenge was replacing all existing messages in the input fields with the new validation message component. Selecting each layer was a daunting and tedious task. Collaborating with Figma super users on the design systems team boosted my efficiency. For example, I learned that holding Shift while clicking into a layer in Figma highlights all similar layers, making them easier to select.

After swapping out the old components for the new one, I realized that in many instances, the new component retained the name of the older component. I reached out to our resident Figma expert, Mordechai Hammer, and learned about Figma’s built-in renaming functionality. Selecting all the layers and hitting Command + R made the process much simpler.

Step 7: Sendoff

We review the final product with the project working group and ensure all loose ends are tied up or handed off.

During this phase, we QA’d the built components and it was a pretty smooth process thanks to all the work and collaboration the working group had done leading up to this point.

Step 8: Inform

Finally, we send out communications to all relevant stakeholders to inform them of what to expect. The documentation site updates are also deployed.

In order to inform our users of this new component, I posted an announcement on the homepage of the LPL website, put out a communication on our Slack channel (being sure to highlight any breaking changes) and presented about the component at our monthly All Hands Design meeting.

Final Thoughts

Following this meticulous process was immensely beneficial. Not only did this process ensure that there was consistent adoption of validation messages across product teams, but designing for LPL has helped me unlearn moving too fast, flex my systems thinking muscles, and optimize my workflow. Reflecting on my journey so far, I am genuinely amazed at how much I’ve learned in such a short time, and I am eager to continue uncovering new insights and skills.

Have you contributed to a design system before? If so, I’d love to hear about your biggest learnings and the challenges you faced along the way.

This article was also published in Tap to Dismiss.

Embracing the process: Learning to slow down to deliver clarity was originally published in Lyft Design+ on Medium, where people are continuing the conversation by highlighting and responding to this story.

Helping women and nonbinary drivers more confidently get behind the wheel

In early September, we launched Women+ Connect, a new feature that matches women and nonbinary drivers and riders together more frequently. This was a highly requested feature, so we set out to create it. Women+ Connect was no small undertaking and it took a large group of cross-functional partners working together to get it off the ground. From a design perspective, here’s a brief snippet of how the team helped create Women+ Connect.

Using design thinking to shape a new feature

A few core principles kept our design team focused as we developed Women+ Connect. Since we were working with numerous stakeholders, it was crucial to have clear touchpoints to bring us back to what was most important.

1. Inclusivity at the core — The “+” in Women+ Connect was important from the start. In order to create a feature that includes underrepresented gender minorities, nonbinary people were always part of the conversation. We also wanted the feature to be clear–so we prioritized explaining how the feature works, who can use it, and what information would be needed.
2. Put drivers and riders in control — We designed Women+ Connect to easily fit into riders’ and drivers’ lives. Riders and drivers are able to turn Women+ Connect on or off as often as they’d like, giving them more flexibility and control over how they ride.
3. Facilitate a great experience — Women+ Connect is a preference, not a filter. Ensuring that everyone who orders a ride is able to get one. Our goal is to see more women and nonbinary drivers join our platform and be able to match with women and nonbinary riders. That being said, when a women+ match isn’t available users will still be matched with men.

How it came together: Women+ Connect

Here are a few screenshots of Women+ Connect in action. While additional changes are in the works, each of these principles shows up in the feature.

Channeling Lyft’s history of advocacy

Lyft has continually been supportive of LGBTQIA+ rights. Our program Round Up & Donate, where users can round up the cost of their ride and donate it to the charity of their choice, has generated over $4.5 million in donations to the LGBTQ advocacy group the Human Rights Campaign. We were also the first rideshare app to allow riders and drivers to set their preferred pronouns.

To help create a feature where riders and drivers feel included and supported, we conducted extensive user research and worked with internal and external organizations like LyftOut, HRC, It’s On Us, and the National Association of Women Law Enforcement Executives to inform our approach before launching.

Continuing to strive for accessibility

We built Women+ Connect in the hopes of making rideshare more accessible to people who are historically underrepresented. We plan to continue to use this framework to keep designing solutions that make our product better for everyone who uses it.

Want to read more?

Interested in finding out more details about the product or how to get started? Check out these links below:

• From Lyft: https://www.lyft.com/women+
• From Lyft: https://www.lyft.com/blog/posts/women-plus-connect
• For riders: https://help.lyft.com/hc/e/rider/articles/9030680293
• For drivers: https://help.lyft.com/hc/en/all/articles/3660193554
• Mashable: https://mashable.com/article/lyft-women-nonbinary-drivers

Special thanks

The launch of Women+ Connect would not have been possible without the hard work and close collaboration of our mighty team. Special thanks to Alyssa Hitchcock (design), Gwen Zhang (design), Michael Levine (product), Naomi Yarin (product), Carly Uhlman (product), Alex Michaelides (research), Sabrina Papazian (research), Alicia Ostarello (content), Joey Ricci (product marketing), Limin Shen (engineering), Xiaoyi Duan (engineering), Adi Zimmerman (engineering), Jessica Wang (engineering), Ding Luo (data science), Yijun Wu (data science), and Scott Geller (data science).

And a big thank you to our design leaders Audrey Liu, Tara Stewart, Leslie Yang, and Brian Ng.

…

This article was written by Julia Green and edited by Amy Lipner, members of Lyft’s 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!

Connecting women at the touch of a button was originally published in Lyft Design+ on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article was co-written by Karuna Harishanker (Senior UX Researcher at Lyft) and Dylan Trow (Former Staff UX Researcher at Lyft) and represents their shared perspective.

When we think about strong UX researchers, we often think about their ability to deliver compelling insights at the end of a study that influences their stakeholders.

However, while coaching UX researchers and cross-functional partners on storytelling at Lyft, we realized some people are naturally better at it than others, and that we aren’t really taught how to do it. In our experience, we often find the skill of storytelling is lacking in researchers early in their careers, and in fact, UX researchers of all levels can benefit from sharpening their storytelling skills.

Scanning articles from the UXR community online, we came across limited writing that we felt got to the core of what goes into telling good stories in the world of UX Research. As people passionate about this topic, we reflected on our own practice of storytelling and found that thinking about it within the context of the product development cycle helped us tell more actionable stories, as well as coach others on how to be more effective storytellers. We want to share our thinking with the broader community, and also hear what you think — please comment below!

What do we really mean by “storytelling”?

We’ve formed a working definition of good storytelling in UX Research — a compelling and simple story that is easy to follow.

Compelling and simple means a clear narrative that your team can understand and act upon. Easy to follow means sharing your findings in a way that your audience can digest what was learned.

Why is “storytelling” important in UXR?

If we take a step back, storytelling in UX Research is more than just what your final report looks like.

Being intentional about the story you tell can help: make findings more digestible, actionable, and easy to follow; focus your stakeholders on the key findings; and above all, increase the chances that your stakeholders will act on what you are sharing. Being intentional about the story you craft is important!

However, the reality of getting to that final report can be daunting — we’re often rushed into another study or we’ve been procrastinating on synthesis and have limited time. As a result, researchers can lose sight of what story they want to tell, and more importantly, how to arrive at that story. We want to bring attention back to the story.

How do I tell a better story?

We’ve identified 3 steps to help you tell better stories in your research reports:

This article was written with a focus on how to find and refine stories within qualitative research reports, but we have found that these three steps can also be applied to quantitative research reports.

Disclaimer: like many things in the world of Design, storytelling is an iterative process, and you might not ace it your first time. This article is not a formula, it is not a one-size fits all. These are considerations that we hope can help as you communicate a story within your own work.

Step 1: Find your story — moving from research insights to narrative

To take inspiration from the world of Industrial Design, form follows function. We always caution UXRs against starting by opening a new slide deck and adding content, because it makes you too focused on the form–your report, versus the function–your thesis. Put another way, just like any good researcher starts by identifying learning objectives before choosing a method, we want to first focus on moving from insights to story before starting on a final report.

This is likely the most time-intensive part of the process and is highly dependent on your study. We recommend finding your story by re-centering yourself on two things: Research intent (i.e. why did you set out to do this research) and research actionability (i.e. what decisions is your research looking to inform). Starting here will help you establish the kind of story your report might arrive at.

Research intent

When starting the process of finding your story, we recommend first grounding yourself in your research intent. Why did your team set out to do this research? Where in the product development process is this research happening–discover, define, refine or launch?

Research intent differs across the product development process and will inform the key elements of your story. Let’s take a look at how this can inform your story.

Remember: Finding your story doesn’t begin at report creation. It starts in the planning stages of your study. It’s about having clarity on the learning objectives of the research and how the insights will ladder up to answering those objectives.

Research actionability

UX Research is rarely done in a vacuum, and is always trying to help gain clarity on a decision. We want to consider what decisions your team is going to make to help determine what’s most important to share (i.e., what insights make up the core of your story).

Some examples:

• Did your learnings highlight new considerations or questions, the team wasn’t thinking about?
• Did your learnings confirm or invalidate the team’s hypothesis?
• Did your learnings give the team a clear signal on what to do next or what not to do?

Leveraging this ‘decision-lens’ is important in Step 1 because it filters out insights that are relevant vs. interesting. Too often we find UX researchers putting all the data they collect and insights they’ve uncovered into a report in the pursuit of being thorough. Instead, anchoring on the decisions your team is trying to make can help you hone in on which insights are relevant for your story.

You might wonder, well what about the other ‘interesting’ insights I gathered in a study. Do I just not share that? We recommend documenting these tangential insights in an appendix section, so you don’t lose the learnings while you’re deep in synthesis and so they’re available for when they potentially become relevant in the future.

Disclaimer: Compelling stories stem from actionable insights and recommendations (the ‘so what’). The more actionable your content (specific and concrete), the stronger the story. This article does not cover tips on crafting strong insights and recommendations and we encourage you to check out other articles on this topic.

Step 2: Figure out how to communicate your story

Once you’ve figured out the pieces of your story — central thesis, relevant insights, and what it means for your team — it’s time to thread them together. Remember that your story might not follow the same order as the research questions in your research plan — that’s ok! This is why figuring out how to convey your story becomes important. How you share your findings with your team will determine their understanding and ability to act on the insights.

There are two important tools you can lean on when communicating your story: story arcs and frameworks.

Story arcs

Generally, a story arc is the path your story takes. A common example in UX Research is an “answers-first” type of arc — starting with an exec summary of top findings and recommendations, then backing up your points with evidence. Story arcs vary, and there are many to choose from, but in general it is important to start with the basics: a beginning, a middle, and an end.

No matter what story arc you choose, consider including comparisons as a key element. Detailing “what is” and “what could be” is a way to easily highlight challenges and opportunities. In early stage research, this might be comparing current-state vs desired future-states, while in later stage research, this might be contrasting potential solutions.

Let’s look at some more specifics about potential comparisons across phases in the product development process.

Frameworks

Frameworks are a great tool to communicate your thesis. By anchoring your story on a single framework (i.e. journey map, hierarchy of needs, etc.) you can help your audience understand how sections relate to one another, tying the whole thing together. Using a visual representation can make insights easier to understand and recall. They can also help simplify complex concepts and establish relationships between the concepts. Also, they can be a neat way to organize your story.

As with everything, use frameworks in moderation. Multiple frameworks within a report, or incorrect usage often does more harm than good. Similar to our advice above–form follows function. Think about whether a framework adds value to your story or if it’s just a visual way to design the slide. A good check is to ask yourself: “is the purpose of this framework really what I am trying to convey?”.

Here are some examples of frameworks and how we have seen them be effectively used in research reports.

Step 3: Make it easy to follow — how to design your report

Now that you’re starting to think about how you are going to convey your story, it’s time to fully shift your focus from function (your thesis), to form (your report).

There are many formats you might use to create your final report. Is it a doc? Is it a deck? Is it a video? Is it print-outs lining the design room? The possibilities are endless, and so there is an important decision to be made here: what format should I use for my report?

Part of this decision might come down to how much time you have to create the final report (i.e. which format you feel most comfortable creating) or how well that format supports the story and way you want to visualize it. However, equally, if not more important, is knowing who will be using your research and how they best consume information. Let this dictate the format of the final report.

For this article, we’ll focus on presentation decks, since we’ve seen that as the most common format in our practice.

When trying to make your report easy to follow, we like to focus on three principles: orient people, leave breadcrumbs, and make it scannable.

Orient people

This is all about situating your audience in the content. The best way to do this is to give people a sense of the contents of your report upfront. Orienting people not only gives them context on what you’ll cover today vs. not, but also makes it easier for them to find information if they revisit your report. Examples: table of contents slide, upfront slides with key takeaways you dive into one by one, or chapters if you intend to cover multiple topics.

Leave breadcrumbs

This helps with wayfinding for your audience, guiding them through each section, and how they fit into the broader story. For this to be effective, it is important to pick one system of bread crumbs, and be consistent throughout the report. Examples: using a framework like journey mapping to dive into each phase or step, icons as markers for different topics, or even colors to distinguish between sections.

Make it scannable

This is about ensuring you’re paying attention to the visual hierarchy of your slides as well as the flow of your content. Ways to test this:

• Content hierarchy: A squint test helps you determine what content is most visible on a slide and if it matches what you want your audience to focus on. If nothing jumps out, you likely have too much content or not enough hierarchy. If the wrong things jump out, reevaluate the hierarchy and layout. Remember, people naturally read top to bottom, left to right.
• Slide flow: To ensure the story flows well from one slide to the next, look at your deck using the grid view feature, and only read the headlines of your slides. This will tell you if the slides are in the right order and if your headlines can be written in a more succinct, or actionable way.

Final thoughts

If you’ve made it this far in this article, you may be thinking “this looks like a lot of work!” You’re right. Finding, refining, and presenting your story takes time. It’s something to begin thinking about not just during report creation, but right from the planning stages of your study.

We hope that next time you find yourself working on a research study, you might give this 3-step process a try, to help find your next compelling story.

We are continuing to hone this practice at Lyft, and exploring how this 3-step process can extend to disciplines beyond UX Research, like Data Science. We also know that UX Researchers have varied approaches to their work — so we’d love to hear from you! Did you find this helpful? What else do you think about when crafting your final report? Please comment below!

Why storytelling in UXR matters and how to uplevel your skills was originally published in Lyft Design+ on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.

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.

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?

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.

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!

“That little island changes everything” was originally published in Lyft Design+ on Medium, where people are continuing the conversation by highlighting and responding to this story.

Guided by quotes from managers and mentors + one of last year’s associates, Miri and Tisha, Lyft’s PD+ 2022–2023 UX Associates, share general insights and advice that helped them on their journey.

In 2022, Mirianna Acevedo (User Experience Researcher) and Tisha Woods (Design Program Manager) joined Lyft as the second cohort in Lyft’s UX Associate Program or LUX-AP. Though they worked in different disciplines, they made time for weekly check-ins throughout the associateship, and those check-ins turned into texts + audio messages and evolved into a friendship built on a shared experience. Halfway into their associateship, they thought, what better way to wrap up the shared experience than a shared project? Combining their love of pop culture and design, Miri and Tisha created a project plan to produce content with two goals: inform anyone interested in the LUX-AP experience and reflect on their journeys. They involved their core program guides and created written + video content to spotlight the program and their growing friendship. These are their insights.

2022 LUX-AP insights

“My lack of experience and credentials were blocking me from getting my foot in the door transitioning into UX Research. A recurring question in my mind was “How do I get experience and develop skills when no one is willing to give me a chance?” Fortunately, this frustration did not last long because Lyft announced their new program for professionals with non-traditional backgrounds. For the first time, I felt like there was finally a role for people like me- interested in UX Research but just needed an opportunity to develop skills and build experience. LUX-AP is close to my heart because it broke down barriers, creating a space in tech for career switchers who are passionate and eager to learn. ”

— Jade Searchwell, Previous Associate, now UX Researcher

What parts of your previous career do you bring to your current role?

Miri: I come from a sales/customer service background, and thankfully, I could pivot and take many transferable skills and put them to use during my associateship. Customer service usually involves a lot of customer-facing interactions, asking open-ended questions to uncover any pain points or expectations, analyzing customers’ behaviors to increase sales, and working in fast-paced environments. Those are some of the typical day-to-day of a sales/customer service job and are also core tenants of UXR. I could take those exact skills and immediately put them to work on the projects at Lyft.

Tisha: My career pivot led me to unpack a lot of what was unique to Teacher Tisha and what could be valuable to DPM Tisha. Turns out, there’s so much overlap in education and design ops — benchmarks, planning, retros, efficiency, adaptability, and team support, to name a few things — and what’s innately me. Thinking broadly, emotional intelligence is the biggest and most useful skill set in both careers. Strong emotional intelligence and a growth mindset helped me navigate the big and unexpected feelings that come with change.

“Personally, I believe the benefits of a program like LUX-AP extend outside of Lyft. Design Ops is a small discipline, and there are only a few opportunities for formal training. (It’s worth calling out that there are groups like Design Ops Assembly trying to change this). This means that many practitioners come into Design Ops from tech or design roles and have similar backgrounds. Programs like LUX AP help expand our discipline by creating new pathways into the field. The more voices and experiences we include, the more impactful our discipline can become.”

— Julie Celia, Staff Design Program Manager

What do you love the most about your role, and how does it connect/relate to who you are?

Miri: Naturally, I’ve always been a curious person since diapers, and I have to be honest and say that I have always been a “people pleaser,” I always want to help and support people in the best way I can. I also love design and creating an effective but good-looking experience for users, as someone who has worked in the Retail, Sales, and Customer Service industries for almost ten years. I have always noticed and heard from customers things that could be different or would optimize a client’s experience with a company. As a UX researcher, I get to work directly with that pain point and improve the user experience by practicing various research methods. This is the most satisfying for me as I analyze users’ concerns and problems and work directly on them with a team that all share the same mission. I am extremely passionate about it and grateful to do it.

Tisha: I love all aspects of the role because each piece gives me a new perspective on my skills and how to apply those skills in different contexts. I’m always in my head and thinking, so I think the ambiguous space — the Mind Palace stage, as I call it — is one of my favorite parts because it gives me the opportunity to consider + process information and investigate, in whatever form that takes — observation, active listening, 1:1s, reviewing projects, reflecting, or taking notes. I can also let my mind wander and make noise with purpose and find unique connections. Creative thinking is fun.

“It has been exciting to see someone brand new to a field learn skills and gain confidence in those skills through practical application and project work. Unexpectedly, the thing that has been more rewarding for me has been seeing someone challenge their mindset by focusing on the process of learning and not just the outcome. I think it was key to unlocking growth.”

— Dylan Trow, Staff Researcher.

What did you do to get comfortable in the role?

Miri: When starting my UXR journey, I knew having a growth mindset muscle Is something I would exercise daily. Questioning myself all the time helped me reach the core of those amazing recommendations and insights for my stakeholders. Things I did to feel comfortable in my role were to seek feedback, look at my improvements, work on things I need to improve, and see my growth as a constant reminder that it’s a marathon, not a sprint. Allowing myself some grace, being kind to myself, making mistakes because with those, I learned something new, and lastly, setting realistic goals (those that applied to me and where I was in my journey). It’s amazing to aim big, but smaller realistic goals help us achieve more and give us more confidence when hitting those milestones that lead us to our dreams.

Tisha: I cannot stress enough how important and impactful my core team + PD+ buddies were to my success and comfort. I had so much external support that I pushed myself to reflect internally and grow. I embraced my internal spirals and acknowledged (and accepted!) all the good things taking place. I carried that vulnerability with me and shared my feelings in safe spaces because saying them out loud made them and gave me an opportunity to own them, and whatever solutions or strategies felt authentic or appropriate. I also adopted two guiding mantras and affirmations to ground me on this epic adventure — “I’m doin’ cool shit.” and “I’m leveling up.” (Credit for the last one goes to Anna Judd, who helped me reframe my confused feelings in a relatable way.)

“When you’re teaching someone, it forces you to reflect on your own practice and become more self-aware around the ‘why’. Being a manager on this program helped me document and refine my own process, and is a great reminder that the UXR is a process of continuous growth and iteration no matter where you are in your career”

— Karuna Harishanker, UX Researcher.

Did you have any expectations of the associateship before coming into the program? And how has it been different or the same?

Miri: I knew I would learn, but I didn’t know how in-depth it would be. It’s made me love research even more. With the projects that I worked on, it didn’t seem like there was an expected outcome. The studies could and did go in so many different ways, and that’s what I love the most about the program. There were so many unexpected things that happened that I said to myself, “Okay, I’m glad this happened. This may seem like a negative, but this is a positive because I’m actually learning. This could happen to me later in my career, and I’m learning now.” Overall, I do think it was a really good experience, and it definitely exceeded expectations in terms of the things that I learned about research, Lyft, and my skills.

Tisha: I had zero expectations beyond learning. That was my only expectation. I learned a lot, and I learned more than I expected. Not just about the role but about Lyft, the people, myself, how I work, what feels natural to me, what makes me uncomfortable, and how to best approach that discomfort. I also learned how to ask for and receive help. It’s such a beautiful thing to be supported and nurtured like this at any career stage, but especially in a foundational role.

“I cannot express how much I appreciate being part of an organization — in the Product Design+ team at Lyft — that allowed us to take the space to think about and build an associate program. To me, LUX-AP paired with our internship program, creates a richer environment of experience among our early talent design team members. It’s been a real joy to get to watch Miri, our UXRA this year, build her skills and confidence in conducting and presenting UX Research at Lyft. I’m eager to continue to evolve this program in a way that allows even more opportunity and perspective.”

— Kat Murray, Head of Research.

Outside of the resources shared in LUX-AP, where else did you find inspiration related to your role?

Miri: I am a hands-on learner, but for this role, I needed a lot of background knowledge before even practicing the research steps. It always helps to know a little bit more about a topic or method before going out and trying it; it can also save you much time to focus on your research. Some resources I found were articles from Nielsen Norman Group. I looked at many Medium blogs, like Top 5 Blogs UX Researchers Can’t Miss. Lastly, I joined many UX Research groups where people share a lot of their work or inspiration; every researcher is different, so it’s nice to see those perspectives and apply them to your own. Remember to take notes and be in charge of your learning, don’t be afraid to ask questions and constantly question yourself. Answering “Why?” is why research exists!

Tisha: In general, I found inspiration from creators and their relationships with creativity, which led me to better understand my relationships with creativity and design as well as how I can fit in a design role. I also used my 1:1s and meetings to find themes in what sparked my interest in something and followed the trail with follow-up questions or Google spirals. They’re also super helpful in gaining insight into how others work. Applying the learnings was the best and coolest part, though. I felt safe to try something and see if it worked or to see how I could improve my process. I kept my mind open at all times and documented any useful thoughts to dig into, share, or apply at work. I also directed my own creative energy toward writing — reflections, random notes + thoughts, and even short stories helped me understand when and how I express my creativity. I read and listen to podcasts a lot, and the following books and podcasts helped me on my inner and professional journeys throughout the associateship.

Books: Nadra Nittle’s Toni Morrison’s Spiritual Vision | Phil Jackson’s Eleven Rings | Rick Rubin’s The Creative Act | Questlove’s Creative Quest | Benjamin Hoff’s The Tao of Pooh | Tara Eurich’s Insight | Ellen Lupton’s Design in Storytelling | Austin Kleon’s Steal Like an Artist | Kevin Bethune’s Reimagining Design | Greg Hoffman’s Emotion by Design

Podcasts: Black Girl Songbook | Revision Path | Technically Speaking | Into the Depths | 99% Invisible | The Homecoming Podcast with Dr. Thema | Team Deakins

Memorable Lyft ride?

Miri: Haha, this is a good one. My most memorable Lyft ride was late at night, I’ll say 3 am. It’s already a sketchy time in New York, and as a woman, you always fear potential dangers. I was going home from having drinks with friends and requested my ride. The driver arrives and asks me about my night! It makes me extremely comfortable and lets me take control of the music. We listened to Bad Bunny the whole ride and sang our hearts out. It felt like I got into the car with a friend. I remember getting home and thinking, “Wow, what a way to end the night.”

Tisha: Eight years ago, I hurt my foot in the most characteristically Tisha way imaginable and needed to have a cool surgery to heal it properly. (I called it my Adamantium Transformation because it involved temporarily fusing two toe bones with a long surgical screw, which I still have in my Core Memory Box.) My usual chauffeurs were out of town or locked into obligations I didn’t want them to cancel, so my then-brother-in-law sent his Lyft referral code. I’d always seen the cool mustache cars but, for some reason, never tried the service before hurting my foot. I booked the ride and let my driver know ahead of time that I used crutches and I’d try my best to meet him outside. He told me to wait, sent a message that he was heading upstairs, and helped me down the stairs to an already-reclined front seat. First and kindest ride-share experience.

“…onboarding our Associates and benefiting from their analyses, questions, and ideas forces us to question what we do and how and why we do it. We can then improve and change together. I have had the pleasure of mentoring Tisha Woods, our 2022–2023 LUX-AP for Design Operations. She has brought fresh ideas informed by her extensive experiences outside of Design Ops that have helped inform how we want to approach our craft moving forward. I don’t think we can achieve the same injection of perspective by hiring people who exclusively come from within the discipline. Ultimately, no craft or discipline lives in isolation (or at least it shouldn’t). There is no reason why Associates with backgrounds outside of a certain discipline cannot meaningfully contribute to our field and become valued and central practitioners– and in fact, we’ve seen that overwhelmingly, they do.”

— Amanda Schwartz, Staff Design Program Manager.

Thank you to everyone who participated in the 2022 LUX-AP workstream. Your work brought us here. Thank you to our respective teams (Design Operations + Design Foundations and UXR: Transit, Bikes, and Scooters + Fleet) for guiding and supporting us on this journey. Thank you to our core LUX-AP teams, quoted in the article, for the opportunities to impact Lyft and the design industry. Our work and this article are reflections of you and your fantastic work.

— Tisha and Miri

Associates y Amigas: Insights from Lyft’s 2022–2023 UX Associates was originally published in Lyft Design+ on Medium, where people are continuing the conversation by highlighting and responding to this story.

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:

1. Transparency & trust
2. Control & flexibility
3. 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!

Scaling Design: Building Lyft’s plug-and-play payment system was originally published in Lyft Design+ on Medium, where people are continuing the conversation by highlighting and responding to this story.

In February 2022, the Driver Growth team at Lyft held a 2-day workshop to holistically re-envision the new driver experience. For the first time, we invited drivers into a workshop to co-create and brainstorm ideas alongside Lyft designers, researchers, engineers, product managers, and other cross-functional team members.

Prior to the workshop, Nishchala, our Driver Growth UX Researcher, talked with new drivers to better understand their behaviors, motivations, and pain points. These research insights revealed the complexities and adversities of being a new driver, and thus a greater opportunity to invite new drivers themselves to be a part of re-imagining their own Lyft experience.

We came together to plan a workshop focused on participatory design. By collaborating directly with new drivers, we were able to:

• Help Lyft team members further immerse themselves in understanding what it’s like to be a new driver
• Brainstorm with new drivers on a wide breadth of potential responses to top pain points, influencing the design and product work that followed
• Generate deeper recognition and excitement towards the problem space across our organization

Hi there — I’m Sara, a product designer on the Driver Growth here at Lyft. While participatory design has already been around for a while, practiced by research experts across various companies including ones at Lyft, this was my first co-design experience in an industry setting. In this article, I’ll share my experience of working with our team to host a co-design workshop involving both drivers and Lyft team members. I’ll also offer some suggestions and personal reflections for running a co-design workshop of your own.

Reframing problems

At the start of 2022, the Driver Growth team set out to redesign the new driver experience — a huge problem space with a plethora of potential opportunities. To help us form a plan, we decided to host a vision workshop in order to identify and prioritize design opportunities to inform our roadmap.

Around the same time our workshop planning began, I participated in a 2-month engagement between Lyft and the Creative Reaction Lab to learn and brainstorm how to reshape product practices to be conducive to inclusion and diversity (I&D). I learned how designers have inherent power and often see themselves — whether consciously or subconsciously — as experts bestowing knowledge onto needy communities or arbiters of design “solutions,” when in fact our roles should be collaborators who aim to serve communities.

At Lyft, we’re fortunate to have an established UX Research function that empowers us to build stronger connections with our users, such as by talking with them to understand their experiences and get feedback, providing avenues for teams to either participate in research or conduct their own, and hosting company-wide immersion programming… but was there a way to bring drivers, the living experts of our problem area, even closer into the decision-making process?

Building upon our existing foundation of research practices and incorporating this newfound lens of inclusivity, we took this redesign project as an opportunity to take the step from immersion and empathy-building, into co-creation and participatory design. By inviting new drivers directly into our design process, not only would they be able to share their experience, but also ideate on ways to improve it.

Redefining goals & planning for inclusivity

Our planning process began by thinking about our goals of hosting a co-creation workshop. While it can be tempting to jump into brainstorming and choosing activities, first thinking about our purpose and the “why” helped us form a framework that guided the rest of our process and a vision to fall back against.

For our team, we wanted to work alongside new drivers — whom I refer to as the “community” our designs impact — to understand their history and experiences, identify opportunities to address their pain points, and get a sense of which ideas most resonated with them.

In addition to Lyft team members and new drivers, we also invited a few relevant stakeholders from different parts of the company (e.g. Lyft support agents and community associates) who our Driver Growth team doesn’t normally work closely with on a day-to-day basis.

Below are some of my personal reflections around defining the intent of engaging the community in co-design.

• Consider how your community can participate as living experts and direct contributors.
  Oftentimes, team members less involved in research second-handedly understand or apply user insights, leaving a degree of separation between our everyday work and our understanding of who our work is for. By bringing the community directly into the design process, consider how they can fill in knowledge gaps, weigh in on design concepts, or otherwise help your team navigate the design process with their true domain expertise.
• Consider the inherent effect of directly involving the community in design processes they aren’t normally involved in.
  Think of goals not only as outputs or what you want to ‘get out of’ the community; sometimes, design is not about solutions, but the process itself. What new perspective, understanding, or cultural shifts can be brought by the mere engagement between your team and the community?
• Consider what other company stakeholders could learn from or contribute to the session.
  Diversifying your audience and inviting people from different fields and teams helps to spread the immersive impact of working directly with community members, as well as gain insight around the problem area on a more holistic level and create visibility and excitement at a broader company-scale.

Focusing on co-creation

With our goals and audience decided, we planned activities that would help us learn from and brainstorm with drivers.

Of our 2-day workshop, Day 1 focused on understanding the history and experience of new drivers. We planned activities such as lightning talks, a driver meet and greet, and a driver journey. This segued into Day 2, which we spent ideating how to address pain points through activities such as a competitive analysis, a brainstorming session with drivers, and storyboards.

Below are some best practices I learned when engaging the community during the co-design session.

• Keep activities simple and spacious to enable collaboration and discussion.
  Whereas workshops are a familiar concept in the design world, community members are likely not as familiar. Lower the barrier to entry by planning activities with clear and simple instructions. Similarly, building in an ample amount of time to work, discuss, and share thoughts in a freeform manner gives everyone a chance to voice their ideas and allow other ideas to blossom, instead of rushing through prompts and constantly time-keeping.
• Plan around the tech savviness of your community members.
  Based on your community, you may want to keep activities low- or no-tech and to also base activities on the type of device they might be joining on. Based on previous research engagements with drivers, we invited drivers to ideate on pencil and paper during our brainstorming activity since we figured most drivers would join on a phone and that tech like Figma (or even a laptop) would be inaccessible.
• Foster a sense of support and community within the workshop itself.
  Give space and time for participants, including community members, to meet one another. Building casual conversation into the schedule fosters collaboration and camaraderie. One of my personal highlights from our workshop was watching one of the new drivers giving advice to another, naturally and unprompted.
• Value and compensate community members for their time and energy.
  Be mindful that community members are taking time out of their day to share their experience and ideas. Articulate the value they’ll be adding to the workshop and make sure to reward them accordingly to make their time worthwhile.

The impact of co-designing

Thanks to the workshop, we moved forward in our redesign process. By understanding the current new driver experience, identifying top pain points, and generating a wide breadth of ideas on how to address them with drivers themselves, we were able to concept meaningful responses to the most important problems.

Outside of our specific project-related goals, we also saw more intangible — yet equally important — cultural impact. Our Lyft team members were able to understand and internalize the needs of new drivers, and this thinking began materializing in discussions on how to make products better. The workshop also generated excitement across our organization around the new driver problem space, inspiring some teams to mobilize new efforts to support new drivers and allowing us to shape our product roadmap with a driver-first mindset.

A reflection on centering communities in the design process

This workshop, along with my engagement with CRXLab, prompted me to reflect on the product practices I’ve experienced and how we may be able to better center communities in the design process.

“Empathy” is a word often used to describe the core of a designer’s work, but tends to fall flat; it’s framed as a means to an end so that we can jump into problem-solving, like a task on a to-do list. Before we dive into how we can solve issues, we as product teams have to carve time to understand the why and the story of the people our designs impact.

Just as we think about any cross-functional stakeholder, we should invite the community early and often. Realistically, this is not always feasible, so our job as designers, researchers, and other community advocates is to campaign for the resources, budget, and time to design as closely as we can alongside our communities.

Centering the community in the design process means sharing our power with them so they can shape the decision-making process. Why we need to do this is simple: our communities are who our designs serve. They are why and how we design in the first place.

Through more inclusive design practices, we can understand the problems that cause pain, collaborate on how we might be able to address them, and take the guesswork out of delivering positive impact. In this way, engaging with our communities can be transformative in and of itself.

In the grand scheme of things, this workshop was only a small representation of our overall product practices and a drop in the bucket of inclusive design at a comprehensive, end-to-end scale. Lyft, and likely many other companies, still have a long way to go to “design with, not for” at each and every step of the corporate design process.

That’s why we’d love to learn from you all. What kind of inclusive practices does your company use? How can companies further center their communities in the design process? Leave a comment below!

A heartfelt thank you to the incredible core team that helped make the workshop happen: Jen Phannguyen, Nishchala Singhal, Justin Mann, and Leo Pereira, and much gratitude to those who helped review this article: Runi Goswami, Raquel Jacobs, Esin Arsan Karasabun, Joanna Cutrara, Mani Pande, Jen, and Nishchala.

Designing with, not for was originally published in Lyft Design+ on Medium, where people are continuing the conversation by highlighting and responding to this story.

Do you feel like your bugs collect dust in Jira and wish they could be completed more quickly? This may be an article for you. While design files contain the visual instructions for what to build, engineering and product teams use stories/bugs in tools like Jira to plan and track their execution. Because of this, they are an integral part of the product building process. Whether writing bugs as part of pre-launch QA or creating instructions for design-led initiatives, having greater command writing them will increase the likelihood they will be completed. The following guidelines are based on my own experience and conversations I’ve had with engineers, and have helped designers on my team write more confidently.

One important note before we continue is that this is not a technical guide on how to use Jira. While settings like epic, assignee, priority, etc. are essential in routing tickets to the right people, we won’t be covering these here. Instead we’ll look at general rules that can be applied to whichever tool your team uses. We’ll look at a ticket’s fundamental anatomy and what to include in these two sections, title and description.

Capture 90% of the story in the summary (title)

Engineers look at many bugs each day and often in views that are simply lists of bugs. In these views the summary (title) is the only indication of what something is about. Knowing what something is about helps teams organize tasks and saves them time from needing to re-write. A good rule of thumb is to ensure that within this you capture the essence of the issue. While this may seem obvious, in practice it’s more difficult to provide clarity and remain succinct. Below we’ll look at two examples of titles that didn’t quite meet the mark and see how we might make them more clear.

In the above example’s original title, it wasn’t clear what about the header the issue was. It gave a sense of where it could be found but not what the problem was. Upon opening the ticket and looking at the screenshots, we see that a CTA’s copy on the first step doesn’t match the subsequent page’s heading.

In contrast to the first bug we looked at, the title provides more information on what is happening but doesn’t tell us where. The screenshot again reveals the full issue but it’s our goal to tell the reader this upfront.

Structure your description

Now that you’ve written a crystal clear title lets move into the description which provides the space for everything else you’re conveying. I find it helpful to break this space into three main sections: 1) overview 2) steps to reproduce 3) intended design. This structure helps ensure the needed information is included and breaking it into distinct sections makes it more digestible.

Overview

In this section include details that maybe couldn’t be included in the title. This section can also include screen shots or screen recordings of the issue.

Steps to reproduce

Assume the person working on your bug has no context or idea of how to get there. Include the actions that were taken to to cause it. Steps to reproduce can vary widely from something as simple as it’s always like this to edge cases that require specific conditions such as input errors or issues that only appear on certain browsers or screen sizes. Pairing visuals with a written account is often best and can be done like step A causes step B. Tools like Kap are helpful to make gifs/movies that can either be included directly on a ticket or linked to via Google Photos or another similar tool. If possible try to determine if something is more general and if so you don’t need to include all details such as device and browser version.

Intended design

Here’s where to include what the product should be. Use a combination of written intention, design files, design system documentation, and any new documentation you created. When possible use commonly shared language within your team such as exact design system component names.

Use written intention, links to design files, links to design system documentation, and sometimes requires new documentation. When possible, use language with can be easily understood and maybe references things like your design system. Using these words in descriptions will make implementation more straightforward.

Grouping

Grouping similar bugs together can help reduce context switching as bugs are worked on. It typically takes less time to complete a single bug with five related parts than it does five separate bugs. Common examples of appropriated use cases include typography changes, a component incorrectly used across multiple screens, or incorrect copy.

Above is an example of two modals that both use buttons that aren’t the correct type. One option would be to write two different bugs or, perhaps better is to combine into a single bug.

Be careful not to get too bloated. When working on a tight timeline when perhaps not all bugs can get addressed before launch, pull ones out that are higher priority. For example you have a number of copy bugs but some appear on main flows and others are extreme edge cases.

Ready to write

Seeing your work built is one of the most satisfying aspects of designing. While writing and following up on bugs is probably one of your least favorite jobs, it is an essential step in the building process. Hopefully these simple rules will improve the way you write bugs and help make completing them easier for your engineering partners.

Interested in joining the Lyft Design team? We’re hiring.

How to write better bugs: tips to make clear and impactful tickets was originally published in Lyft Design+ on Medium, where people are continuing the conversation by highlighting and responding to this story.