User-centered Design System Resources
How to go beyond asset libraries and build systems for people.
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!
