A day dedicated to design systems
Figma is planting its flag in the ground as the leader in building and enabling design systems. At the 2021 Schema Conference, Figma's design systems conference, Figma brought together leading designers from across the biggest names in tech, including Netflix, Asana, and Google's coveted Material Design System, to talk through how teams are designing systems to scale.
At Devbridge, we're no stranger to launching and maintaining design systems for clients big and small. We've had our unique trials and successes in this space that Figma's Schema talk highlighted. Here are our biggest takeaways from the conference, courtesy of Devbridge product designers.
Treat the design system like a product.
Jan Toman of Productboard gave a great talk on the tactics of building and enabling a design system for consuming designers and developers. His tutorials highlighted that a design system is itself a product that can succeed or fail in the hands of its users. A sound design system and its components require clear guidance and semantic documentation so users can leverage components correctly and efficiently.
Figma enables designers to be complete owners of design documentation. With that comes a responsibility to work with other designers and front-end engineers. A great example is the comparison of a design system API call and a Figma component variant.
Think about color like a developer.
Asana's talk on design tokens was a great tactical walk-through in building and maintaining sound color principles. Designers often entered a design system as a consumer and just snag the colors that felt correct but weren’t treated consistently.
Ivy Wang, Software Engineer at Asana, highlighted a method of codifying color uses through sentiment-based tokens. Rather than having just a straight set of reds and greens, there is a second layer of how those elements relate to headlines, buttons, and other elements through labels of [Sentiment][Usage][Prominence][interaction]. Then, when a designer is building a default button, they do not have to eyeball various colors and states.
The Asana team also introduced two products:
Leonardocolor.io to generate consistent and accessible color pallets
Style Dictionary to codify token-level designs across all platforms (web, ios, android, etc.) so that designers and developers can quickly generate and federate improvements to color pallets
Going a step further, the closing session demoed the latest release of Material 3's ability to build custom and accessible color pallets from a user's phone background. Designers use the tool to combine an app's design language and the user's aesthetic to create a custom experience for users.
The tooling and methodology have many applications for product designers working on software that gets white-labeled, re-themed, or suddenly needs an infamous dark mode. In turn, designers become much more empowered to approach color with a rigid set of principles.
Build design systems to scale.
How do you create a design system that works at scale, especially when that scale could be up to 6,000 designers across multiple devices, platforms, and products? Jennie Yip, Lead Designer at Atlassian, spoke about how her team built and then re-built a design system that worked for the whole team.
Atlassian is the parent company behind productivity software like Jira, Confluence, and Trello, among others. As the tools became more popular, the teams behind them grew exponentially, with Atlassian hiring around 1,000 new designers in the last year alone. The influx of new designers meant that the team needed to take a hard look at its design system, stress-testing it to ensure that the components worked for a wide variety of needs.
At first, the design systems team tried to modify the existing library. However, due to the size and scale of the Atlassian design team, communication began to break down. Jennie cited Brooks’ Law, which states that as teams scale, lines of communication grow to the point of becoming unmanageable.
To combat this breakdown in communication, Jennie shared a few key learnings from her team's experience.
Documentation is crucial.
Create an open document to serve as the single source of truth and give the entire team one shared language. For example, the design systems team created a Google site with up-to-date references and use cases.
Component libraries aren't design systems.
The system components should be adaptable and applicable to many uses. Don't let the design system become a dumping ground for one-off elements. Use an editorial eye to ensure that every component can serve multiple purposes.
Communicate with developers.
Keep developers creating components informed. Jennie shared a quote from Nathan Curtis on documenting components, "Be wary of design and code split. While convenient to author and publish early on, long-term risks may outweigh benefits."
“We fail multiple times until we are successful.”
- Jenny Yip, Lead designer at Atlassian
Jennie and her team went through multiple iterations of design systems. They learned from their early shortcomings and built a system design that could scale, work on multiple platforms, and, most importantly, was documented in a consumable way.
Teach others how to use the design system.
Once the design system is built, how do you set it up for success and being used by consumers? Designers often look at systems thinking in terms of product delivery. However, it's important to zoom out and look at the company using the system. The design and engineering team at Lyft shared their approach to system thinking and how they helped build a more engaging onboarding experience.
The team shifted the approach to onboard designers and developers with interactive labs with droning videos and internal documentation. Each lab tackled common problems that engineers or designers faced onboarding. The team built visual resources to guide designers using the design system and decision trees that mapped out frequently asked questions, helping the designer self-learn.
Figma is the tool. Designers are the resource.
While Figma has become a game-changer for product designers who now use the toolset for a myriad of products built for clients, design systems are more than just tooling. Designers using the systems and tooling have stories of success and setbacks. The tooling only gets design so far. All the decisions, documentation, resources, user error, and adoption fall in the hands of designers to expertly execute and share with the consumers of their design systems.
