Writings

My Design System Principles

Design systems are my jam. A perfect niche for a designer/developer such as myself. I’ve been part of about five design systems, with the longest run being about four years (and counting). So, I have some opinions about what makes a good design system, and between the lines are lessons learned.

Some of these are related to the culture and conditions surrounding the design system, and others about the content. And, they all happen to start with C:

The design system is...

Context-aware

The design system fits the specific product or company it is made for. It could be based on a generic headless system, but should be adapted to what makes your product unique, instead of aiming to be a one-size-fits-all solution.

Collaborative

The design system connects and serves all product functions, containing design, code, content guidelines, and documentation. It is informed by all the functions it serves, and they each have a hand in shaping it, ensured by the design system process.

Continuously improved

The design system is not a one-and-done project that magically fixes the entire product development process and end product. It’s an ongoing practice. The company and its products evolve, and so should the design system.

Just as the whole system is never complete, no one component needs to cover every imaginable scenario and variant from the start. You might never need those options, and they should always be easy to add later.

Centralized at the core

Ideally there can be a dedicated design system team with designers and developers, maybe even a PM. Contributions can come from product teams, but at least one person well-versed in the design system should sign off on final designs and code review.

The need for a full team may change with the lifecycle of a design system. With or without a dedicated team, assign one final decision maker who can settle disputes and keep things moving.

Communicated

The design system should have an established communication cadence, which can be included as steps of the process. Communicate early and often. Make a design system introduction part of designer and developer onboarding. Share plans and previews, announcements and demos. Hold office hours, run feedback sessions or surveys. (Communication is a two-way street.) Have channels open for questions and even check in on code review and drop docs where appropriate.

Chosen

Like the foundation of product-led growth, the design system should be so good, people want to use it. The design system team can focus on quality and effectiveness in co-creating components.

Design system adoption can be rolled out in alignment with team goals. Different teams and products may have different rates of adoption.

Considered

The design system includes responsiveness, accessibility, micro-interactions, and pixel perfection, so the implementor doesn’t have to do it all. This goes along with the design system being chosen -- it does work that most people aren’t willing or able to make the time for every time, enabling higher quality outputs with less effort.

Clear

Working with the design system is intuitive and predictable, it is internally consistent and there is no unnecessary cruft from Figma to documentation. This takes effort, especially when working with multiple contributors, but code standards and style guides help.

Composable

Components work together to create larger patterns, much like the standard building blocks of the web. Guidelines are needed to define how components can be composed, but don’t necessarily control every possibility. This is more flexible and leaves room for judgement and creativity.

Complete enough

The design system does not contain every component, only the most used ones to create something like 80% of screens. (Three times is a pattern, as a rule of thumb.) Specific experiences may have unique UI, and that’s expected and fine. Products can have their own reusable presentational components that aren’t in other products and don’t need to be in the main design system, yet.

Consistent, not complacent

Consistency is heralded as one of the main benefits of design systems, bolstering the aesthetic-usability effect, leading to increased user trust. But, when using the design system, consistency should never come at the expense of the user experience. Don’t be satisfied with a “technically correct” solution if there proves to be a better one. The final product is still cohesive when built on the same foundational elements and design tokens.

This goes along with continous improvement and is an invitation for design system consumers to be active in improvement: could a component be updated, or is a new pattern emerging?

Conclusion

A good design system will find a balance of control and creativity. The design system is an indicator of the overall product culture and feeds back into it, contributing to the conditions in which people making software work. Care at the component level travels up, eventually affecting customers through a cohesive, well-crafted product.