I love building design systems.

There is something about this challenge of building and creating something immutable. Not immutable in a “let’s never change anything” sort of way, but immutable in its ability to fail or be broken. I think that’s what design systems are ultimately trying to accomplish. They’re trying to create a system before we even begin working on a project, that enables us to quickly and effectively create consistent and interesting web experiences. My hope for this article is to help you better navigate creating a design system in 2021. Design systems aren’t a new idea and there are many more thorough resources for how to create a design system. My hope is by the end of this, you’ll have an opinionated, well-thought-out infrastructure to give you a headstart on creating your own design system.

Atomic Design

I think Atomic Design by Brad Frost is the single best resource for starting your journey on how to think about creating and building a design system. It still to this day carries many important truths about creating design systems in 2021. There are however a few chapters that address tooling and not just atomic design more holistically. After really digging into the resources that are out there, here is what I’ve found:

Context

It’s important to understand where your teams are at concerning a design system. For instance, if there is already one built out, you probably don’t need to convince everyone that you should build one. If your teams ask “why don’t we just use [insert anything but the design system you’re proposing to build]” then you probably need to focus more on buy-in and education about why it is important to develop your own. Depending on your role, you may not only have to be able to build and create components, but also change the culture around how development happens. This can be tricky, but communication and patience is your friend.

Atomic Design Methodology

Templates and Pages aren’t really helpful terminologies. Atom’s good. Molecule’s good. Organism’s good. Templates and pages… bad.

I think it is inherently difficult to continue the atomic design methodology because there isn’t a natural progression away from “individual components” into what is often called “templates” and “pages” that ultimately live in a CMS or generally speaking, don’t really fall naturally into “isolated” components. I’ve found that the work to create templates/pages in a Pattern Lab or Storybook is often mostly wasted. Depending on how you use it I guess though, it could be a place to get review/feedback. The trick is just making sure you and your team are all bought in to the same idea.

Tools of the Trade

Chapter 3 is basically an ad for Pattern Lab. I don’t really blame him though, this book is getting fairly old and I don’t believe many of these other tools existed at the time. All that to say, I wouldn’t just jump on the Pattern Lab hype train until you’ve evaluated all your options and know what other tooling options you have. I found it helpful to look at Pattern Lab as the “how” to get this done to the response “What” and “Why” that comes out of the firsts two chapters. Storybook and Bit.dev are both great options for creating component libraries. I’ve found Pattern Lab is a bit opinionated, so unless you’re on board with those opinions, I’ve found it’s just as easy to spin up a Storybook instance and use it to build your components in.

With tooling on the brain, I’d highly recommend opting for typescript (if you haven’t already) and a frontend framework (React/Vue.js). These might be obvious, but I think it is easy to just skip over these parts in favor of getting something up and running. They are super valuable in getting your storybook instance running super smooth with addon controls that work really well and automatic documentation pulling from your codebase as much as possible.

Commit to a System

Build this separate from whatever products/applications/websites are consuming it. Don’t just throw it in with the main website or any other app that might need it. Develop a deployment strategy that creates a clear line between a team that consumes the tool and the team that builds the tool. They have dramatically different end goals and having them work together when possible will always end up with better results than just letting everyone build/change things through the codebases.

What else then?

There are a lot of really great tools out there for creating modern design systems in 2021. Other than what I’ve already outlined above, these are areas I’d like to explore more to see how they fit into the design system ecosystem and the cost/benefit of adding them to the scope of a project. I haven’t been able to dig into these area’s too deeply yet, but look forward to the opportunities they bring for leveling up a design system.

Unit testing
Visual regression testing
Interaction testing
Snapshot testing

As far as more reading goes, I’d recommend:

Hopefully this gave you a nice curated starting point for design systems. I’d love to hear from you and what you’re experiences have been. Don’t hestiate to reach out on twitter @nicdford.

Nic

Latest Posts

Design Systems in 2021

Road to 29

Forcing myself to use TwentyTwenty