At Deepnote, we are building a collaborative IDE-like interface for data teams. From the design perspective, that means fighting for every pixel while giving the users a consistent, clear experience in an environment where they easily spend eight-plus hours a day working on their projects.
But how do you align a growing team on crafting a consistent user experience? One way to achieve this is to set up a design system. There are great articles that go in depth on what design systems exactly are. Loosely described, a design system is a constantly evolving collection of reusable components and resources that the team uses to design and develop.
If you're a founding designer, an early engineer, or a founder who is thinking about setting up a design system, this article will explain how we did it at Deepnote. It doesn’t need to be a major undertaking, yet it can noticeably speed up your team.
Why have a design system?
To understand why you should create a design system, let me describe the world without one.
We used to have all our components spread over various Figma files without a single source of truth. This made it hard for me — the only designer on the team — to find and re-use them. For others, it was downright impossible. As the team grew, it was also harder to keep the components in code synced with the designs.
Once completed, we observed three main benefits of having a solid design system in place:
- Increased productivity across the team
- Visual and behavioral consistency of elements
- Fewer decisions for designers to make
I'll briefly touch on all the benefits later in this post. First, let’s take a look at how we approached the initial implementation.
The design system at Deepnote
Creating a design system can easily take weeks or months, depending on how extensive you make the system. Deepnote is a fast-moving startup, so allocating a couple of team members on a several-month project is not something we wanted to do.
In our case, a design system means a simple collection of very basic elements and building blocks. Think type, colors, buttons, inputs, and dropdowns. It has a long way to go to compare to systems such as Figma’s UI2 or the Visual Studio Code Toolkit, but it’s a start that has already had a large impact on the team.
We're huge fans of the fixed time, variable scope approach to shipping. I allocated two days to go through our designs and convert the basic elements into components. To be more specific, in those two days, I managed to set up the following building blocks:
- Type scale
- Buttons
- Inputs
- Dropdowns
- Checkboxes
- Toggles
- Radio buttons
- Tooltips
- Labels
- Dropdown menu items
These pre-created components alone make the designers and the frontend team as effective as if you were to hire a new team member (a pretty great deal if you consider the time investment).
A 4-point grid and a type scale
An important part of every design system is its type scale and grid.
From the very beginning of Deepnote, we were using an implicit four-point grid, which loosely means that element sizes and spacing are in multiples of four (4px, 8px, 12px — you get the idea). However, the grid was never really formalized or enforced. So if another team member added some designs, it was unlikely they would follow the grid. We had to revisit our older designs and fix small visual inconsistencies to make them work with the newly formalized grid.
Hand in hand with the grid was the type scale. I checked the font sizes we used in the interface and I could easily find all sizes between 11px up to 16px. Don’t get me started on the font weights and line heights. The line height is what defines the height of the text box, which means it also needs to be in multiples of 4 in order to match the four-point grid. To fix this, I took inspiration from Figma’s UI2 type scale and defined a couple of font sizes along with their heights. The heights are all multiples of four and are calculated with the formula shown in the screenshot below.
Buttons, inputs, and other elements
Once your grid and type scale are defined, creating individual elements becomes surprisingly quick. We already had our elements created, they were just scattered across many Figma files. This was a great exercise, as we revisited all the buttons and inputs we use every day without giving them a second thought and checked that they adhered to the grid and type scale and were consistent with the rest of the design system.
The translation to code
Our aim was to never do a big, single sweep where we code and replace everything. That could take a serious amount of time.
Instead, we selected a couple of the most important elements and jumped into a Storybook implementation with the frontend team (there already was an implementation — we simply updated it). Figma variants were really helpful, as they served as a guide to the React props the components should have.
If we were touching an old React component as a part of a PR, we simply checked if the component used the design system elements defined in Storybook. If not, we replaced them. Gradually we removed all hard-coded and orphaned elements that did not adhere to the design system. All new React components leverage the Storybook implementations of the design system by default.
The benefits of a design system
The larger your company is, the greater the benefits of a design system. In our case, we saw three main benefits.
1. Increased productivity across the team
Increased productivity is the most immediate and praised benefit of a design system. Colleagues can just use the same components in the code as in the Figma designs. This reduces the hand-off time significantly, saving time for both parties. Also, if others have an idea they would like to explore, I encourage them to do the design for it. Thanks to a design system, this is now much easier.
2. Visual and behavioral consistency of elements
This one speaks for itself. As mentioned before, we are gradually replacing all elements with their component counterparts. It was also a nice reality check, as we found we had seven different representations of the same button.
3. Reducing the number of decisions for designers
The most striking difference of having a design system was that it reduced the number of decisions I needed to make. I no longer have to search for the right files and elements, deciding if they fit into the new design. I simply drag and drop them into the design knowing that they form a unified experience for the user. I can focus my energy on the actual design problem at hand. This reminded me of a story about why Mark Zuckerberg wears the same shirt every day.
Wrapping up
A design system is never done and these were just the very first baby steps. It’s already amazing to see the amount of impact it's had across the whole team, ranging from the eagerness of engineers to create designs (previously they were discouraged because they had to search for elements) to a significant decrease in decision fatigue.