So stated Lauren LoPrete at Figma’s short and sweet Schema conference last Wednesday. With a grab-bag of the most interesting talks from New York, London, and Tokyo over the past few weeks, speakers shared their experience with design systems from the perspective of individual contributors all the way up to senior leadership, wrapping up with a live speaker Q&A at the end.

Tension between freeform & structured design

Jacob Miller, product manager at Figma, kicked things off by expounding on the age-old tension between structure and creativity. Design systems are constantly increasing in complexity: more component variants, expanded theming considerations, and greater operational process surrounding it all.

Regarding process, us designers can definitely crib some practices from DevOps. Component override regression tests and branching & merging could certainly be integrated as part of a test-driven workflow within larger design systems. However, we do need to be careful. If our design processes stray too close to development standards, we risk losing the spark of creativity and flexibility that can really push a project forward. The purpose of a design system is not to reduce the possibility of making mistakes, but instead to reduce the friction between designers and innovative new ideas.

Slotting subcomponents in a design system

EightShapes' Nathan Curtis dove right into the weeds, showing how a design system can best handle the common situation of a designer needing a slight variation on a standard component when its built-in properties don’t fit their specs. The two immediate solutions seem to be either detach the component and build something fully custom, or request an update from the design systems team. Neither are particularly desirable, though, as the designer is forced to choose between opening up Pandora’s box of inconsistencies, or potentially needing to wait months for their request to be properly integrated into the design system.

The better solution, in Nathan’s experience, is for design system components to be fully built from subcomponents that can be slotted in and out. This structure requires a bit more forward thinking, but allows for wildly different layouts within the exact same component, giving designers flexibility within the constraints of the design system.

Despite subcomponents making things easier for design system consumers, there will always be some work and tweaking necessary—and it’s the job of the design system team to communicate just how much less work it is by building in this way.

Executive level support for using design systems

Lauren next raised the stakes by talking about getting support and buy-in for design systems at every level of your organization. As a senior product manager at Dropbox, she’s had the experience of communicating with designers, managers, & senior leaders, and knows what kind of support is needed at each level. Her core tenet?  “Demonstrate value and align with what the people in power care about.”

When talking with designers, establish trust by asking how you can help them be a better designer, and make it easy for them to give feedback. For managers and senior leadership, who have likely not used the design system itself, figure out what’s important to them in order to build a shared understanding. Then, communicate the value of the design system in a language they understand—usually via metrics and a brief summary of its benefits.

“Influence is not reliant on you having authority.” Anyone, at any level of the organization can be a strong advocate for a design system. Since a good design system should be invisible, you just need to consciously point out its value to the right people in the right way.

Scaling design systems up and down

We also heard from designers at Uber, Zalando, Brainly, and Atlassian on how they manage their organizations’ sprawling design systems with the help of automated metrics like design coverage, plus internal plugins for operations such as linting that are more commonly associated with DevOps. Within such large organizations, a design system definitely needs to be treated as a product in its own right.

For us in the client services world, though, the question was thankfully raised in the Q&A about how agencies can best use design systems. The hard truth? We can’t always. Some projects will always be too custom, too small or too quick for it to make sense to invest in a design system from the get-go. Despite the constraints, a general-purpose design system like Material could still be the right choice for getting started quickly, precisely due to its inflexibility. Later enhancements and refactoring (assuming the client sticks around!) could start to smooth out some of those rough edges.

Overall, this year’s Schema presented a nice, condensed selection of talks hitting on many different aspects of design systems, from actual component creation, to getting buy-in across all levels, to managing the inherent complexity within large organizations. Lastly, big a11y props to Figma for having live ASL interpretation! 🤟