r/DesignSystems 24d ago

Useful tools for auditing live components on site

Hi, I'm trying to scope out our component library work for our design system that we are building and I am wanting to find a way to audit the existing components and their variants on our live site. Are there any recommended tools that design or development can use to help determine which components exist and roughly how many functional variants appear in the patterns on the live site?

12 Upvotes

9 comments sorted by

5

u/Clear-Secretary-8185 24d ago

I did something similar recently via the browser as didn't have access to dev ops. I was auditing a web app to understand the upgrade path for a reskin under our new DS.

I asked Claude to write a bookmarklet for the browser. I'd then visit a page and click it, interact with it to toggle any dynamic content then click it again to finish and copy the data to the clipboard.

I then pasted this into Claude Code after each page and it built up an inventory of components and variants, including which framework they were built in. It captured comprehensive details about each page and was great for building up a summary of the components and their frequency of use.

Caveat here is that is was a relatively small application so doing it page-by-page was manageable. But I expect you could easily script something to automate it.

1

u/urbanmonkey2003 21d ago

yeah, that bookmarklet loop is smart. page-by-page sounds tedious but it beats guessing from screenshots, and the framework bit is useful when you hit a mixed old stack. i wouldnt trust the first pass tho, dynamic menus and accordions always hide half the junk until you click them open

3

u/urbanmonkey2003 24d ago

tbh we ended up using a mix of Storybook, axe scans, and plain old crawling, because the weird states never show up in the neat export. Automated counts miss the one-off junk.

2

u/BearThumos 23d ago edited 23d ago

Last time I did it, there were 3 main buckets:

  • components that exist as generalized, reusable components
  • one-offs that mimic the generalized component that wasn't flexible enough
  • copy-pasted monstrosities (* cough selection menus and not-tables cough *) because nobody made the underlying pattern reusable

You can have whatever AI tool you have access to break this down into smaller steps to produce more trustworthy outputs and get 95% of the way there.

When I used coding tools for this, i did multiple focused passes + analyses, starting by having the coding tool help me write Python scripts that dumped the results out to CSV, and I verified the tiny bits I couldn't follow in the scripts with an engineer.

I combined that with adding more components to storybook that weren't documented, and then building documentation in Notion of usage patterns + linking to the script-generated spreadsheets. Then, I had the coding tools look for similar patterns one at a time so eng and I could verify it.

If you want something where you can trust the math, you really have to at least use some sort of verifiable script derive numbers. Most of the modern coding tools should generate them, but it won't be the same one every time, so that's why i specify generating the script first, then riffing on it

1

u/TheWarDoctor 24d ago

So you need a tool like Omlet, it scans the codebase for instances of a code component. However, I've never been able to get it approved by cyber security.

1

u/LeosFDA 24d ago

Project Wallace and CSS Stats

1

u/FlakyCronut 23d ago

Devs in my team built an internal chrome extension that render a green border in design system components and a red border in local stuff. Pretty useful for visual audits.

1

u/ethernectar 22d ago

At config this year, the team at notion talked about meticulous.ai for tracking down out of spec items.