Why a cookie-cutter design system won’t work for your organization

There are a lot of great design systems out there. And these days, it seems that every organization publishes their design system publicly. And that’s great for transparency and inspiration. But it’s not a good idea to just use their template for your own organization.

“A design system isn’t like a code of ethics. It’s more like a set of company values. It’s good for everyone to share the same ethics. But it’s not necessarily appropriate for every company to share the same values,” says UX Interaction designer Alex MacDuff.

The bottom line is that trying to Frankenstein everything together from other places will leave you with something less desirable: an ineffective (but very organized!) design system.

Trying to Frankenstein everything together from other places will leave you with something less desirable: an ineffective (but very organized!) design system.

Building a design system is kind of like being a personal trainer. A trainer tailors workout and nutrition plans to a person’s goals, lifestyle, experience, body type, and budget. In the same vein, you need to consider every team’s unique needs and feature sets and  build a design system around those distinct demands.

It didn’t take us long to notice that Lyft’s design system team was doing something right. Linzi Berry, Product Design Systems Manager at Lyft, has been instrumental in thinking through the problems that face folks using a phone in real-life situations. Customers aren’t just sitting in a perfectly lit room. The majority of the time, Lyft customers are on a busy street and drivers are looking at tiny phones from 2-3 feet away.

We chatted with her about her approach to building Lyft’s design system, core principles and learnings, and how her team communicates the design system out to the broader team.

Why did Lyft decide to build a design system from scratch rather than use something off-the-shelf (Material, Bootstrap, HIG)?

We are building off of and elaborating on Material Design and the HIG for core components within our custom system. We use those systems as a starting point because they’re backed by research. And they’ve created expected usability paradigms with users. So when we think about building a sheet, we first consider how a user expects to interact with an Action Sheet on iOS and a Bottom Sheet on Android, then solve it to meet our users’ needs, achieve parity across systems, and match our visual design style.

We also need elements that don’t exist in either system — especially when it comes to the map, which is a large portion of our app.

Does your design system have rules or principles that you follow? How did you arrive at your rules or principles? Who had a part in crafting them?

Of course!

Our goals, defined by the design system team’s designers and engineers, were created as solutions to the problems our company was facing internally and externally:

• We aim to deliver consistency and predictability to our products.
  Multiple designers solve the same problem, unbeknownst to each other. Others see those solutions, adopt, and adjust them to their needs. This further results in a disjointed experience for the user. The same button may do different things or the different buttons may do the same thing.
• We aim to reduce design and engineering time and debt.
  Copy and pasted code means everything is a one-off, which takes time to create. Not to mention if we want to update the style of a button, we need to hunt for every use and adjust it.
• Today we aim to raise the quality of our experiences for every person and every edge case.
  In the past we didn’t put a strong focus on accessibility, localization, and solutions for every state or edge case a component might encounter.
• We aim to create a universal design system that works best for Lyft on all platforms.
  Due to fast timelines, our designers usually only hand off iOS designs. Our Android developers look at those designs and make assumptions for how to solve it in Android. Sometimes the standard solution in the HIG or Material Design does not work best for us.

Additionally, our executive leadership team defined Quality Principles that applied to every department throughout Lyft. Our systems team turned those more holistic guidelines into a tangible checklist for components.

How do the needs of your users differ from other companies?

We have two types of users:

• The riders and drivers who use our apps
• The designers and engineers who use our system

Our riders and drivers use our app differently in two common scenarios:

• “Focus” state, which is most commonly referred to when someone has the Lyft app open on their mobile device. The “focus” state requires us to meet guidelines presented in the HIG and Material Design, essentially designing for an experience 12” from the user’s eyes. That means 48x48 tap targets and type size above 15pt for legibility.
• “Drive” state is more unique to Lyft. While our Rider app currently only exists within the “focus” modality, our Driver app uses both “focus” and “drive,” depending on what the driver is trying to do. This state required us to expand the guidelines presented in the HIG and Material Design to work for an experience 20” from the user’s eyes. That means 64x64 tap targets and type size above 24pt for legibility.

In order to best meet our users’ needs, we really have to focus on educating designers and engineers on what modality to use  and when, and provide clear guidelines on component usage that may change between modalities for safety and accessibility.

How do you communicate your design system to your team? What did you think might work, but didn't?

Systems design is not only scientific and meticulous, it’s the mastery of interacting with people in a sensitive and effective way. It takes human connection and empathy to go from a sticker sheet to a living, thriving system.

The time we invest in relationships with designers and engineers (and their bosses, their bosses’ boss, their project managers, and the accessibility guru down the hall) is as important as building the system itself.

Systems design is not only scientific and meticulous, it’s the mastery of interacting with people in a sensitive and effective way.

Linzi Berry | Lyft Product Design Systems Manager

In order to communicate our system in an effective way, we…

• Empathize with teams and their users. Have meetings with teams to drive home the benefits a system provides and, arguably more importantly, how much we truly care about them and their users’ needs.
• Reassure stability. Piecemeal updates and additions can be overwhelming and make the system feel unstable. A consistent, batched workflow and announcement process sets expectations and documents why we did what we did.
• Educate, don’t enforce. We see ourselves as teachers, not the police.
• Be flexible. By approaching our system as a living document, it remains flexible enough to be open to new ideas, challenge what we’ve created, and pull in new paradigms as they are proven successful.
• Share ownership. Designers and engineers desire ownership of their work. But that can be difficult when you’re using a system you didn’t create. By creating clear pathways for all stakeholders to get involved, we can share ownership.

In my experience, the hardest thing for any team when it comes to communicating a design system is constructing clear and consistent communication avenues.

Depending on your department, you may use Facebook Workplace, Slack, JIRA, Google docs, email, etc. and your interpretation of effective communication can drastically change depending on what your team uses. I recommend considering your teammates’ communication habits and routines, and sharing updates wherever most people already spend their time.

Ultimately, we ended up sticking with a bi-weekly email with highlights because we came to understand it was the one place everyone looked.

Thanks so much, Linzi, for sharing your insights with us!