5 Pillars of a Design System

Design Systems are beasts that want to get tamed. With the right preparation, diligence and perseverance we can get it done.

Tim Schoch
May 2, 2019 · 11 min read

Design Systems Series

This concept is the first part of something bigger:
Part I 5 Pillars of a Design System
Part II Design System Checklist
Part III Design System Resources and Links

Today, design systems combine a style guide, UX patterns and functional components into a stand-alone product that gets maintained with a long term focus.

At least that’s my definition of a design system. We can find others online — in the end, the one that really matters is the one that fits our organisation’s needs.

The express train on the top is fast, while the cargo train on the bottom can handle heavy loads.

Design systems exist to simplify building other products. There is no warrant for a design system in itself.

If you only wanted to learn one thing about design systems today, this quote should be it. I know, it sounds obvious, but it’s the most important thing to remind ourselves when designing a system. It keeps us humble. And helps us find the balance between gold plating the design system to spoil our inner designer or building a robust design system that handles the tough stuff.

Pillar 1 — Sell our Design System

The first step we take is to find out what already exists and learn about the expectations on what our system should offer. To learn about this we talk to our colleagues, the users (devs + designers) and to our sponsors within our organisation. If our organisation is already open to the idea of a design system, finding those needs and discussing possible solutions can be a very collaborative process. I’ve heard of instances where the buy-in was already so strong after the initial research that a pitch wasn’t even needed anymore.

Pillar 2 — Research our Design System

We rocked it! Funding is secured and now we can start with designing juicy components, right? Nein, das ist falsch! ;) — before we start designing fancy components, we want to do some in-depth research first. Even the cutest Design Systems have the tendency to grow into unmanageable beasts if we don’t attend to them thoughtfully.

Pillar 3 — Design our Design System

When starting a new design system we want to start small. Every feature we add to a component increases the complexity in the code, in the patterns, in our documentation and makes testing exponentially harder. As product owners of a design system we need to find the optimal balance between reduced components and enhanced functionality.

All Layers of a Design System depend on each other

Pillar 4 — Build our Design System

While implementing the components for our design system, it’s usually a good idea to only write code once (DRY principle). On the other hand we don’t want all variations and states to be crammed into one master component. With every additional feature, the possible combinations within a component increases and with them the possibility for edge cases that break it. Which in turn makes the components a nightmare to test. At some point it’s easier to build distinct components for different variations. It’s up to our devs and their UX designer to determine the right moment to split a component.

  1. Interactive demos for our components (storybook)
  2. A documentation system to add our explanations
    and embed the interactive demos (zeroheight)
The actual code and the documentation are actual deliverables, while the interactive demos are a way to enhance the documentation.

Pillar 5 — Maintain our Design System

Most design systems these days are published as npm packages (or something similar) and included in the build scripts of the final products. In most cases, we’ll have to provide some infrastructure along with our design system where the package can be published. Often these requirements are already defined and we can check with our product teams to find out what they prefer.

We break up our design system into sub-packages. Our product teams can now pick the desired plugins to create a tailored design system.

Final Notes

While the initial creation of a design system can flow chronologically through these pillars, once we’re live we often find ourselves doing work in all five simultaneously. The product owner might be securing more funds while our designers research and design a new component and our devs code and maintain others.

Next Article in the Design System Series

Ramblings of a Designer

I write about Interaction and UX Design.