How we started our own Design System Team
Product Design is a first-class citizen in our “Tech & Product” Organization. Over the last year, one event was clearly making this statement a more tangible reality: we put together a team to work full-time on our Design System; here is the gist of “how and why we went there”.
State of the Design
Before we created the team, Doctolib’s Design System was mostly maintained by volunteers through an organization-wide “guild”. One of our core tech values is “Scale”: when our tech leaders realized that a well-maintained Design System was a key asset to achieve scalability, the organization decided to invest on it, making it a priority topic. On a more personal note, I’ve worked in the past with front-end developers and design systems and believed it was a real opportunity to enhance (frontend) developers experience at Doctolib.
Product Designers at Doctolib are using Figma, and developers use Typescript and React to build reusable components that are exposed in a Storybook. This is a very typical stack for the front-end. Our codebase is mostly organized as a monolith, so every change in our Design System is pretty quickly observed in our apps. It’s as convenient as it is dangerous and requires a large test coverage.
3, 2, 1, Start!
Ok, now, how do you start a team? Let’s try with a “vision” — a mission statement. Ours was to “bridge the gap between devs and designers with a common language: a design system”.
Working in Platform Engineering, you have to be product-minded to be as impactful as possible: to build an efficient backlog, we needed data. Data about the design system itself, but also its usage among the codebase.
Considering the state of the design system when we picked it up, we knew we had a huge debt backlog to tackle: from mis-aligned mockups to fragile code implementation, to missing typings or duplicate code. But how “huge” was it?
We instrumented our codebase to get a better idea of 2 main metrics:
- Our Design system usage (or “adoption” score) among different parts of our applications
- Our components “quality score”
We also created multiple Figma plugins and widget for data extraction and even our own Chrome extension to highlight components from the design system on a given web page on our apps.
What did we find? Well, without any particular priority order:
- Different quality levels
- Untested or broken things (mockups & code)
- Overall Low Design System adoption (!)
- Some components barely used and others over-used
- but most importantly: lots of motivation to improve the current state of things!
We combined these automated data extraction with a complete analysis of existing mockups (Figma pages) and code and *tada*, we had a full backlog ready to be tackled.
Scaling the work
Working as a Platform Team means we most of the time are not directly working on Design System components, but more spending our time being “Temple Guardians”, setting boundaries and rules, coaching people that need to implement a change in the library or reviewing their code — right before it gets into production and impact (positively!) all our applications.
We worked early on “change management”, asking every external contributor to go through a meticulous “Design Review” and to prepare proposal documents for every meaningful change. This was key for us to be able to coordinate efforts from 40+ Feature Teams.
Scaling our work was also about automating ourselves out. — or at least trying. We provided our developers with linter and formatters rules when applicable, to ensure conventions were respected everywhere in the code. Sometimes, we were even able to auto-correct parts of the code!
Spreading the word
The deeper we went into the Design System rabbit hole, the more we discovered teams from other companies working on the same missions. We started pinging them and organizing small, private meetups for the teams to meet and discuss their current challenges and achievements.
For us, it was about learning from others, and giving back what we learned. We had lots of ‘aha’ moments, realizing we all face the same challenges — with some variants. To all the people we met already — you’ve been a great source of inspiration and I hope we also inspired you!
Along the road, we had the opportunity to talk about our team creation and mission during many conferences: we could not have dreamed of a better way to assess our early achievements.
What’s next ?
To quote our very own CEO, “it’s only the beginning”. While we now focus on resorbing the debt accumulated over years, next months will be more exploratory: new or rebuilt components, accessibility assessment and improvements, developer experience focus.
