Design System Diary — Part II: Starting With the Basics

The beauty of atomic design (and why we don’t just use it as is)

I’ll likely never forget the first official meeting we had as the newly formed design system team. It was four of us, two designers and two developers (including me). The goal of the meeting was to define the different parts of the design system and give them names that both designers and developers would understand.

Early sketches trying to figure out what the design system consists of and how to organise these different pieces of information

The “how”

In the first part of this series, we explored some of the reasons “why” you’d want to build a design system. Identifying these motivations is key to your success. If you have no clear objective, you’re unlikely to get clear or good outcomes.

Atoms, Molecules and Organisms

So how did we approach our design system? A lot of it was inspired by Brad Frosts “Atomic Design”, a book I think everyone thinking about building or even just having to deal with design systems should read at least once (or at least watch his talk 😉). Not because it represents the ultimate truth (I don’t think such a silver bullet exists in our industry for pretty much anything, let alone such a complex matter as design systems), but because he does a great job in explaining the motivation behind his approach and the different layers of abstraction. The principles he describes are also nothing new, just put into a context easy for everyone to understand. — visualisation of the five distinct levels in atomic design

1. Atoms

The lowest level of abstraction. “Atoms” are the smallest building blocks. You cannot break them up further. These kinds of components are your fundamental building blocks. They need to be very flexible.

2. Molecules

Combine multiple “atoms”, and they will form “molecules”. Ideally, this group of components is built for a specific job and is doing that job well.

3. Organisms

This level describes a group of “molecules” that together build a bigger structure, you could call it a feature if you like. “Organisms” could still be reusable within the same application, but their primary purpose is to combine reusable components to provide the big structures of functionality in your applications.

4. + 5. Templates and pages

This is where we most definitely hit the application or rather brand specific level of abstraction. As the name suggests, “templates” are your boilerplates for different kinds of contents, ranging from individual sections to whole web pages. “Pages” are essential templates with actual content fed into them.

How we structure our design system

This split into different levels of abstraction makes a lot of sense. And as I said before, the core idea is nothing new. Earlier concepts have tried to describe the same thing, take e.g. BEM (the popular CSS class naming convention). Its whole idea revolves around the same thing, defining element groups and even bigger groups formed of element groups to target particular “component” styles. And the goal is also the same: break your UI up into small, reusable chunks.

A missing piece

Another big reason for our decision against just using the “atomic design” terminology is that it is missing something that we want to emphasise more — variants.

The initial model for our design system structure

Lessons learned

Lesson #4 — Using the same language is way more important then it might seem in the beginning

Dealing with two disciplines that have wildly different perspectives and objectives to start with, to align them, you need to speak the same language. You can’t define aligned objectives (which you definitely want to do to make sure you’re pulling on the same strings) if you don’t share terminology.

Lesson #5 — The lines between different abstraction levels can be blurry

Especially when it comes to “patterns” vs. “variants of core components” — is a “primary button” a “molecule” or an “atom”? This is important to define for you as a team, though. As I tried to point out earlier, all levels serve a different purpose, so the team not being on the same page about what these levels are and why they are important is just asking for disaster.

Lesson #6 — Start small

As tempting as it is to build everything at once, start small. If you don’t get the core right, the issues will get exponentially bigger at scale when you start building patterns and whole features.

Lesson #7 — Don’t forget who you are building for

Yes, you’re trying to create a generic solution, but in the end, the DS needs to be usable for all your product developers and designers.

  • Part IV: Communication is Key
  • Part V: Documentation, Documentation, Documentation
  • Part VI: Design Tokens
  • Part VII: Creeping Product Deadlines and How To Measure Success
  • Part VIII: Automation
  • Part IX: The First “Reference Customer”
  • Part X: Share Knowledge

Frontend developer @rexlabs —

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store