Sign inGet started
← Back to all posts

Building a design system at a startup

By Filip Stollar

Updated on February 25, 2021

Learn how to build a design system at a fast-moving startup and leverage all the benefits it offers.

Illustrative image for blog post

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:

  1. ⁠Increased productivity across the team
  2. Visual and behavioral consistency of elements
  3. 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 look at our inputs and dropdowns from the new design system

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.

Filip Stollar

Head of Design @ Deepnote

Follow Filip on Twitter and LinkedIn


Illustrative image for blog post

Beyond AI chatbots: how we tripled engagement with Deepnote AI

By Gabor Szalai

Updated on April 3, 2024

That’s it, time to try Deepnote

Get started – it’s free
Book a demo



  • Integrations
  • Pricing
  • Documentation
  • Changelog
  • Security




  • Privacy
  • Terms

© Deepnote