My favorite thing about working on design systems—besides this—is showing other designers how to adopt the system. Teaching them that it’s not meant to stifle creativity but rather get them from point A to B faster and with less frustration—and meetings.
There are a variety of approaches one can take when building a design system, not to mention the needs and preferences of the team that need to be considered for successful adoption.
They always say a strong foundation is the key to building anything made to last—design systems are no different. Creating the components is the easy part; it’s establishing the token architecture, sub-systems, foundational styles, and nurturing team relationships that allow design systems to work and companies to scale.
Any successful project hinges on maintaining good relationships with your peers. This often gets overshadowed by a design system's technical needs but is one of the most important aspects of a design system—without adoption, a system is useless. It's essential to create a safe space for others to express their needs and concerns and to listen.
This is created in heavy collaboration with engineers to ensure alignment with code. Currently achieved by using Tokens Studio, a Figma plug-in that syncs directly to GitHub, where developers can then use Style Dictionary to transform these tokens into their chosen code language.
Design tokens allow a company to establish its visual language and then transform it as needed into color modes or entirely new brands with much less effort and cost than building each from scratch.
A design system is the result of many sub-systems working together. For example, the type scale impacts how components are sized, and button hierarchy impacts the styling of all other interactive elements.
It's essential to be aware of how making one edit can cause a ripple effect throughout the system.
A product may be complicated under the hood, but the end-user experience needs to be intuitive and easy to use. One way I achieve this is through t-shirt sizing—all components of the same t-shirt size work together and can be adjusted to create hierarchy.
I’ve experimented with several ways to construct components in Figma that balance the needs of aligning with code, easy for consumers to use and system designers to maintain.
Using an atomic design approach for building components allows for handling sizes at the atomic level instead of having every size for every component. This means creating various sizes for atomic components that get used repeatedly and nesting them inside more complex components. This keeps file sizes and component matrixes down.
Whenever possible, I avoid using the concept of unpublished base components as I have found that they make it harder to troubleshoot issues and make the user experience more cumbersome.
While written documentation is needed to give consumers a place to find out everything they need to know about a design system component, education usually happens in the form of office hours, sitting in on design reviews, and training workshops.