Building Design Systems

Design systems are quite a controversial topic for product designers and front-end developers. Every growing company that intends to scale would need to invest in a design system, as it is one of the biggest tools in the entire DesignOps tool kit.

Truth is, even if you aren’t a big team with a design team or if you've got a digital product, you have created a design system — indirectly or unknowingly maybe. In this article, I’d be walking you through how to build a Design System from the ground up.

I’ve made it a thing to write more design-related articles from my experience as a Product Designer.

Let’s jump in.

What’s a Design System

A Design system simply put, is a living and breathing product library of experiences design, and development resources. It’s a collection of well-thought-out efficient resources for crafting interfaces.

The primary benefit of a Design system is the ability to replicate designs quickly by utilizing premade UI components and elements without the need to reinvent the wheel while keeping new interfaces consistent with the intended overall look and/or feel.

The design system consists of various building blocks (like color schemes, grid definition, Icons, image assets, etc.), UI patterns (like templates, components, elements, etc.), and rules (Do’s and Dont’s, Guides, design principles, etc.)

As Nathan Curtis says, a “design system isn’t a project, it’s a product serving products”. Do also note that a digital product design system is kinda incomplete without a code implementation.

First (Last) Step — Naming your Design System

Truth is, as a designer, you understand the pain in naming. Be it layers, groups, or countless revisions of a file exported.

Designer’s naming dilemma. 😂

Your design systems need to have a name and you might as well come up with it early enough.

1. Define and Create Tokens

I’d just quote myself here “Design Tokens are tangible properties shared throughout an interface, composition, or graphic elements which are typically not useful alone.”

I previously wrote about Atomic Design, I talked about the Atomic Design Taxonomy, where we have Design Tokens as the first layer of the Russian doll analogy.

Moving on, this step would require you to create the basic variables for your entire system which you can easily update in the future if need be. Here you define Font name, size, weights, Colors, Opacity, spacing icon set, spacing, etc. If it’s specific, or fixed, or has a value tokenized it.

Designers can check out this plugin I found in Figma, after doing it manually, countless times 😣.

  1. StyleList: To create Typography scales and Color shades.
  2. Typography Styleguide: To show the various type scale styles.
  3. Color Styleguide: To show the various color styles.
  4. Figma Tokens: For inspecting, generating, and syncing Tokens in JSON.
StyleList, Typography Styleguide, Color Styleguide, Figma Tokens

It’s also good to note that this is the point where you factor in or enforce a11y in your Design System. So ensure to test against established color contrast guidelines. This practice improves the overall elements built with the design tokens.

You might not have all the tokens figured out at first, but the idea is to start small and improve as time goes on.

2. Build & Test Components

Components are the user interface elements that make up the digital product. They include Breadcrumbs, Input fields, Breadcrumbs, Tree selection, Tables, Pagination, etc.

The idea is to build, test with various use cases and update build.

Here's an example, let's create an Input field Component.

Input field

First, I’ve divided the elements that make up an input field into 3 parts. These parts have various variants and use cases.

A. Field Label

The label would have the main text and a combination of any of Note, Help icon, and Required (*). I’ve created this on Figma and made it a component with the respective varients combination.

Label variant

B. Text Field

The field can be a simple input field or a text area. Input fields could have a prefix or suffix icon or a combination of both and the Text area could have a scroll and drag-to-expand feature. These variations have to be accounted for in the design of the Field (if required.) The states also need to be considered.

Field variant
Figma component control

C. Message

The message helps inform the user concerning the input field currently being interacted with. This information can be of various types, could have an icon, or could be always visible. Cases like this might be worth considering.

Message variant and Figma control

You might need to meet review each component with the development team for more insights and considerations.


With this, we have successfully built the Input field while considering over 90% of use cases.

3. Document

Ever heard that “Documentation is a love letter you write to your future self.”

You want to document as you build and test each component. Designers could document right in their Figma file or in another Documentation that is accessible and convenient for the purpose.

As designers, component states, variants, and use cases. You can go the extra mile to document the How-tos that might be helpful for anyone on the team.

Documentation and Testing for Developers

Developers can document the UI components developed using any tool that gets the job done. I’d suggest Storybook for a number of reasons. Ohh, and you could embed published Figma files on Storybook, how cool!

Design and code represent the same thing and therefore must be connected. It doesn’t mean though that they require the same person to take responsibility for both, just as the songwriter and the singer can be two different people creating one masterpiece — Marcin Treder

What Storybook looks like.

Storybook can serve as a single source of truth for everyone on the team.

And here’s another documentation quote 😂— Documentation is like sex: When it’s Good, it’s very, very good; when it’s bad, it’s better than nothing”

4. Update & Repeat

Do I need to explain this?

Keep building, testing, documenting, and updating components.

The truth is the Design System is always never finished, so (keep updating) go on.

In conclusion

So far, following the sample steps above while keeping the Atomic Design principle at the back of your mind, you’d be able to develop a working Design System.

The entire team would be able to achieve a Component Driven Development system AKA Micro-Front end.

Thanks for reading this far, don’t forget to share and clap this article if you find it useful.





Product Designer. Engineer by certification. Creative by heart.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Collective Curation: New Lenses for Experiencing Smart Cities

5 Figma Plugins To Save Your Time!

Reflection — Third Week — Experiment & Market Exploration

How can you test business viability quickly?

How do you build an exhibition, during a pandemic?

Image of a robot

Are Chief Design Officers the key to better cities?

7 Ways to Make Your Website ADA Friendly (and Still Look Good)

The Beginner’s Guide to Microcopy

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
Gideon Alawode

Gideon Alawode

Product Designer. Engineer by certification. Creative by heart.

More from Medium

Design System boosts efficiency up to 7* times

Creating complex interactions with interactive components — Dropdown

Bratto Design System Case Study

Source: SuperFriendly

Creating Components For Mature Design Systems

Abstract illustration of a man and a women jumping and high-fiving each other