A New Way to Audit Design System Usage

My wife, Haley Ward, and I went to a Design Systems conference called Knapsack Patterns a few months ago. Someone (if this is you, let me know! Happy to drop a link!) mentioned they have a tool that highlights all of their Design System components on the page. I thought this was an excellent idea.

The words "Design System" and "adoption" in a conversation with higher-ups are inevitable. It's important in organizations where you really have to sell the value of a Design System. It makes sense they care about metrics and adoption – they want to ensure their investment is paying off.

And while I do think tracking metrics is good, I don't think it tells the full story. In my personal opinion, it's better to measure adoption visually and realistically – by going through your product and explicitly calling out the components being used. A "large number" of usage is great, but what if those pages aren't used frequently? Or what if they're "internal" pages?

Maybe these cases still speed up design and development. But I want to ensure our Design System components are front and center with our customers. That the organization is getting the most bang for their buck. And this idea of highlighting all components on a page help you tell your story on why the investment is worth it.

Rather than tallying up usages, you can show something more tangible.

"See this page? All components highlighted with a red border are our Design System components. We estimate using our components saved $x.xx/hour, etc., etc.,"

Additionally, as a visual person, I'd rather see the usage in the UI rather than look at a raw number. It's more meaningful that way. And many others feel the same way, I imagine. So go highlight them!

(I use the word "highlighting", but you can really do whatever. I've used outline or border CSS properties to do this with success. There are probably other things you can do too!)

One improvement that comes to mind is turning this into a Chrome extension. Pull up a page, click the extension, and voila – see all of your components highlighted.

The advantages of this are that any non-technical person can use this tool to perform an audit. Normal coding methods require a developer. But not this! At least after it's "completed".

The disadvantage is similar to it being just a script or a development-only tool – it's time consuming. Someone has to know how to get to every single page. I'm a developer, I want to automate this!

Because Haley and I are married and both in Design Systems, we started brainstorming how we could take it one step further. Then we landed on something I quite like – tie this functionality into your existing end-to-end tests.

Most end-to-end tests are already navigating through your application. Maybe even going to very specific pages that may be difficult to reach, depending on the data or path to get there.

As you hit areas you care about, create a custom function that will:

• Highlight all Design System components on a page
• Take a screenshot
• Turn off the highlighting

Store all of these images in a directory. Then you can provide a "report" of sorts to anyone who wants to know about Design System usage.

By tying in to your existing end-to-end tests, it means you get this auditing almost "for free". I dig it.

After you get some of this tooling in place, you'll have a way to check which parts of the application(s) are using your Design System.

Designers won't have to guess if they see a component that looks like a Design System component, but isn't quite right. If it doesn't have a red border, it's hand-rolled! Go chat with the team about why.

You can reason about costs easier – "this non-Design System component is estimated to cost $x.xx in maintanence, but if we switch to the Design System component that goes away". And on the flip side, as mentioned above, you can estimate cost savings of building new features and applications.

It also opens the door to notice patterns in your applications. Just like going to every page manually is time consuming, it's also difficult to spot patterns by popping around the application yourself. If you have an image of every part of the application handy, although it's a lot to sort through, you could more easily recognize patterns by flipping through everything. This is probably better done in Figma using designs, but sometimes pages exist in code that don't in design. So this gives you the full view – code is the source of truth and what customers interact with at the end of the day, not your designs.

Overall, I think this goes a long way and could help teams track and measure adoption in a more meaningful way than "numbers should go up!". Let me know what you think!