Building a design system at a startup
How to build a design system at a fast-moving startup and still leverage all the benefits a design system offers.
At Deepnote, we are building a collaborative IDE-like interface for data scientists. 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 8+ hours daily working on their projects.
But how to align a growing team into crafting a consistent user experience? One way of achieving this is by setting 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 are 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 the team.
Why have a design system?
Before we jump into why have a design system, let me describe the world without it. We used to have all components spread over various Figma files, not having a single source of truth. This made it hard to search and re-use them for me, the only designer on the team. 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 3 main benefits of having a solid design system in place:
- Increased productivity across the team
- Visual and behavioral consistency of elements
- It reduces the number of decisions designers need to make
We will 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 were looking 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 from neat systems like 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 are huge fans of the fixed time, variable scope approach to shipping. I allocated 2 days to go through our designs and convert the basic elements into components. To be more specific, in those 2 days, I managed to set-up the following building blocks: type scale, buttons, inputs, dropdowns, checkboxes, toggles, radio buttons, tooltips, labels, and 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 4-point grid, which loosely means that element sizes and the spacing is in multiples of 4 (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 they also need to be in multiples of 4 in order to match the 4-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 4 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 nice exercise to revisit all the buttons or inputs you use every day without perhaps giving them a second thought and check that they adhere to the grid, type scale, and are 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 & replace everything. That could potentially take a serious amount of time.
Instead, we selected a couple of the most important elements and jumped with the frontend team into a Storybook implementation (or there already was an implementation and we simply updated it). Figma variants were really helpful, as they served us 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 uses the design system elements defined in Storybook. If not, we replaced them. Gradually we removed all hard-coded and orphaned elements which 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 will be the benefits of a design system. In our case, we saw 3 main benefits.
Increased productivity across the team
The most immediate and praised benefit of a design system. Colleagues can just directly use the same components in the code as in the Figma designs. This reduces the hand-off time significantly too, saving time for both parties. Also, if others have an idea they would like to see, I encourage them to do the design for it. Thanks to a design system, this is now much easier.
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, we found we had 7 different representations of the same button.
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 need to make. I no longer need 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 use the energy to focus 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 has across the whole team, ranging from the eagerness of engineers to create designs (who would otherwise be discouraged because they had to search for elements) up to the mentioned reduced decision fatigue.
Got any feedback? You can reach out on Twitter
We are hiring developers & designers. If you love creating beautiful interfaces, or you know anybody who would like to join us in any of these roles — send us a 👋 at work@deepnote.com
