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 Tap to Dismiss 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 posted in Lyft Design+.

Embracing the process: Learning to slow down to deliver clarity was originally published in Tap to Dismiss 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 from Lyft Design 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 Tap to Dismiss on Medium, where people are continuing the conversation by highlighting and responding to this story.

Unfortunately, from a design systems perspective, incorporating these new features isn’t as easy as it appears because they may result in breaking changes to the current component set or require system users to learn a whole new workflow.

At the end of the day, we must ask ourselves:

Will these enhancements add value to system users?”

And if the answer is yes, and there are breaking changes, the next important question we must ask should be,

“Is the effort to incorporate these enhancements worth it?”

At the beginning of 2022, I led the project to enhance the Lyft Product Language (LPL) Native component library. In this blog post, I walk through the strategy we used, the reason behind incorporating lightweight user research, and some key learnings from this 6-month long project.

Our strategy

As I alluded to in the introduction, incorporating the new Figma features to the current LPL components resulted in breaking changes. But, we theorized that fully incorporating Auto-Layout and the Variants features into our components would ultimately decrease component detachment rates by making them more flexible and therefore usable across all product features. Paraphrasing Linzi Berry:

‘The juice IS worth the squeeze’

Given breaking changes were inevitable, we set out to minimize disruptions and avoid forcing system users to update their components all at once. I realized the best strategy was to essentially create a new version of each component within the existing library. Users would automatically have access to the new components without losing access to their existing components — empowering each designer to make the decision to migrate for themselves initially. This approach was also key when thinking through how to user test each enhanced component (stay tuned).

Because we knew that system users use the Asset panel to search for components, I prefixed each enhanced component with [LPL Beta] to distinguish them from the existing [LPL] components.

And once all the components are enhanced, the phased migration plan would include:

• Communicating with product teams to plan for this work on their team roadmaps (at least a quarter in advance)
• Creating tutorials and screen recordings to guide product designers how to migrate to the enhanced components
• Renaming the existing components to [Legacy] and updating the enhanced components to use our standard [LPL] labeling
• Setting the deadline to migrate all necessary Figma files which will also be the date the [Legacy] components will be archived, and,
• Scheduling workshops where the design systems team and product designers perform the migration together (picture Apple’s Genius Bar)

The enhancements

Applying the new Figma features gave us a chance to re-architect our system components that admittedly still had structural holdovers from our old Sketch library. Let’s use a particularly gnarly component — the mighty List Item — as an example. This component hadn’t been touched since its creation over 3 years ago due to its almost infinitely reconfigurable permutations and its ubiquity in our products (510,000 instances to date)! We knew that if we changed the structure, Figma would default all 500k+ component instances to the original component’s content. So naturally, I tackled enhancing this component first.

For context, the LPL List item consists of 3 areas: Start, Middle, and End which allows system users to swap to different elements. For example, within the Start area, the Drive Default size component supports either an icon, selection control (like a checkmark or radio button), and an avatar image. Similarly, the Middle and End areas have their own supported elements. That’s a whole lot of variations!

To help cut the number of variations down, I first simplified the “Internal elements” by applying the Variants feature which allowed me to group and organize similar components into a single container, like all the Start area elements. Now, the icon, checkmark, radio button, and avatar image elements are grouped together in a “Start” variant. I did the same for the End area elements, labeling that variant “End”.

For the Middle area that supported the required component content, I applied the Auto-Layout feature which allowed my content block to grow to fill or shrink to fit, and reflow as their contents change. Now, when system users hide a subtitle layer or copy-pastes in very long content, the content block resizes and wraps to a second or third line accordingly. Plus, by applying the Variants feature, the “Middle” internal elements went from 12 swappable options to only 2!

This was the strategy I used to enhance the rest of the Native components, finding opportunities to group elements and components as Variants as well as apply Auto-Layout for those components with variable content.

The Plot Thickens

During the project, Figma actually launched a few new features including Component properties. {Sarcastic tone} Thanks a lot, Figma! Just kidding.

This new feature gave systems maintainers the option to apply these properties to components with a parent-child relationships:

• Variant properties ↗️
• Instance swap properties ↗️
• Text properties ↗️
• Boolean properties ↗️

Though super powerful, I didn’t immediately add this to the project’s scope. But it did justify the need for the design systems team to plan for enhancement work on our project roadmap.

User research

Even before this project began, I knew I wanted to find a way to get feedback from design system users. Design systems mostly play the reactive game and so this was an opportunity to incorporate actual user testing right from the start to help speed up the feedback loop for the enhanced components.

To set the tone with system users, I leveraged them to create a prioritized list of components to enhance. I first placed each component in a group based on similar functionality (ie Button, Circular button, Icon button, and Text button were placed in the Button group while Inline message card, Toast, and Tooltip were placed in the Messaging group). I then created a Slack post where they could vote on which component groups should be enhanced first.

To be honest, the component group I thought users would choose first didn’t align with the actual results. Right off the bat, user feedback proved valuable! From here, I set my project roadmap and began strategizing the LPL Beta Tester program.

What’s the LPL Beta Tester program?

I’m glad you asked! I wrangled at least 1 product designer from each feature team to join together to systematically test each component within a component group. Within the project roadmap, I set up testing weeks for each component group and provided all the necessary artifacts to make it easy to stress test enhanced components either asynchronously or during testing workshops scheduled during that week. Among the artifacts, I created robust testing instructions, a Figma file playground to perform the testing, and a Google Drive folder for those async testing users to place their screen recordings of their testing. Let’s dive into each artifact together.

Testing instructions

For each component within a component group, for example, the Button component, I provided step-by-step instructions to fully test both the functionality and flexibility of the enhanced version. The first obvious test was ensuring beta testers could effectively find the [LPL Beta] Button component within their daily workflow, which is why I provided a link to where it was located in the main library file as well as give them the option to use the Figma Asset panel search.

Next, the instructions asked beta testers to perform specific tasks to test the flexibility of the enhanced Button component by using the Design panel to swap to different button types as well as replace the label content. I also included a screenshot of what the testing results should be for those visual learners like me.

Finally, to complete the [LPL Beta] Button component testing, I posed questions for beta testers to answer to help focus the feedback I was looking for.

Figma playground file

To help consolidate all the beta tester’s work, I created a playground file with different pages broken out for each component of a component group. Taking our Button component group example, the playground file consisted of 5 pages with specific testing instructions copied over from the testing instructions gDoc.

Async testing recordings

I didn’t want beta testers to feel obligated to attend a testing workshop during testing week, so I provided a Google Drive folder link within the testing instructions for those who prefer to test asynchronously to save their screen recording to. All I asked async beta testers to do was talk through their process as they screen recorded, allowing me to observe their experience testing the enhanced components and understand their thought process.

What we learned

This project allowed the design systems team to not only make our current component set more flexible to accommodate the various use cases across product teams but also really connect with our users. The LPL Beta Tester program was a true gauge to get a sense if product designers would:

1. Find early component usability testing valuable
2. Understand the systems maintenance process and the effort involved
3. Want to collaborate with design systems more often

Halfway through the project, I asked for specific feedback from LPL Beta Testers about the program and got some interesting thoughts. A beta tester said,

“I joined into the testing process late, during the List component week; however, the materials that Jeremy prepared made onboarding extremely easy and straightforward. The testing instructions and Figma files he provided were very comprehensive, so it was clear how to test the component regardless of the testing format (workshop-style or async). The thoughtfulness and craft that Jeremy put into the testing materials definitely stood out to me.”

I even got a really nice tidbit from a design systems teammate as well,

“When I had to fill-in for Jeremy as the host of one of the testing sessions, it was so easy because everything was explained in detail in the instructions and I was able to answer beta tester questions just by referencing the doc.”

Countless beta testers commented they hoped for more testing opportunities in the future as well which helped validate the extra effort involved to create a testing program for a project that traditionally only involves the design systems team. But the appetite from product designers to support lightweight user testing really opens up the door to get them more involved with other design systems projects moving forward.

Education opportunities

Any kind of change to the existing libraries will not only require communicating to users what changed but also a way for them to understand the impact of those changes. Whenever Figma releases any new feature, they also provide a Playground file that clearly breaks down the feature to help users feel comfortable. For this project, I planned to reuse the testing scenarios within the Testing instructions and playground files I set up to help showcase the flexibility and efficiency of the enhanced components. But I didn’t want to just share the LPL Beta testing resources and call it a day. I planned to create short videos and gifs to dynamically show their value all while providing further education about those powerful Figma features like Auto-Layout and Variants:

In addition to these videos and gifs, I planned to host a Figma lab or lunch and learn session to give users the opportunity to learn and ask questions in a more casual environment. This also would provide a good baseline on which educational method resonated with users the most so the design systems team can utilize that data for future projects.

In conclusion, this project broke ground to not only get product designers involved in the systems maintenance and enhancement nature of design systems but also helped benchmark the level of effort it takes to incorporate the latest and greatest Figma features. With this project, prioritizing Figma enhancements on our roadmap becomes more important to continue providing usable components that allow the flexibility to support product designers in their current projects as well as future ones.

To continue the discussion on how to update components when there are breaking changes, check out this amazing article.

This article was written by a former Lyft product designer, Jeremy Dizon, who is now a member of the Design Systems team at Disney Streaming, and Runi Goswami, a design systems manager at Lyft. Please subscribe!

Enhancing Figma Resources was originally published in Tap to Dismiss on Medium, where people are continuing the conversation by highlighting and responding to this story.

As creators of guidelines, our Design Systems team is compelled to follow them. Not just ours — WCAG, HIG, Material Design, Android Auto… the list goes on & on. This is expected, table stakes, for our team because it has been and continues to be a huge selling point for our system. “Use Lyft Product Language and get guideline adherence for free!” But what does that actually mean when that isn’t the expectation of feature teams?

When feature designers follow guidelines, especially ones around inclusivity, they are seen as compassionate, empathetic — going above & beyond — vs meeting expectations. So many don’t. Not because they don’t care, but because it hasn’t been prioritized and they don’t have the time, so the responsibility to adhere to the guideline falls on someone else. Therein lies the guideline gap: what is prescribed versus what is enforced organizationally.

By not holding designers accountable internally, we open ourselves up to external consequences. Designers avoid facing the consequence because engineering protects them — and the gap between the two disciplines widens.

After chatting with other Design Systems’ teams we realized that this pain point is shared by many. In the end it comes down to the fine line between what is suggested vs mandatory and how you ultimately educate and enforce those rules.

Common UX guidelines

Similar to many companies, Lyft has a variety of guidelines that its employees are expected to follow to varying degrees. Our main guidelines include:

• Quality Principles — Lyft leadership’s definition of quality.
• WCAG 2.1 — Web Content Accessibility Guidelines (WCAG) 2.1 defines how to make Web content accessible to people with disabilities that can often improve usability for users in general.
• Localization — Defines how to adapt products to ensure they’re culturally appropriate — familiar languages and environments.
• Road Safety Guidelines — Pulls from Android Auto & the Human Factors Design Guidance for Driver-Vehicle Interfaces — both define how to design for driving.
• Brand Guidelines — Defines how the Lyft brand manifests across our marketing and products including our mission, vision, platform, voice, tone, logo, colors, illustration and iconography styles, and motion.
• Content Guidelines — Building off of the more high level brand guidelines, we have additional more detailed guidelines for UX writing, illustration, and iconography.

Education & enforcement over time

In a perfect world, feature designers & engineers know, understand, and create with guidelines in mind. There is no need for guidelines checks throughout the product / feature creation process.

Unfortunately we don’t live in a perfect world and guidelines require a considerable amount of reading and comprehension in order to effectively put them into practice. When guidelines aren’t outlined as requirements to launch by leadership, it’s difficult for feature designers and engineers to prioritize the time it takes to learn. Especially if there are no consequences for not adhering to them.

This is where design systems usually step in. Lyft’s Design Systems team created an internal tool, Lyft Product Language (LPL), to make the guidelines easier to follow. Foundational elements and components follow the guidelines, so feature designers and engineers get a large amount of adherence for free. In our most recent survey, 98% of designers and engineers agree that LPL has delivered on efficiency and consistency.

However, it is a common misconception that by using the system that you have followed all of the guidelines. Not all guidelines can be encapsulated by the design system & need to be defined or documented within the feature itself.

But not everyone followed LPL and, in turn, did not follow the guidelines. Design Systems made following LPL mandatory using linters — a bold choice. This decision, whether or not we knew the weight of it at the time, turned these guidelines into policies. They were no longer general recommendations, they were mandatory and had consequences. Teams couldn’t launch unless they complied.

The foundational elements that are enforced (color, typography, and iconography) through linters have a high usage rate. LPL components are used the majority of time, and we have seen an uptick over the past year with folks using them all the time. We continue to see engineers receiving designs that could be LPL eligible but not adhering. The top action engineers do when receiving these is pushing back to design to use LPL (or just using LPL and not telling design).

It is also worth noting that there are many guidelines that are not linted as part of LPL.

The guideline iteration loop

This has created tension between the two disciplines. Here is a real example that happens frequently:

By the time this information gets back to the designer (IF it gets back to the designer), they’ve moved onto a new project. It usually falls on the Design Systems team to assist the engineer in fixing the issue. Captured in this narrative as well is the misbelief that LPL, the design system, created the rule vs something that the team should be following outside of LPL. This creates tension between the Design Systems’ team and the feature team — we have a separate solution for this.

Closing the gap

Design Systems and various task forces have attempted to make quality appear mandatory to designers through onboarding, classes, handoff checklists, and Figma plugins (like LPL Lint) to shorten the iteration loop and repair the relationship. We know that this can continue to be improved because we have surveyed low guideline adherence percentages. So what now?

Education

Set clear expectations through a mandatory education program on our various guidelines. Using programs like Docebo or Deque University allows for managers to be notified who has completed the training or not. This also requires managers to prioritize the time it takes to complete the course.

Process

Have a defined design process that includes handoff expectations. Every designer is expected to go through the handoff checklist, which hopefully will become second nature over time, and requiring use of the Figma linter will result in less lint checks at the end of engineering. Managers and PMs are responsible for checking-in on if these tasks are completed and protecting the designer’s time to do them.

Support

Hire design guideline specialists with QA capabilities. Designers who are extremely well-versed in guidelines who can provide guidance & spec’d designs on a request basis. They can take on the QA work when designers don’t have enough time and can educate them when they don’t have the expertise for a comprehensive handoff.

Last thoughts

If this problem space is interesting to you, we’re hiring for this role now! We’d love to work with you on how to further refine this thinking.

What are other teams doing to close this gap? Where have you had success and failure? What did you learn?

I’m Linzi Berry, currently design systems & illustration senior manager at Lyft. I sweat the details so you don’t have to. Please subscribe!

​​The Guideline Gap was originally published in Tap to Dismiss on Medium, where people are continuing the conversation by highlighting and responding to this story.

Text makes up a large majority of the content in internal, operational products. Between the many labels, values, and other helpful information crammed into charts, graphs, column lists, and the like, text serves many functions and takes many forms. So when we updated our spacing and layout system for internal products, we knew we would also have to tackle our typography.

The lay of the land

We have 4 core typography styles in our design system which help our consumer products keep it simple, stupid (K.I.S.S.): Headline, Title, Subtitle, and Body styles.

In most of our consumer-facing contexts (largely mobile), designers only really need to combine a few of these styles per screen to deliver a simple, consistent, and purposeful experience for users.

But when you put together a multi(verse)-zone layout with site-wide navigation, in-page navigation, a data table with pagination, corresponding filters, and a side panel for additional details, you begin to ask yourself if more (Loki) variants would be helpful. We found that to be the case while assessing the (mis)use of our type styles across the 75+ operational products at Lyft.

Designers would find themselves using semantically improper styles simply to get the right size or weight in the right place.

To get a more holistic and detailed understanding of designers’ needs, we looked at responses from a survey with 15 operational/internal tools designers to gather thoughts on what aspects of the typography attribute needed to change in order to support their products:

Operational products need to fit in a more dense space, like tables, charts, and graphs. Need smaller components and text that can be suitable in a limited space.

Size of some fonts is too large to work nicely in all cases.

For typography we want smaller type sets and open-source friendly font families.

Need monospace font for numbers in a table or column list, to enable easy scanning and comparison of digits vertically.

Across the board, we heard that our Core Typography styles and guidelines did not accommodate all the operational typography use cases. Thus sprung forth the TVA (Type Variance Authority) — with the mission to not only prune the biggest offenders but also to find the variants needed to support typography for data content.

Purpose-driven typography

Before jumping straight to new type styles, we partnered with designers from 10 operational products to collect key screens and organize distinct typographic use cases into an audit table. We determined categorical groupings of type properties or patterns (along the y-axis) by asking the question:

As a designer placing this piece of text on the interface, what purpose or functional role does it play in the experience?

Perusing these use cases across the key screens, we saw that designers needed clarity and guidance on styling text within:

1. Section headings — text headings for sections or groups of UI
2. Label:Value pairs — the text combination for displaying data
3. Interactive elements — any actions or controls that include text
4. Visual indicators — any other UI that includes text and provides information rather than interaction
5. Code — text that represents code content

We also assessed other stylistic and formatting variants such as usage of secondary shades of color, text weights, all caps, monospace numbers, and more.

As we identified these functional roles of type, we documented the overarching problems with the current type styles and uncovered the need for (1) further guidance on using the core type styles and (2) additional styles to support data text.

Data text styles

What kinds of data text do we need to account for?

Looking at two-column layouts, data tables, forms, and other data viz contexts, we found that label text and value text are the most prevalent type of content (pun intended) on a given operational product page. While label text simply acts as a title for data values, value text can take shape as basic text, alphanumeric characters, static vs. dynamic numbers, dates/times, currency, and more. We also need to consider that value text often lives within structured layouts such as tables — that’s where monospace numbers and text alignment for tabular data comes in. Lastly, our products need to display code snippet text in some contexts.

With all these unique use cases and only 4 core type styles to work with, it’s no wonder that we see that every product or even a section of a given page is styled so differently. Size? Weight? All caps? Shades of gray? The permutations are endless.

To address this, we decided to add a new set of data type styles and usage guidelines for Labels, Values, Monospace values, and Code. These aren’t intended to replace the existing core type styles but to add another layer of functional typography to the system, equipping designers to present text data content more purposefully, consistently, and confidently.

Deciding on the sizes/weights was pretty straightforward; the hard part was actually determining that these type styles serve a semantically unique purpose. Rather than arbitrarily dictating (we practice the art of diplomacy!) what we think would work, we identified designers’ most commonly used sizes/weights, stress tested with our key operational product partners, and added to the type ramp accordingly.

Supporting smaller sizes

Another common finding across our operational products was the need for smaller heading sizes for additional levels of information and data. So we added two more!

Our Headline styles play the role of heading up entire sections or groups of content. Not to be confused with our Title styles, Headlines are crucial for users on screen readers to navigate through headings and sections on a given page. Title text usually sits at a level lower in the IA to label primary content.

When less is not more

As systems thinkers, we want our partner teams to create experiences with the right tools for the right time. We all like to say that “less is more,” but when is less not more?

When the lack of choices obscures purpose.

This story is part of Lyft Product Language’s series on How to Systematize Internal Products.

Up next: Russian Nesting Figma Libraries (coming soon)

Typography for Data was originally published in Tap to Dismiss on Medium, where people are continuing the conversation by highlighting and responding to this story.

Update: Check out our talk at Figma’s Schema conference

Design systems often start as a way for product organizations to increase their efficiency, consistency, and velocity. Organizations invest a lot of time and resources upfront into creating shared component libraries to bind design and engineering together. Typically, these resources live in both design tools and code and serve as two sides of the same coin: supporting the end-to-end product development process and ensuring designs can be implemented efficiently.

But, while a lot can be solved through these assets, even the most robust component libraries can sometimes feel like they’re not delivering on their potential value. Collectively, we have worked on 9 Design Systems at companies ranging in size from early-stage startups to massive enterprises. Across the board, we’ve learned the hard way that asset libraries are necessary but not sufficient.

For example, when we worked at companies which lacked documentation, we spent all day answering context-related questions and providing recommendations on how and when to use specific components over others. Similarly, when we worked on teams that neglected incorporating systems thinking into onboarding, we observed “brain drain” as senior systems designers and engineers left the company and took their institutional knowledge with them.

Like any other product, a design system is only as useful as it is usable.

Here we’ll talk about all the different resources (design libraries included!) that have helped the Lyft Product Language (LPL) get used by 97% of product teams at Lyft — enabling system users (designers, engineers, product managers, etc.) to build products and features at scale with Lyft quality standards embedded every step of the way.

Onboarding

Systems thinking starts during Week 1 at Lyft. Shortly after newly hired designers and engineers learn about Lyft’s culture and get their tech environments set up, they take Mobile and/or Web system onboarding labs (mini design/engineering projects overseen by onboarding mentors). These labs help new hires learn:

• What assets and resources live in the system
• How to use existing system assets (and how to adapt them)
• How to communicate and collaborate with cross functional team members
• Where to get help

By incorporating system citizenship basics into onboarding, we help new hires ramp up more quickly and contribute more effectively in their first few weeks. Just like the system, the onboarding labs are living documents. When system processes evolve, so do our labs. This way, institutional knowledge isn’t concentrated within a small group of people but rather distributed across the entire organization.

Libraries & Tooling

LPL is a multi-platform system with design and engineering asset libraries for iOS, Android, and Web products. While some components may have platform-specific differences, across the board we strive to make our libraries platform agnostic and as easy to use as possible.

Design Libraries

LPL’s design libraries started as sticker sheets in Sketch where designers could view all the system components within a single file and copy/paste components into mockups. When we migrated our libraries to Figma in early 2020, we took the opportunity to up-level our libraries and incorporate features that Figma offers — like making it easy for designers to search and discover components in the Assets panel.Consistently naming and ordering component properties and variants

We make sure our Figma libraries are easy to use for engineering partners as well by clearly communicating what components are part of the system in the attribute panel. When engineers look at designs that have been handed off, they can see “[LPL] Core UI — [Platform]; [Component name]” on all our system components.

We additionally help the engineering handoff process by incorporating redlines into our libraries. All component sticker sheets include component instances with Spacers overlaid on top of them as a quick way to communicate layout values between component elements.

Design Tooling

Our 2 internal Figma plugins (LPL Lint & LPL Dark Mode Switcher) are the icing on the cake for Figma Design System usability. LPL Lint checks selected frames in mockups to see if they’re using LPL color, typography, and elevation attributes. This linter is a lifesaver for design to engineering handoff and QA. Meanwhile, the LPL Dark Mode Switcher does exactly what you might suspect — it switches all the colors in selected frames from Light to Dark mode (and back) using our Figma Dark Mode Color Library. Now that Lyft Rider and Drive apps both support dark mode, this plugin helps designers quickly check mockups to see if visual hierarchy remains consistent at all times of day.

Engineering Libraries

In our engineering libraries, we make it easy for engineers to use LPL components out of the box. Each component has platform-specific technical documentation that covers:

• How to implement the component
• Component customization options including common variants and use cases
• Necessary logic that handles text wrapping and truncation
• State definitions and interaction details
• Accessibility definitions
• Live demos
• And more

Equipped with the component code and technical documentation specific to that component, engineers are able to build at a much faster pace. And by using these design system components, they promote consistency and a high standard of quality across the products they build.

Documentation

Let’s say your team has a well constructed component library in Figma, those components have corresponding iOS, Android, and React components, and every new designer and engineer knows how to use those libraries. If you stopped here, your products would be in great shape: you’d see improvements in product consistency, feature velocity, and design-engineering handoffs. However, it would not be long until you started getting unanswered questions like:

• “When should I use component variation X instead of variation Y?”
• “Why does this component look/behave like this? I think I need something different.”
• “How does my engineering partner implement this into our feature?”

“Where do I learn about the system?”

Enter: the documentation site. This centralized resource helps system users gain context, understand when to use certain component variants over others, and learn from other designers and engineers. We split our documentation into usage guidelines and technical implementation details to help all users at every stage of the product process.

Whenever we add a new component to our libraries or update an existing component, we also update the documentation site so decisions don’t get lost. Anecdotally, we’ve found that just like that old adage — if you really want to master something, teach it –

If you really want to create a good component, write documentation for it.

In our docs, we include examples of the component in situ and we connect the dots between all the different use cases. In fact, the majority of the time it takes to add a new component to the system is spent writing guidelines for it.

“Which component should I use?”

On most design system component pages, we include a decision tree at the top, like a Choose Your Own Adventure book. Like in the Toast component example below, the decision trees ask simple “Yes” or “No” questions to help system users narrow options down within a type of component or between related components. Decision trees help system users:

• Understand how and when to use components
• Discover related components that might better fit their use case that they might not have previously considered

We also make recommendations on how to use and apply components and provide additional information on:

• The anatomy of the component
• Different variants of the component (if applicable)
• How the component interacts on the screen
• How the component appears on different platforms
• Motion details (if applicable)
• And more.

Processes

It’s hard to maintain a system over time especially as team members come and go and as more people contribute to the system. Our design system team processes are like a meta-system — a way for us to ensure each new or updated part of the system is held to the same, high, standards. Truthfully, our processes could be their own separate article (coming soon)! To narrow the scope a little here, we’ll highlight some of the artifacts that come out of our processes.

Every change to our libraries and documentation goes through the same process. We start by writing a project brief detailing:

• High level problems & project goals
• Key design & engineering contributors and stakeholders
• Success metrics
• Potential challenges
• What’s in scope and out of scope
• Rough milestones

We share project briefs with stakeholders in kickoff meetings to align on scopes and timelines. From there, we audit the system and iteratively design a solution. Each new design exploration is documented in an ongoing presentation deck and reviewed in ad-hoc meetings with stakeholders. Finally, we synthesize guidelines around content, style, states, accessibility, interaction behavior, and other design decisions into a written document and/or a new Figma component.

Artifacts

Each system design artifact (brief, audit, review deck, documentation, component) has a standard template so it’s easy for us to take the same level of care with every new component or contribution. The final artifacts get reviewed asynchronously by as many people as possible before getting published to our libraries and documentation site and shared out.

Comms

Along the way, we craft careful comms to make sure system users aren’t caught off guard by the changes we make. Depending on the impact of the changes, we’ll choose to alert people in All Hands presentations, emails, Slack messages, or some combination of the above. We try to keep our messaging concise, bulleted, and spread apart so folks don’t learn to ignore us over time.

All this might seem like overkill. We certainly get a lot of feedback from system users telling us that our stringent processes are a barrier to entry to them contributing to the system. On average, each new addition to the system takes a little over a month start to finish. We like to think that what we lack in velocity we make up for in quality but please let us know in the comments if your team has found a way to maximize both.

Support

While we try our best to make our documents and libraries as usable as possible, we need to remember:

• Not all people are systems people
• No system is perfect
• There is a lot of stuff in the system
• Often the easiest way to get answers about the system is to just ask the people who build it.

We consider ourselves the glue between feature teams. We discourage people from working in silos by enabling conversations between teams and promoting cross-collaborative patterns and recommendations. And on occasion, we evolve the system through component contributions (stay tuned on this future post).

For all these reasons and more, we make sure there are multiple ways for system users to get the help they need from us. Our Slack channel is the easiest way to get in touch with our team and ask both design and technical questions. We try to respond within a couple of hours during ET/PT working days. If users want some in-person time with us to get feedback on work or to ask more open-ended questions, we hold weekly office hours by appointment only to ensure the right team members are there to support. For bugs and feature requests, we have a shortcut link to ticket templates in our project management software. If all else fails, emails (and maybe carrier pigeons or three-eyed ravens) will also work!

We know it can be hard to ask questions — especially in a public Slack channel with literally hundreds of people in it. When someone asks a LPL question, regardless of their attitude, we try to respond with gratitude and thank them for reaching out. We’re just appreciative that ya’ll are using the system! We also research our answers before responding, cite our own sources, and double check with other team members if we’re still not sure so we don’t confuse people with contradictory guidance. All of this is captured in our Support Playbook. No really, we have documentation on how to support our users — don’t you? At the end of the day, if no one uses what we create, then we won’t exist.

All together now!

All of these resources provide our partners with the tools and context they need to work as efficiently as possible together. We learned early on that it was important to take a user-centered approach to our system resources in order to consistently deliver value to Lyft designers and engineers. We not only strive for our users to be aware of the system and to efficiently use it in their daily work but also work tirelessly to ensure it provides value. In our most recent (June 2021) design system engagement survey we found:

• 91% of participants are aware of LPL
• 98% of participants agree LPL provides value, with 80% who strongly agree
• 97% of participants have read at least one form of LPL documentation

What works for one organization may not work for another. Every organization is unique and there is no one size fits all when it comes to building a successful design system. But the hope is that our discussion helps start or further conversations around the resources that you provide for your design system. What does your organization include in your design system resources? Leave a comment below!

This article was written by Evan Maeda, Matthew Spiel, Jeremy Dizon, Runi Goswami, and Michael Yom — 2 former and 3 current members of Lyft’s Design System team. Interested in joining the Lyft design systems team? Check out our openings; we’d be happy to chat!

User-centered Design System Resources was originally published in Tap to Dismiss on Medium, where people are continuing the conversation by highlighting and responding to this story.

A recurring refrain in our conversations with operational product designers was that all our design system components were just too darn big for internal tools. Many of these tools feature full screen data tables and charts. In these information-dense contexts, it’s important to make as much content visible on the screen as possible so users can easily scan, parse, and compare information. Unfortunately, when operational product teams tried to fit our existing components into these contexts, they looked gigantic and out of place.

At first glance, it seemed we needed to considerably shrink down our components to work well for operational products — but how small could we go while still maintaining WCAG AA target size standards?

Space research

Accessibility is a Lyft-wide quality standard and is therefore non-negotiable in our design system. Previously, our internal products largely flew under the radar of this standard because there weren’t many centralized resources or guidelines for them to follow. Unsurprisingly when we brought up the 44px minimum pointer target size in initial meetings with operations teams, it was a big sticking point and a likely deal breaker.

Rather than press the issue further, we did more research. Externally, we looked at how other companies handled the same problems. These articles in particular greatly elucidated the problem:

• Space in Design Systems and Size in Design Systems both by Nathan Curtis
• Using Material Density on the Web by Una Kravets.

Internally meanwhile, we audited our existing web components to see if our current approach to sizing and spacing could be extensible to operational products.

We learned that while we had “Default” and “Compact” sizes of most of our components, those names didn’t consistently correspond to component vertical heights, content sizes (i.e. text and icon sizes), horizontal and vertical padding, or component shapes (i.e. border radius). Several components lacked two sizes entirely and others had different names for their “Default” and “Compact” versions. The component sets had grown piecemeal — a side effect of an oversight in our process.

When we add new components to our libraries, we audit their usage across different product experiences to standardize their sizes. We don’t often evaluate all our components as a set, so over time, “Default” and “Compact” came to mean slightly different things in different contexts.

Before our research, we assumed the crux of the problem was that operational products needed smaller components but that these components would have to be inherently pointer target inaccessible. Through our audit, however, we realized that we had never before approached sizing, spacing, and density holistically. So what we really needed were clear and consistent rules around how to apply density in both consumer and operational products.

Defining Density

Density is an overloaded term and usually refers to screen density or the literal pixel resolution of displays. While internal product teams universally asked for more dense components for dense interfaces, they weren’t talking about pixel resolutions. We discovered through our research that there are 3 dimensions that make a screen feel more or less compact. These dimensions comprise visual density, or the set of spatial relationships within and between visual elements on a screen, including:

• Content size (i.e. type scale, icon scale)
• Container padding and shape — the space within a container
• Layout — the space between screen elements

It seemed like once we defined density, everything else started falling into place. For one thing, our “Default” and “Compact” sizes could now also be defined and standardized. We set standard values for our internal padding, content scales, spacing, and container shapes in terms of our base 8px grid. We also standardized the typography styles we use within operational products (article coming soon)! These decisions had the happy side effect of greatly simplifying our decision making process for adding new components to the library.

Roughly speaking, consumer web products could use Default components while operational web products could use Compact components. But we also called out specific exceptions and provided more granular guidelines for how to mix different densities within the same screen on our documentation site.

Finally, we realized that the third density dimension, layout, was the key to unlock an accessible, visually dense, interface. With our minimum content sizes and visual height requirements, as long as there is at least 6px between each UI element, we can ensure pointer target accessibility for even the tightest of layouts. We just define the interactive area of each component to extend slightly past its visual area and ensure the interactive areas don’t overlap with our component layout requirements. To make it extra easy, we created accessibility helper components in Figma to visually show designers the minimum accessible pointer target area for each interactive UI element.

5 easy steps to fix your system spacing

Our path to spatial clarity has been meandering — fixing spacing in an existing, mature, design system is a messy business. For example, we learned the importance of publishing size changes in bulk rather than individually when system users started noticing that some of their components grew or shrank out of alignment with components we hadn’t “fixed” yet (whoops)! We also learned that only design systems enthusiasts get really jazzed about attribute updates while everyone likes shiny new components, so we started crafting our comms differently to reflect that.

If you are attempting to adapt your system to work for a new visual density or if your system suffers from inconsistent sizing and spacing like ours did, we hope this distillation of our work can help:

1. Audit your system components, decide how many different visual densities you need, and name them.
2. For each density, define values for content size, container padding and shape, and layout spacing in terms of your base pixel grid (bonus: involve system users in the decision making process)!
3. Apply standardized visual density names and values to all existing components (this is the bulk of the work and may take months and an airtight communications strategy to complete — but it is worth it).
4. Create new components so each component has a version for each visual density.
5. Publish visual density changes in bulk to your libraries to reinforce the fact that this is a holistic, attribute-level, change.

Whatever your system spacing journey looks like, and however messy your audit table gets — know that accessible, information-dense, interfaces are possible!

This story is part of Lyft Product Language’s series on How to Systematize Internal Products.

Up next: Typography for Data Products

Growing (and Shrinking) Pains was originally published in Tap to Dismiss on Medium, where people are continuing the conversation by highlighting and responding to this story.

We designed the Lyft Product Language mobile first. All of our design system attributes and components were crafted with small screens, unreliable internet connections, and touch inputs in mind. When we later expanded the system to support Consumer Web products on Desktop devices, we seemingly realized the promise of a mobile first design strategy. Screen designs grew elegantly across different surfaces and our core attributes and components largely stayed the same across platforms. But, like many design systems teams, we drew the line at Operational/Internal Web products.

Over time, Lyft’s suite of internal, operational, tools grew to over 75 — built and maintained by multiple teams of designers and engineers. These internal product teams were largely left to their own devices with no centralized resources and guidelines. As a result, the quality and consistency of these products suffered. In several cases, backend engineers created entirely new products without any designs, designers, or even frontend engineers at all.

70 products ended up being built on top of other systems like Material UI and 8 teams started their own systems — resulting in lots of duplicative work and disparate styles.

Over 6 months, we interviewed and surveyed designers and engineers across these product teams to understand pain points and inform our approach to systematizing ops products. We learned that screen designs and components are usually designed with just one product in mind and then adapted with patchwork solutions when new use cases come up. We also heard that due to time pressures and resource constraints, designers rarely have time to do accessibility checks, define all component states, or write documentation for new features. Understandably, we’ve ended up solving for similar interface constraints and data display use cases in pretty different ways across this fragmented product landscape.

In this series, we’ll cover how we approached reconciling these differences systematically and how we expanded a mature design system to support a whole new suite of products, users, and use cases.

Part 1: Growing (and Shrinking) Pains — Holistic spacing and visual density
Part 2: Typography for Data
Part 3: Russian Nesting Figma Libraries (coming soon)
Part 4: Building Blocks (coming soon)
Part 5: System Citizenship — Adoption, Contribution, and Migration (coming soon)

How to Systematize Internal Products was originally published in Tap to Dismiss on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few years ago, we built a segmented control component for the Lyft Product Language (LPL) design system. You may have read our guide to designing and using selection controls. However, when we recently looked at our component adoption and usage metrics, we found very few teams actually used our segmented control when building products and features 😔.

Our rule of thumb is that at least two products or features need to use a component for it to belong in the system. Product and feature-specific components live in their own, child libraries which inherit attributes from LPL. Segmented control was dangerously close to getting booted from the system. Luckily, we decided to take a closer look at the root of the problem — and ended up improving our entire ecosystem of selection controls. Here is that story.

Problem definition

We started from first principles and asked “what the heck is a segmented control anyway?” Apple says they’re a “linear set of two or more segments, each of which functions as a mutually exclusive button.” They think it’s ok to use segmented controls to navigate between different views. Google disagrees about using segmented controls for navigation and says it’s ok to select multiple segments sometimes — unlike Apple. Google also doesn’t think segmented controls are selection controls at all 😐.

When designing an interusable design system with rules that apply across iOS, Android, and Web interfaces, contradictory platform guidelines like these make it tricky to know which conventions will be the most familiar to users across all devices.

When we first built our segmented control component in LPL, we didn’t necessarily consider this convention confusion. We optimized for internal consistency — choosing to match the visual style of our pill-like toggle buttons.

In theory, we thought it might be likely for toggle buttons and segmented controls to appear frequently in the same contexts since they were functionally analogous to checkboxes and radio buttons. In practice, however, feature designers and engineers took matters into their own hands and created all sorts of permutations of custom segmented controls. When we audited our products, we found 14 distinct segmented control components across 10 different products. Obviously, our existing component didn’t meet the needs of our system users. We didn’t need to remove segmented control from the system, we needed a better segmented control.

Upon closer inspection, we saw the custom permutations differed from the system segmented control in one of two ways:

1. Stylistic differences: Controls with different selection and background colors, container shapes, and/or text styles from the existing component.
2. Semantic differences: Controls used for navigation or filtering content (like Apple allows) instead of selection as intended.

Tackling one problem at a time

The first bucket of stylistic discrepancies was relatively straightforward to address. We redesigned the control to be less similar to its pill-like cousin, toggle button, and more similar to our visually lightweight input fields instead.

One of the big reasons product and feature teams created their own components was because ours wasn’t flexible enough to adapt to a wide variety of use cases. So we also introduced 3 new stylistic variants of the component:

• Text with detail text — for when the extra information helps users better understand the options and make decisions
• Icon — only for when there is enough context for each icon option to convey meaning and not when short text would suffice.
• Primary text — for when the segmented control is the only or primary action on the screen.

To close the loop and encourage adoption, we replaced the custom components in all of the screens we collected during our audit and showed off the new variants in situ. Just like it’s better to use real copy and data over auto-generated Lorem Ipsum, we found it more effective to use real screen designs to stress test our component.

For the semantic discrepancies, meanwhile, we looked across other systems… and found more discrepancies 🤦‍♀️. For starters, there is no consensus on what to name this pattern. In addition to segmented control, we’ve seen it called a button group, toggle buttons, radio bar, or content switch in different systems. And for each new name, there is a slightly different usage guideline. Turns out, this isn’t just a platform convention problem, it’s a meta-problem across all design systems. It’s no wonder that we saw so many different custom implementations of it across our feature teams!

Needless to say, tackling inter-system consistency problems was well beyond the scope of this project. So instead, we focused on making our own system as clear and internally consistent as possible. We created a new component in the system (Tabs!) to handle the filtering and navigation use cases and we updated our decision trees along with component definitions to make the new distinction clear. To further reinforce the semantic difference between segmented controls and tabs, we made the selection states, container shapes, and motion guidelines different between the two.

Our previous definition for segmented control borrowed heavily from Apple’s which literally states what the component is. But the “what” doesn’t help designers make decisions. Now, we emphasize the “why” and the “how”:

Segmented controls allow users to make a single selection from a set of 2–5 options, as a common alternative to radio buttons and dropdown menus. They clearly present all available options to users and are easy to use on mobile devices.
• Use them over other selection controls to reduce cognitive load.
• Do not use them to filter or navigate content (use Tabs instead).

Tying up loose ends

Updating documentation is one thing, but we still needed to make it as easy as possible for designers to use the updated system component. We wanted to avoid triggering potential breaking changes by simply swapping symbols in Figma. Instead, we phased out the old component as suggested by Onfido’s great article on deprecating components in Figma design systems. For us, that meant:

1. Renaming the page with the old component.
2. Moving the page with the old component to the “Deprecated Dungeon” section of our library.
3. Adding a super obvious visual overlay to all variants of the old component, complete with a ghost emoji 👻 as voted upon by our design team.

With the old component relegated, we could finally consider this problem solved.

As long as there is a central system, there will be teams that deviate from it. So often as systems stewards, we seek to reduce and reign in those deviations. In this case, we could have chosen to remove segmented control from LPL because it wasn’t being used. Yet, when we examined why so many teams were choosing to build custom components over using the system component, we ended up with a more varied, more robust, more usable, and better defined ecosystem of selection patterns. As for the meta-problem, if your team calls this component something else or thinks about its usage differently than we do, let’s chat about it!

This article was written by the extremely talented Runi Goswami — a product designer on the Lyft Design Systems team. Please subscribe!

A better segmented control was originally published in Tap to Dismiss on Medium, where people are continuing the conversation by highlighting and responding to this story.