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.
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.
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:
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.
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:
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:
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.
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:
Some principles we followed:
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.
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.
We set out to produce design-led and development-led documentation that is integrated and synced to create one consolidated system.
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.
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:
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.
We decided to use Tailwind as our base CSS framework, main reasons being:
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.
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.
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 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:
Written by
Tamara Runtsova