Systems

The two-week design system audit

Before building a system, spend two weeks finding out what you already have. The audit usually changes the plan.

Nov 06, 2025 · 5 min read · By Tomas Berg

Key takeaways

Inventory before architecture.
Count components by usage, not by name.
End the audit with a decision, not a report.

Why audit first

Most teams already have a system: a large, accidental one. The audit finds the shared core hiding inside it and tells you what a rebuild would actually cost.

How the two weeks run

Week one: inventory every surface, tag components by usage. Week two: cluster near-duplicates, measure drift, interview the people who ship.

“Inventory before architecture.”

What comes out

A reduced set of shared patterns, a drift number per surface, and a proposed sequence for the first quarter – with named owners.

The decision at the end

An audit that ends without a decision wastes the fortnight. End with one of three verdicts: extend what exists, build a core with themes, or consolidate first.

A practical checklist

Inventory every shipping surface
Tag components by real usage
Cluster near-duplicates into patterns
Measure drift per surface
Close with a decision and owners

Written by

Tomas Berg

About the author

Design director

Treats systems as an operations problem: naming sessions, version numbers, drift reports. Designs in the open with weekly walkthroughs so the first review is never the first look.

Profile

From the work