Since Belka was founded, 8 years ago, we’ve helped some of the most successful Italian digital product companies build design systems to help them launch faster, make better decisions, and make their users happier.
We’ve gotten quite good at it, and these days we’ve even come up with a pretty comprehensive methodology. We have learned from others too, with our own Sara Fazzini and Maria Sole Biondi interviewing designers, developers and managers to uncover how leading European and North American companies approach design systems.
But this wasn’t always the case. It’s been a long process of trial and error, and we’ve had to figure out a bunch of things over the years. This post is about how we got here, and what we learned on the journey.
Maybe you can learn something from it too.
A first time for everything
The first time we got our hands on a design system was for a large company with a super successful digital product that had been around for a long time.
A lot of different people had contributed to it over the years, and it seemed like each one of them had their own conventions and way of working. Without documented rules shared by everyone, their product had become incredibly difficult to maintain. The result: slow development process, confusion about decision-making, and inconsistencies in the user interface.
At first we struggled figuring out which conventions they were following — without success, because they didn’t really have any. Since each component was written differently, the design system became a nightmare to implement.
It was like trying to play a game where everyone has their own set of rules – it just doesn't work.
We had to work with the company’s engineers to define some basic rules and common standards to follow. It didn't completely solve the issue but it was an initial step.
Looking in the mirror
Fast forward a few years. We’re getting better at this. It’s all going very well, and Belka is now handling multiple design system projects.
But guess what.
On top of everyone at our clients’ organization having their own way of doing things, we now had a similar situation at Belka. Everyone on our development team was also making up their own rules!
We were mirroring the situation of our client: many people working on something, but everyone doing it their own way. No structured work processes and nothing shared among the team.
This was no way to live.
Getting a taste of our own medicine
As we all know, the purpose of a design system is to help product teams build and maintain their digital product.
What Belka’s developers had to do was similar: to build a system to help us build and maintain design systems.
Our goal was to make the process of creating a design system as straightforward as possible. We needed to speed up the development process, improve readability and maintainability by defining shared guidelines for everyone. This would make it easier to produce and maintain high-quality code regardless of who did the work. It would also make it easier to onboard people to projects and help them understand the codebase.
Here’s how we did it.
Building the design system factory
We started by getting everyone together to standardize the various rules, techniques and guidelines shared among the Belka engineering team to produce cleaner, more readable and scalable design systems. Then we defined the architectures, code standards and conventions to be used in our design system projects.
The ultimate goal was that every Belka engineer should be able to deliver a successful design system for a web application, according to our high standards.
This activity resulted in two important outputs: a template repository and detailed documentation.
First, our template repository. We host it on Github (but it’s not open source, yet), and contains everything needed for a design system, from the initial project configuration to launch day — we can just clone it to start a new project. It includes a README file with technical specifications on how to use the software/tools in the repo too. (And coming soon: a command line interface that automates scaffolding, components creation and more).
Secondly, we have a Notion page with detailed documentation. It covers the whole process, from start to finish, including answers to questions like:
- What is the minimum set of structures we need to create a design system?
- What are the best ways to implement the foundation of a design system?
- How do we create and structure a component?
- How do we make the design system available consistently during the development?
- How can our clients check the progress in a delightful way?
- And many more…
The documentation also includes a review of our choice of software/tools with considerations and specifics on why we chose one over another.
We make these choices in a regular meeting, the “Engineering Review,” where we get together to standardize the various rules, techniques and guidelines and add them to our documentation. It’s a chance to cover everything from architecture and code standards for projects to new technologies we could integrate into our work processes.
The whole idea (and the reason we think this is so valuable) is that these documents and repository system contain the sum of the experience of the group at Belka who have been working on a bunch of different design system projects.
Keep in mind that none of this is set in stone. It’s a constant work in progress, and we can (and do) iterate on it throughout our journey. This system is also not designed to impose a way of working on the team, but to help us facilitate interaction and communication.
Tools of the trade
As every developer knows, creating a unified system for a team to follow starts with some foundational decisions. This is where you pack your bag for the journey to developing a system for building design systems. An essential step!
You’ll need to pack a lot for this journey. We deliberated on many things, including how to build scaffolding, develop a component style, and which tool to use for showcasing components.
Scaffolding
It all begins with scaffolding. It’s the skeleton of every design system: setting up and configuring the project, creating folders and files, installing the dependencies (React, Radix, Tailwind, Storybook, etc.).
We decided to divide folders according to their contents to improve the clarity and consistency of the project. We also thought of all possible files that a component could require.
Component style: Radix UI and Tailwind
Next, component style. We chose Radix UI as the headless library (an accessible and flexible library for unstyled UI components) for a few fundamental reasons:
- It offers many unstyled primitives, which are like building blocks, giving us the flexibility to create different components and customize them to match the look and feel of a particular design system.
- It’s designed with accessibility in mind, so you can be sure that your app will be accessible to users with disabilities.
- The Radix UI community is large and active, so you can get help and support if you need it.
And we chose Tailwind, a rich source of components and templates, with class-variant-authority for the style because it’s very flexible and we’re very comfortable using it. It was a no-brainer.
Radix UI and Tailwind are like the two amigos that help us build components that not only look cool but also work spectacularly.
Storybook
We chose Storybook for showcasing components. It’s an open source tool for UI components that lets developers view, test and document components in isolation from the rest of the application. It also lets us create and manage a library of reusable components, enabling us to view and interact with each component independently.
Storybook is super important to us because:
- It serves as living documentation, and the ultimate source-of-truth.
- Designers can give us feedback on the implementation before we actually ship the code.
- It makes it much easier for new developers to jump into the project when they have such a complete overview of all the available components.
With the tools sorted, the next step is setting up rules for their use, right? Well, maybe not.
Rules versus rituals
Rules are important, but early on we learned that by themselves they’re not enough. Something else might be even more important: communication and shared knowledge — let’s call them rituals — play a crucial role.
Because it’s not just about making decisions, but making them together, as a team. And for us, having regular meetings (our Engineering Review) to review and update our processes has been fundamental to creating our process.
It might sound strange, especially for engineers who think that meetings are a waste of time, but in this case, if the team didn’t regularly spend time talking about this, it would lead to slower and sloppier delivery.
The essential benefit of the process we’ve come up with isn’t that it creates a standardized way of working — it’s all about encouraging collaboration between team members, and creating Belka’s “institutional memory” based on all the experience we’ve gained from working on multiple design system projects over the years.
So, what’s the takeaway? Creating a system is a collaborative journey you should take with your team, not for your team.
∗ ∗ ∗
Want more insights?
- Why your first attempt at a design system is likely to fail
- Let’s talk about design system audits
- What’s the recipe for a successful handoff?
Want a safe pair of hands to help with your own design system?
Check Design System Audit, our service to make sure your design system brings you results.
