My First Design System Audit

The first design system audit I ran was not called an audit. It started as a request to "clean up the UI before launch" on a product surface that had grown through several urgent releases.

The team was not careless. Everyone had made reasonable choices under pressure. The problem was that those choices had happened in isolation: one form pattern from a prototype, one card style from a sales page, one empty state from a late-night bug fix.

I began by taking screenshots of every page state I could reach: default, loading, empty, error, permission denied, and the odd states that only appeared after a partial save. Then I placed similar pieces next to each other.

The moment that changed the conversation was not a beautiful component inventory. It was a row of six nearly identical empty states with six different spacing decisions.

I expected to find missing components. Instead, I found missing defaults.

• Page headers had different gaps between title and supporting copy.
• Forms used three help-text patterns.
• Secondary actions moved between header, footer, and inline placement.
• Empty states had different title casing and button hierarchy.
• Status badges mixed product language with implementation language.

None of those findings required a giant system rewrite. They required names.

The most useful artifact from that audit was a short decision log. It translated screenshots into choices the team could reuse.

# Audit decisions

- Empty states use one title, one sentence of recovery copy, and one primary action.
- Form help text sits below the label unless it describes a destructive consequence.
- Page sections use the same vertical rhythm across setup, review, and settings screens.
- Status labels should describe the user-visible state, not the backend enum.

That document was less glamorous than a component library, but it was easier to adopt. Designers could review it quickly. Engineers could apply it without waiting for a package release.

I would still start with screenshots. Code search can tell you where classes repeat, but screenshots reveal whether the product feels coherent to a person trying to finish a task.

I would also keep the first pass intentionally small. The goal is not to catch every inconsistency. The goal is to find the handful of patterns that slow the team down every week.

I would bring support and product into the review earlier. The best notes came from people who knew where customers hesitated. They cared less about whether two cards shared a component and more about whether the interface explained the next step.

The design system work that followed was modest: a page header pattern, empty-state guidance, a tighter form layout, and a few semantic tokens. But the team had a shared reason for each change, and that made the system feel like a response to real work instead of a parallel project.