Related case study
The metrics I chose to track for Allica's design system.
The design system team
My responsibilities
Measuring how widely the Alchemy design system is being used throughout the platforms is a good indicator of UI consistency and how well it meets the teams needs. If they aren't using it, it's a red flag for me to investigate.
The goal is to have 80% of features using Alchemy as a positive indicator of UI coverage. We can confidently roll out UI themes and brand updates at this coverage rate. A simple spreadsheet was used to keep track of which features had migrated to the design system.
Using React Scanner to get a list of the total number of components being imported from the design system is a quick way to check how much Engineers are using the components, and how much the system is growing.
Checking the Figma Library Analytics to see how many components were inserted in to projects every quarter is a quick way to check how much Designers are using the component libraries.
These metrics are used to keep an eye on how well the design system is serving the Designers and Engineers that use it.
This tracks the percentage of components in Storybook that match the designs in Figma, tokens included. It's a manual check which is logged in a spreadsheet at the end of each sprint.
Engineers run linters to see how many times the code of our components deviates from code quality standards. 0 linter warnings is the ideal outcome.
> npm run lint
> @allica/alchemy-react@10.0.0 lint
> npx eslint ./src
> 0 errors and 0 warnings
Checking the Figma Library Analytics to see how many components were detached every quarter is a quick way to check if any components don't meed the Designers needs.
Components without documentation aren't of much use to the people that use them, so it's important to keep on top of how many still needed writing up. This is a binary measure tracked in a spreadsheet.
Patterns inform Designers and Engineers of the important decisions we've made on common user scenarios, so keeping track of any missing patterns is vital.
Really handy metrics for seeing how much value the design system is bringing, and keeping stakeholders happy.
Using Jira to see how much time front end tickets spent in the "In Progress" column each quarter is a good indicator of how much the design system is speeding up the Engineers' process. As more time saving features are delivered, the average time spent in this column should decrease.
By using the average wage of a Senior Engineer in London, and multiplying it by the time spent, we can estimate how much the average front end ticket costs the business. This should decrease as we deliver more features for the design system.
Average front end speed
* Average Senior Engineer wage
= Average cost per front end ticket
To give stakeholders an idea of how much time the design system has saved the business, I find the total time spent creating new components, and multiply it by the number of additional respositories that use them, excluding the original product. This shows how much time Engineering would have had to spend re-building each of these for each repo. It doesn't take in to account any iterations of the components, so it's extremely conservative, but it's the only metric for time that wouldn't be using any estimations.
I like to send out a quarterly survey to Designers and Engineers to get an idea of how they feel about the design system. This flags up any areas that may not be serving the teams optimally, and gives me a chance to improve it. These are the categories of sentiment.
The perceived quality of the design system by the teams.
How quickly the teams feel the design system can be used in the feature work.
How easily and quickly Designers and Engineers can contribute to the design system.
Whether or not the design system provides the teams with everything they need.
How effectively the design system team is communicating the latest updates.
How comprehensive the teams think the design system documentation is.
Every business quarter I give a presentation to Product, Engineering and Design to tell everyone how the design system is performing using these metrics, as well as giving them an idea of the road ahead.
