Design System, a Spendesk success story
Today, I’ve decided to embark on a new exciting project. But first, I want to take a moment to reflect on my journey at Spendesk over the past 4.5 years.
This post is primarily a review on the work I’ve done at Spendesk. It will naturally focus on the Design System, as it has been by far the most impactful project I’ve worked on, both in terms of its value and duration.
Build trust
The Design System of Spendesk, Grapes, was created in 2020. I took ownership in early 2021 with my partner in crime, Pauline, another developer with whom I worked for the next 4 years on this amazing project.
At that time, the Design System was just a side project, in several senses of the term.
- Firstly, it was deployed only in a small portion of the product.
- Secondly, there was no team dedicated to it. Instead, developers and designers worked on it in their spare time with Pauline and me acting as quality guards (i.e. tech owner)
In order to support the growth of this project, I initiated several projects and processes in the first few months:
- The process of release changed from a manual action to an entirely automated system using
semantic-release. - Visual testing was implemented to prevent any visual regressions from being released. I wrote an article on this topic here: Build trust in your design system with Visual Regression Testing
The goal of these initial efforts was to build trust amoung consummers. The idea was simple:
If a tool is available, bug-free, and can help build a feature quickly, why not use it?
And it worked.
After this period of transformation, the design system truly grew within the product, and developers became hooked to its usage.
Track your design system
In parallel with building the first block to support the growth and trust in Grapes, the need for a system to track how and how much the design system was used began to emerge.
As months passed, the spare time to work on the Design System felt more and more insufficient. I didn’t have time to complete my task and support and bug took more and more time. I didn’t have any data to support my concern so I started to write a script to follow the usage of the design system in the product.
That first step evolved into a full-fledged project to track usage and drive decisions around the design system.
If you want to know more about this topic, I wrote an article on this here: Track the usage of a Design System.
Share your achievement
Newsletter
To keep developers and designers engaged, we had a lot of initiatives.
For instance, we published a monthly newsletter highlighting changes in the Design System.
This newsletter included upcoming features, ongoing work, among other little sections such as one called The perks of being a UI frontend engineer where I balanced between complaining about the state of the web or celebrating a new releases.
A preview of the October 2023 newsletter where I celebrate the release of a fix in the latest version of Safari.
This newsletter provided an opportunity to communicate more broadly about our progress. Not everyone in the company used the design system, and unlike a product team, our changelogs were not included in the product release notes.
So to demonstrate the value of this project and how it supports the Spendesk product, we, like a marketing team, promoted and communicated about our work.
A preview of the February 2024 newsletter
We also took the time, in this newsletter, to acknowledge anyone who helped us during the last month, whether it was through a pull request, a bug report, or a support question. To me, it’s absolutely essential to celebrate the people who help you and contribute.
Presentation
Additionally, we gave many presentations, both internally and externally, to share our achievements, with always this playful tone that everyone knows me for.
Internal presentations were mostly made during events called ‘All Hands,’ where people from Product, Design, and Engineering gathered for about an hour.
A slide from an internal presentation at Spendesk. Grapesification was the name of the project aiming to achieve 100% coverage by the design system in the product.
And given the subject, we naturally did a presentation at Design System France to celebrate and showcase the rebranding we completed at Spendesk.
Myself at Design System France presentating how did we did the rebranding.
Spread knowledge
One of our aspirations was to welcome developers, whether frontend or backend, within the design system team for a period, and to mentor them. Although this wish couldn’t happen at Spendesk, we did our best to share our knowledge.
The design system served as a testing ground for most new frontend technologies before they were implemented in the product. It also dictated the minimum browser support for the product. So I believed it was crucial for everyone to understand the ‘magic’ and the libraries behind this project.
Presentation
I led many internal technical presentations on CSS features, visual testing, frameworks and libraries. I’m quite sure I gave the most technical presentations at Spendesk ever, but it’s obviously enfair given my 4.5 years in the company.
Most of these presentations focused on how Grapes is built, how it works, and the APIs or concepts we use. For example, I gave talks on visual testing and Chromatic, handling z-index, and managing CSS specificity.
A slide from my talk on handling z-index
Documentation
At the end of 2023 and the beginning of 2024, we started building a documentation website. The primary reason was: developers wanted business-oriented examples for our components with an easy copy and paste feature. Storybook was not suitable for them, as the stories were primarily built for Chromatic, our visual testing tool.
So, we decided to build a documentation website and keep Storybook only for testing purposes.
We chose Next.js to build it, and two months later, it was online. It included business-oriented examples (as expected) along with props documentation and accessibility documentation.
Screenshot of the Button’s documentation
The code source is available here: https://github.com/Spendesk/grapes-documentation
Pair
Finally, the last initiative in order to share our knowledge, was to pair with developers. The rebranding of Spendesk in 2024 provided a fantastic opportunity for us to collaborate with every team, discuss their daily use of the Design System, and understand their needs.
To facilitate this exchange and plan the pairing sessions, we created a lot of dedicated Slack channels, one per team.
A list of Slack channels my team had with others.
Rebranding through the design system
In october 2024, the biggest project for the design system began. A full rebranding! It was a journey, a true adventure and ultimately the biggest success of my career at Spendesk.
There’s a lot to share about it, but to keep this article “concise”, I’ll simply link to my detailed article on the topic: My journey into rebranding Spendesk in 3 months.
Open source
Following the successful rebranding of Spendesk, we decided to make our work accessible to everyone. First, our design system was open-sourced, and very recently, our documentation website was also open-sourced.
If you want to learn more about our transition to open source, I wrote an article about it here: We made our Design System open source.
Some ressources:
Conclusion
Today, the design system team no longer exists, and Spendesk has shown no intention to invest in the design system anymore. We often joke about the fact that our success was the design system’s downfall. Only one big incident in 4 years, resolved in 10 minutes, the highest developer satisfaction rate across the entire Spendesk codebase, all our projects delivered on time, and a full rebranding done in 3 months with a team of 3 peoples!
So maybe because of that, the leadership didn’t understand or appreciate the huge amount of work we were doing and thought that, with much more investment (close to none to be fair), it would still work.
By sharing our accomplishments both internally and externally, it became clear that we had achieved something special here. The incredible talents within the design system team, our knowledge of the product, our connections with people, and the happiness we had working together made all of this possible.
Grapes is a success story thanks to all the people who contributed to it.
To conclude, this is the last message I sent on the public channel regarding the design system of Spendesk:
This is my final day, so before I leave, I wanted to share some things I learned along the way.
You will make a lot of mistakes and that’s okay. Working on a Design System is different, and you will learn that the hard way. We made plenty of mistakes with Pauline, but fortunately for us, Grapes was just a small side project back then. Today, a single mistake will impact every squad, every scope, and will likely generate an incident. That’s our legacy with Pauline and your burden. Sorry for that.
A change in a design system takes time. You need to test changes against hundreds of variant and state combinations. This is not an easy task, and that’s why we have extensive tests and that’s why this exists. On top of that, you need to test changes against how Grapes is used in the Frontend. On that, I must congratulate everyone of you, you really used our components in ways we never anticipated!
I’m sorry for all the “No”s, the features I refused to support, and the components I declined to add. When I was just using Grapes (i.e., not involved in its development), I was often frustrated with Aurélien (the designer who worked on the first version) because I wanted the Design System to support my use case, and he always said “No”. Four years later, I understand him. Perhaps you will too in the future.
I loved working with you, developers and designers. You made this journey amazing and you are all the reason why Grapes became a success.
All the best