3

Lessons learned from design systems conference by Figma 2021

 2 years ago
source link: https://www.devbridge.com/articles/product-design-system-takeaways-figma-schema/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Top takeaways from Schema Conference 2021 by Figma

Jonathan Allen,

Olivia Challenger,

Rebecca Rother

10.19.21

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.

Design system API
Productboard designers work with developers to mirror component code and Figma component variants. Credit: Mastering the art of code - aligned UI kits Jan Toman, Design System Lead at Productboard

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.

Color coding image
By organizing colors in Figma design systems by sentiment rather than color, Asana designers can avoid subjective and inconsistent color usage. Credit: Design tokens on Asana's Design Systems team | Asana Design Team

The Asana team also introduced two products:

  1. Leonardocolor.io to generate consistent and accessible color pallets

  2. 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.

Google material
Google will enable Material Design-powered applications to pull variables from user settings to inform applications’ UI styling. Credit: Material You and Figma Ivy Knight, Designer Advocate at Google, Rody Davis, DevseloperDeveloper Advocate at Google

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.

Group sharing image
Credit: Reimagining Atlassian design system | Jennie Yip, Lead Designer at Atlassian designer at Atlassian

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.

Decision tree image
As part of Lyft’s design documentation, they include decision trees to help designers implement components consistently. Credit: User-centered design system resources | Lyft Design Team

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.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK