Building a Design System — a Case Study

In this case study, we would like to share our experience of developing a new design system at Storyblocks, on which we started working nine months ago. Within that time frame, we assembled a core team, built processes, introduced new tools for work, and laid the foundations of our design system. This project was rolled out without dedicated design or development resources assigned to the design system work. Our experience is about finding a systematic approach and enabling continuous progress in the environment of a large flow of accompanying tasks and changing priorities. In this article, we will be talking about the approach and processes we have been following so far both at the interface design level and at the technical development level.

What is a Design System?

A Design System is a systematic approach to product development complete with guidelines, processes, components, and code. It is a single source of truth for teams that simplifies the product creation, testing, and development, and ensures consistency across different pages and channels.

Adapted from Mira Teresa

Why did we need a new Design System?

Storyblocks lacked a comprehensive design system that unified our brand prior to an update. The design system at that time was fragmentary, lacked consistency, and was partially outdated. Additionally, the old documentation left much open to interpretation. As a result, our product, brand, and engineering teams lacked a shared foundation around process, design language, guidelines, and UI pattern libraries. This created inefficiencies for each team, as well as inconsistencies within our product.

Below is a visualization of all the different styling variations on our site at that time we derived by running CSS Stats, a free inventory tool that finds and analyses a site’s stylesheets.

As you can see, we had many different colors, font sizes, and spacing values. And that was only part of the problem.

By creating an updated centralized design system, we aimed to:

  • Align our teams by giving them a more structured and guided way to build products.
  • Speed up our design and development process: with a ready-made library and patterns teams can create and test layouts much faster.
  • Improve brand perception and user trust through consistent experiences that work for everyone and allow users to accomplish their goals.
  • Promote accessibility of our products by building accessibility and inclusion into our component libraries, both from a design and code repository perspective.

While it was clear that this project would require a lot of resources, planning, and time commitments, we knew that this work was a justified long-term investment in our company, brand standards, and our customers.

UI Inventory

To better understand the current state of our existing design ecosystem, we started with a UI Inventory of our main interface components. We used Brad Frost’s interface inventory guideline as inspiration to conduct a full-day audit that we ran as a team of 5 designers and 2 developers. We split into three groups and assigned each a set of components to go over on our site and build an inventory around. The plan was to screenshot unique instances of our main design assets such as typography, buttons, icons, input forms, drop downs, etc., and add them to our PowerPoint template we had prepared ahead of time. Then each group shared their findings with the team.

As a result of this exercise, we identified a lot of inconsistencies in our design assets, which only proved the need for a more systematic approach to documenting, communicating, and maintaining our design system.

Below are some examples of the components screenshots we came up with after this exercise:

1. Alert styles are all over the place and are about the furthest thing from consistent and cohesive. 2. Looking closer at select menus and drop downs reveal significant inconsistency in styling, elevation, corner radius, and more. 3. Pagination component has variations on different parts of our site. 4. Text inputs have different height, inconsistent labelling positioning and outline color in resting and focused states.

The inventory process helped us clearly see all discrepancies and inconsistencies across our site and product. It served as a foundation for our design system work. With the audit results in mind, we created a priority list for our design system minimal viable product (MVP), and started assigning designers that would lead exploration and documentation of each component.


In order to ensure the success of this project, it was important to get stakeholders on board before we start building our design system.

We systematically promoted the initiative via:

  • A kick-off company-wide presentation where we shared the current pain points and the anticipated benefits of the project for the company as a whole.
  • Involving engineering into the conversation early on through bi-weekly design system meetings and workshops to collect their input.
  • Sharing with squads work in progress and the roadmap of the project.

By getting other teams involved from the onset and as the project evolved, we strived to promote understanding of the project and inspire a sense of co-ownership throughout the entire process.

Design Exploration

We decided to focus first on the foundational elements (atoms) of our design system, such as color palettes, fonts, grid, spacing, buttons, etc., and then move on to more complex blocks and pieces (molecules, organisms, templates, pages). We created components from scratch since we switched from Sketch to Figma as it served our design needs better.

Some of the activities at this stage involved:

  • Researching other design systems and interfaces for components common practices and inspiration.
  • Analyzing the instances and use cases captured during the audit and ideating on the solutions that serve our goals best.
  • Unifying: we merged different variations of components to leave only the essentials. For example, we limited our color schemes to a maximum of 9 shades for each hue and all the excessive variations were matched and merged with the decided upon schemes based on proximity. Below is our final color palette:

Some principles we followed:

  • We tried to make our components responsive with the auto-layout Figma feature, so we could reuse those components when designing for different devices or layouts.
  • We designed to cover all scenarios, or “states” in the system: hover, focus, filled out, error, and disabled state.

When the Variants feature was introduced to Figma, we started using it to combine variants into component sets with custom properties and values. Using variants makes components easier to maintain, browse and swap through the sidebar menu.

  • Each component we designed with accessibility in mind. We strived to comply with WCAG AA accessibility standards. Below is an example of intentional choice of color on a warning alert to achieve sufficient text contrast (checked via Stark Figma plugin) so that users with low vision can see and use our component.


Reviewing work is an important part of any design process to ensure we arrive at decisions collectively and align on details such as component design, documentation, and tools. For this project, we formed a multidisciplinary design system team that would meet every two weeks to discuss the direction and progress of work. We also set up a design-systems Slack channel, where we post the design system updates and requests for asynchronous feedback. These practices allow us to collect everyone’s perspective and bridge the gap between design and engineering.


High-quality component documentation is crucial to an effective library allowing everyone to quickly and efficiently make consistent decisions. We wanted to create detailed documentation that would support every single aspect of our design system, and also be organized, consistent, and easy to use. We referred to several design systems such as IBM’s Carbon, Material, Atlassian, Salesforce Lightning, and other design systems for some good practices, guidelines and tools that we could apply in our design system.

Google’s Material Design System

We set out to produce design-led and development-led documentation that is integrated and synced to create one consolidated system.

Design-led Documentation

Figma Component Library

Once the Figma components are approved, we move them to a Figma Atomic Components file, a shared library of assets that our team can use to drag and drop while working on their designs.

Zeroheight Documentation Site

We use Zeroheight, a collaboration platform that integrates with Figma and allows product teams to create and maintain web-based design system documentation. If Figma atomic library is a library of design components, Zeroheight is a collection of guidelines and rules for those components. At a high level, most of our component documentation in Zeroheight usually includes:

  • Introduction with component description
  • Component construction
  • Component states
  • Behavior
  • Best practices
  • Accessibility guidelines
  • Examples of components in different contexts to demonstrate how design patterns would be applied in real products and specific use cases

Storybook Components Repository

Our old repository was dated and only addressed our design system in places where we use React, which is not everywhere on the Storyblocks. We decided to build out our new repository from scratch in Storybook, a tool that allows to create an interactive pattern library for code in isolation and supports all the popular frontend frameworks. It allows to document use cases as stories and easily find, share and reuse them. Just like Figma, it also integrates with Zeroheight, making it easy to sync and align documentation between development and design. We called our new repository “Storywind”. Our plan is to eventually migrate all components from the old library into one consolidated repository.

Tailwind CSS

We decided to use Tailwind as our base CSS framework, main reasons being:

  • It’s utility focused, which encourages the creation of modular/reusable styles
  • It’s framework-agnostic, which means Tailwind utilities are supported well both in PHP (our main monolith codebase) as well as React (supplemental parts of our front-end codebase).
  • It’s highly configurable, allowing us to customize styles for our brand.
  • It encourages interoperability between design & engineering.

We built Tailwind configuration based on our design system fundamental variables and use it to more easily enforce design system constraints within both of our main technology stacks.

Tracking Progress

In order to track and communicate the progress of the different steps, we created a Jira board that can be viewed and updated both by design and development. We create tickets for specific components that link out to all the relevant documentation and move them to corresponding status columns (In Design, Needs Feedback, In Development, etc.) throughout the process.

Naming Conventions

To ensure everyone is on the same page and speaking the same language, we aligned on consistent, clear naming conventions between design and code, be it font styles, colors, spacing, icons, etc.

The table below specifies font sizes and line spacing in text styles. For convenience, each style is named the same as in the code.


Since we did not have dedicated resources to work specifically on the design system, we sought opportunities to work with squads to incorporate building the design system components into the existing efforts. For example, during the Storyblocks Home Page update, such fundamentals as a grid, typography, spacing, buttons were built out and documented. We plan to continue with this approach with the upcoming initiatives. Of course, we need to account for the extra time teams need to document the components in addition to the main scope of work.

The Future

The design system is an ongoing project. We iterate, change and learn a lot in the process. So far, we have a set of basic components ready, which has been game-changing for our team in terms of efficiency, as well as consistency, and standardization.

Some of our team’s next steps include:

  • Continuing to grow our component library and supplement it with more complex components.
  • Adding sections on brand, illustrations and animation.
  • Cultivating processes and best practices for maintaining the documentation to ensure that our library stays up to date and perfectly in sync both on the design and code side.
  • Raising awareness across the teams and promote adoption and contribution to the documentation.
  • Building processes for testing the components on compliance with guidelines and accessibility standards.

Written by

Tamara Runtsova