Measuring Design System compliance of your teams
Measuring a Design System is a really hot topic, but whatever the level of maturity of your Design System, gathering data on your Design System as soon as possible is definitely a great idea to:
- get buy-in from your top management (early stage)
- improve your codebase and design consistency (medium stage)
- scale your processes, fasten and ease maintenance, improve workflows (advanced stage)
That’s what we did at doctolib. And, as a side effect, it also helped us fight against legacy code, and ensure tech teams are not shipping custom code. To make this a reality, we decided to equip our teams with tracking methods and dedicated tools.
Design System Compliance definition
First, we needed to estimate the compliance per team, but how to precisely define design system compliance? Seems quite basic, but when deep diving in the craft of our tools, we struggled to determine what can be defined as compliant from what can not.
Let’s start with Figma, as its data is easier to compute.
Our Product Designers are using different Figma libraries. All the components from these libraries have a name starting with an emoji based on this nomenclature:
- 💠 Oxygen components = the heart of the Design System, with atoms, agnostic and excluding all business logic.
- 🧩 Modules = multiple business related libraries, generally organisms composed of 💠 Oxygen components
- 💟 Icons = our repo of icons
What we’re doing on Figma is just counting the number of instances with emojis versus instances without. Of course, we have many edge cases to handle, such as:
- Fonts: a content using a declared font style with a declared Color style (or variable) is considered as compliant.
- Hand-off elements (arrows, annotations to devs, cat stickers…) are skipped
- Deprecated components, the 💠 emoji is replaced by a ☠️, are counted as non-compliant
On the code side, it’s a bit more tricky. We ended up with two complementary systems:
- First one: a (more or less) similar estimation than on Figma. Our components are flagged with a data attribute, indicating its status: Oxygen (for live and official components), legacy or deprecated
- Second one: a set of rules called ESlint, generating comments into the code, and those comments are counted.
For instance, an official component overidden with custom CSS will be considered half compliant, because this is a component coming from the Design System but it is breaking an Eslint rule.
About duration of compliance, we only consider the compliance on files edited in the last 30 days, as considering compliance of archive files are not relevant.
And… so what?
Once we know how to compute our Design System, the next step is to make it visible and actionable for feature teams. So, we decided to equip our teams with dedicated tools.
OxyScan, our powerful Figma plugin
As our Product Designers are spending a huge part of their time in Figma, we had to find a go-to solution included in their usual workflow. Moreover, creating a plugin in Figma is quite simple in terms of code, so it was a no-brainer solution.
This homemade plugin is scanning the active page of the current file the user is in, and provides:
- a global compliance score in percentage
- a compliance score per Section and Frames
- a detailed split of items per Section / Frames (number of 💠Oxygen components, number of 🧩Modules, number of non-compliant ⛔️items)
- a list of links pointing to non-compliant layers to be fixed.
We don’t track the usage of this plugin yet, but it really helps standardize and clean our delivery files. The team made a huge effort going from 47% of compliance on average when we deployed the plugin to more than 86% four months later. One of Doctolib’s Product Designers, Alice Raynaud wrote a great article on how this plugin is used internally:
Next step on this plugin would be to make it more actionable, like providing tips or fixing guides or guidelines links.
OxyScan is available on the Figma Community, feel free to use it (ensure to use the same Emojis nomenclature as provided).
The Global report
Based on OxyScan, we also created automations to extract data directly in a dashboard. Concretely, a script is running every night, scanning all files among identified Figma teams, and looking for high-fidelity pages.
As for components nomenclature, those high-fidelity pages are flagged with a dedicated emoji 📘 to help the scanner target only pages handed off to developers.
Measuring Design System Compliance on production
Dedicated Feature team dashboard
We provide to each feature team a refined dashboard with:
- the overall compliance of the team and the trend
- the number of components, legacy, deprecated and their path to concerned files.
- the list of all broken ESlint rules, and the path to the concerned files
All those figures are extracted with the code owners feature of Github (which helps us know which file is allocated to which feature team).
Highlighting legacy and deprecated components on production
To help teams visualise their debt other than having a list of URLs or items on the dashboard, we created a simple but efficient tool to display component status while browsing in production.
Based on a Chrome extension, our tool, called X-Ray is basically highlighting compliant components, the legacy ones, the deprecated ones. Components that are overidden in CSS or using deprecated properties are of course displayed as non-compliant.
As displayed on the homepage hereafter, are highlighted:
- in Green, compliant components (Headline and Search titles for example)
- in Orange, legacy components (search inputs for example)
- in Red, deprecated components (right button on top menu)
Anything not highlighted is not part of the Design System.
Next steps
Equipped with those tools, our teams are really more concerned about their own compliance, and it really helps to evangelize the Design System.
Next big step for us is to measure component quality, from a code craft perspective, but also from an accessibility point of view. More to come in a future article :)
🙏 I’m speaking on behalf of the Oxygen Team Anaïs Macé, Hélène Pruvot, Michael Blancon Tardi, Matthieu Vignolle, Julien Tanay, Nicolas Declercq and Victor Michaud.
