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 there’s a lot of buzz around design systems. To understand where design systems come from, let’s take a brief glance back in history: First there were corporate designs which are rule-sets mostly focused on print. Then JavaScript came along and made building rich internet applications much faster and cheaper. To keep up with the speed, designers started to create pre-made symbols that could be copy-and-pasted to quickly create screens and called it a pattern library.

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.

When building a design system, there are two distinct approaches. A very fast paced, organic way where we build exactly what is needed for one product only. Or a very structured one that serves a wider range of products.

Both approaches (and every shade in between) are valid. Which one we choose depends on our needs. The more products we need to serve, the more robust our design system should be. If only a handful of people will be using it, we’re fine to take a much faster approach. In this article I’ll cover the “cargo train” approach. If we decide to go the “express train” route we can shorten or skip many steps shown here.

Did you know, the carbon design system from IBM has 12 people on their core team in various roles, and many (many) more that contribute components to the actual code implementations? You’ve probably seen those beautifully crafted showcases online and aspire to build something similar. Just remember they’ve evolved over time and have a whole team dedicated to the development. If we’re just starting out, it’s better to start small. Once our design system is up and running and our core team is stable, we can still on-board more people and scale things up. In the beginning, the core team doesn’t have to be full-time, as long as every member has a scheduled amount of time they can dedicate regularly.

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.

Enough of the prelude, let’s put butter by the fishes, as the Germans say. To build a successful design system, we’ll need all five of the pillars shown below.

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.

Once we’ve gained those basic insights we run a quick technical analysis of the current component landscape. During all this research we want to do just enough research for us to be able to understand the problem and propose a solution. We’ll spend some more time on in-depth research once we’ve secured funding.

For our pitch we’ll need to prepare our value proposition, the scope of our design system and what resources we need to reach our goals. Speaking of resources, there are several ways to fund a design system. Ideally we get a dedicated budget and team that allows us to keep working constantly. Especially in the beginning of a design system that’s not often the case. In those circumstances there are other ways that we can try out: (internally) open source our design system, product team participation or licensing models to name a few.

Once we’ve got a robust plan, it’s time to pitch it to our stakeholders. In doing this, it’s important we understand where they come from and what pain we can solve with our design system. While a developer might be concerned with loosing flexibility and over-complicating maintenance, a designer could suspect that they will loose flexibility. It’s important to be honest here and set the expectations right. A design system offers some distinct advantages, while restricting other parts of the current process. As with any pitch the better we understand their reservations and address them, the more like we’ll get what we’re asking for. Speaking of us and them, the more we can create a sense of shared ownership the easier adoption will get once our design system is released.

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.

After setting up a team process (Jira, Scrum, etc…) we can take a deeper look at what we need to build. Depending on the effort we spent in the previous phase, we want to spend some more with our product teams. Once we thoroughly understand their process and needs we’re able to decide on what we’ll provide. (Hint: it might not be a design system at all)
If we can’t rely on previous UX research, usability tests and a component inventory are our preferred methods to find out more about our user’s side.

Every design system needs to know the reason it exists. (Can a design system have an existential crisis then? I think so.) We want to create a shared vision around it that is carried by most of the product teams. We’ll also want to define a realistic scope of deliverables (design library, ready-to-use components, change log, road map, …) and give it a name at some point. Every monster needs a name, even cute ones.

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.

Before we design the components, we want to define our UX patterns. I’ve got a whole Checklist to work through to see what questions our patterns should cover.

The last step before designing our first component is to define our tokens (colors, fonts, white space, animations). These tokens are the foundation styling that we’ll be applying to our components. Additionally, we should include the tokens as scss file in the final package for our product teams to reference in their styling. We don’t need to have all tokens ready from the get-go, but it helps to define the most important ones.

Finally we’re able to design our first component. We can build this directly in HTML / CSS or draw it up in a design tool. Personally I like to start with a simple component like a button and define all the needed variants (primary, secondary, ghost) and states (default, hover, active, disabled). This allows us to familiarize with the whole design system first. Next up, I’ll take the most nested/complex component, which often happens to be a card. By doing so, I can stress-test our concept and make sure it’s robust and flexible.

There are only two hard things in Computer Science: cache invalidation and naming things. — Phil Karlton

When designing components, one of the most important things is to keep the naming of components, variants and states consistent from the symbols to the final code. Once every discipline uses the same names, conversations get much easier.

One perk of most design systems is that we sacrifice perfect UX flows for standardization and a faster implementation time. As UX designers we inflict those limitations on our selves. Gone are the days of pixel perfected micro interactions to gain the last fraction of our key metric. There must be a very valid business case to not use one of our existing components or add another feature to it. To keep our credibility with the product teams it’s important to be especially critical towards feature requests from our own UX designers. If we dismiss our design system rules at the first hick-up, why should anyone else compromise? The upside of this is that, by being strict with ourselves, it frees our designers up to assess underlying procedural UX problems. Once usability tests surface an actual problem we’re still free to deep dive and create custom components to fix this particular use case.

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.

When building a design system for more than a single product, quality isn’t an option, it’s the only choice we have. We want our product teams to trust us enough to use our design system as an integral part of their daily work. If they choose to do so they rely heavily on our system to function properly. If we mess up the wrong component and break their product, we can possibly get them in big trouble. Because of this we always want to rigorously test before every release. This ties back in with the mantra of building less components and limiting their features. It’s also not wrong to have an automated build and testing pipeline.

At this point in time it’s probably a good idea to work on the public documentation. Currently most documentation frameworks require three parts:

1. The actual code
2. Interactive demos for our components (storybook)
3. A documentation system to add our explanations
   and embed the interactive demos (zeroheight)

Our documentation should at least consist of the tokens, components, vision, patterns, a change log and a contact page.

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.

Something to keep in mind when updating any component is that most aspects are a public API. Not only the obvious parts like parameters that are passed in the code, but also the visual appearance. Product teams spend a lot of time perfecting their UIs within the available screen estate. Increasing the padding of a Button by one pixel can break a finely tuned form and render an app unusable. Making a buttons background darker can lead to illegible call to actions.

We should also accept that our design system won’t fit every application and that it will be used in creative ways that we’ve not intended. By supporting a certain degree of freedom and unorthodox uses we’ll foster a creative environment and encourage our product teams to search for innovative solutions. Once we spot an implementation that we feel doesn’t fit with our UX principles we can still approach the team in an open-minded, collaborative way. It’s a chance for us to learn more about their needs and to educate them on why our principles exist. This will enable the product team to apply them independently and build even better products in the future — in turn freeing us up to design instead of govern.

The more products use our design system, the more components will need to be adjusted to very specific use cases. A business application can have vastly different requirements regarding a table than a simple B2C app. To address this, it’s possible to create plugins for our 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.

Enjoyed it so far? I’m thinking of writing a series where we’ll look at all five pillars in-depth and learn more about the steps it takes to build our own design system.Writing an article like this is a lot of work, let me know below or on Twitter (@tim_schoch) if you’ve enjoyed it and would like to learn more on this topic. And if you don’t want to miss any of the next articles click the follow button. 👇

One last thing
If you’d rather meet me in person and have a chat about design system, I’ll be giving talks on this topic in Melbourne, Manchester and Berlin:

Next Article in the Design System Series

Part III → Design System Resources and Links