(last updated: )

Design Systems, Pt. 9: Conclusion

Explicitly defining the rules and constraints of a design systems enables us to create consistent designs more easily. By defining a set of design tokens, we add constraints on the colors, font sizes, margins and paddings we can choose from. By defining the rules of our layouts, we know how our designs should behave on different viewport sizes.

While the examples in this article series are written in SASS/SCSS, the main takeaway should be the underlying principles for defining a design system and enforcing its rules.

Parts of the system and guiding principles

  1. A standard format for design tokens. This standard format should include the set of design tokens that need to be defined for any project as well as naming conventions that should be enforced across all design documents and across the code base.
  2. A standard project layout. Adhering to a standard project layout makes it easier to get started, to keep a clean code base, and to switch between projects.
  3. Automatic enforcement of the design rules. It should be easy for developers to do the right thing and ideally impossible to do the wrong thing. We defined variables in our code base and added accessor functions to reference them, so that we get compile time errors if we try to use a value that does not exists. Rules can be further enforced by using a linter like Stylelint to warn us when we use raw values instead of an accessor function. Utility classes are automatically generated from the design tokens.
  4. Emphasis on global defaults and local exceptions.
  5. Emphasis on components and layouts. Utility classes should mainly be used for exceptions and one-off adjustments. The bulk of the styles should be defined in the form of reusable layouts and components.
  6. Support for theming.
  7. Preference for web standards. In the examples, SASS is used to generate custom properties and classes and for conveniences like nesting, but the actual styles are still written in standard CSS.
  8. Reusability across projects. The solution should be independent from any particular frontend framework. We defined a setup based on a global style sheet that can be pulled into any project. An alternative could be a library of reusable Web Components that can be customized by passing the custom properties we defined for our design tokens.
  9. Automatic generation of a style guide. It should be possible to export the design tokens from the code base, so that a style guide can be automatically created, without the need to update it manually, should any changes occur. If a library of reusable components is built, automatic documentation would be ideal.

What’s next?

The solution sketched out in this series is spread out over nine articles. I started putting together a starter kit based on these ideas at woylie/tinnef-scss-starter-kit.

See Also