How to build a Design System in a scale-up (and survive it)
A brand new design system to keep the fast-growing DaVinci Salute on track.
While the internet is plenty of to-do-list articles and videos on design systems, there’s a noticeable absence of real-life case studies. I’ve often wondered about questions like “Why should companies invest in design systems and how do product teams manage these kind of projects?”.
While there’s no one-size-fits-all solution, and every business must find its unique way, I want to share how we dealt with this challenge at DaVinci Salute. This way, as you’re reading, you can gain a more practical understanding of what it truly means to “build a design system.” Think of it as a way of giving back to the community!
Why did we need a Design System?
After finding our product-market fit, we entered a phase of intense growth. This should have enabled us to accelerate the development speed of new features. However, when you’re in a rush, there is no time for consistency, writing documentation, and proper handoff. We began to notice that the pace of design and development was slowing down, leading to a decline in the user experience.
In response to these challenges and driven by the commitment to meeting Unipol’s ambitious plans within established timelines, our goal became speeding up the efficiency of our design and development processes.
That’s the thing we needed to build a design system: opportunity.
A design system is a set of rules that establish a shared language within a company, facilitating collaboration between designers and developers. It enables a rapid and efficient scaling of products by providing clear guidelines and pre-built components. Incorporating new features becomes easier, while maintaining visual consistency and enhancing the user experience.
Start small, build as you go
Given the team’s overall limited experience with design systems, we opted to take a measured approach to the project. To begin, we had to chose for one main designer who would be the owner of the project, and I volunteered for this challenge due to my pre-existing engagement with the topic.
As a result of this choice we contacted Belka, an agency that specializes in exactly that sort of thing, and collaborated to craft a solid foundation and design some components. Their experience would have helped us speed up the process without necessitating the full involvement of the entire team.
After completing this initial phase, we would then gradually develop new components, evaluating the team’s priorities and ongoing tasks on a case-by-case basis.
Time to sit on a table
We sifted through our product to get a better understanding of the state of the UI across the entire digital experience. This gave us an idea of how large in scale the project was going to be and where were the areas for improvement in our design. Yes, we run a design audit and yes, we took a lot of screenshots…and I mean LOTS of them. By creating a visual map and conducting heuristic evaluations, we collected all the components and patterns to evaluate their reusability and flexibility across different contexts. To ensure easy access to all relevant materials, we centralized everything in Figma. With the audit results in mind, we created a priority list for our design system minimal viable product (MVP).
When it was all done, the vision became clear, and we could begin to plan out a journey path to create our new design system.
One brick at a time
A design system can be compared to a super organized toolbox that contains stuff and materials you need to build a house. Just like a toolbox helps builders work fast and keep things consistent, a design system helps designers and developers create great products.
And you know what’s really important to prevent the house from collapsing? Yup, a solid foundation.
The foundation of a design system is a set of bricks that represent rules like typography, palette, icons, layout and tokens. With bricks (foundation) and tools (component libraries and communication), you can build a sturdy and long-lasting house (the product).
We designed our bricks straightforward by collaborating with Belka and the internal product team. As it always goes in a project like this, communication and collaboration are key!
Additionally, we switched to a new font family (from Quicksand to Plus Jakarta Sans) to enhance the perception of reliability of our products.
Design tokens, what?
While I was familiar with common rules like typography, the concept of token was something new to me. I had to dive deeper to fully grasp its importance and impact on our design system.
In short, design tokens are the backbone of a design system. Instead of using hard codes like color hex codes or pixel sizes, we give them names. These names (or “tokens”) store design details in a simple, easy-to-read way. In our case, tokens will be used in all Figma files to maintain consistency across our products.
We relied on Tailwind for the “basic” tokens such as sizing, spacing, and elevation. This well-known framework was already being used by our development team and It was perfect for our needs. Lastly, we created a new set of tokens to define the scope of colors used within components.
A brand new components library
A significant focus has been placed on the evolution of our components library. Starting with a deep dive into what we already had in Figma and the insights gathered during the audit, we re-designed our components to align with the principles and guidelines set forth by our design system. On top of that, we introduced a naming convention for variants and properties, amping up our game with the game-changing Figma variables feature (a lifesaver!)
However, our commitment to quality goes beyond just the design board; regular team updates were at the core of our process. These sessions weren’t just about ticking boxes but a collaborative space to validate our work, soaking in valuable insights and feedback. By weaving in perspectives from all corners of the team, we made sure our new components weren’t just design-system-compliant but also hit the right notes for everyone on the team. It’s this whole give-and-take vibe that’s not just boosting the muscle of our component library but also infusing the design squad with a spirit of collaboration and always getting better!
Conclusion
Even if a design system is an ongoing project, we’ve learned so much from our experience so far, and along the way we’ve found lots of things we want to improve to make things even better.
The decision to adopt a product design approach and draw insights from the research of other design systems has been key in achieving our desired outcomes, what we have now is a new foundation with tokens and a set of developed components which are being implemented while I’m writing this article.
Our build times are already seeing a boost, the increased speed and efficiency in iterating on the new design system promise to elevate the daily workflows of our colleagues (which was my personal goal for this project).
What’s next? Well, I can’t predict what the future holds for us, but these are the goals we intend to pursue:
- Continuing to grow our component library and supplement it with more complex components.
- Cultivating processes and best practices for maintaining the documentation to ensure that our library stays up to date and perfectly in sync both on the design and code side.
- Raising awareness across the teams and promote adoption and contribution to the documentation.
Thanks for reading! I’m going to write other articles about design systems so stay tuned and feel free to add a comment below 🙂
