Design Intelligence Audit
We examine the gap between your design files and code, where documentation is breaking down, and how your team actually works with the system. You leave with a clear diagnosis and a specific path forward, not a scorecard.
Most design systems don't fail loudly. They drift: a token overridden here, a component rebuilt there, documentation that quietly stops being true. The audit finds where your system stands before the drift gets expensive.
§ What we look at
Token architecture
Whether your design decisions live in tokens the system can enforce, or in someone's memory.
Component coverage
What the library covers, what teams rebuild by hand anyway, and why.
Documentation and governance
Whether the docs describe the system you have, or the one you had a year ago.
Figma file health
How the design files are structured, and whether they still match what ships.
Accessibility baseline
Where the system supports accessible defaults, and where it leaves them to chance.
How your team works with the system
What the people inside the system trust, what they route around, and what that tells us.
Putting agent-generated interfaces on top of the system? We add a seventh area: whether your tokens and components are structured for agents to consume safely, and where the human checkpoints belong.
§ What you get
Findings scored by severity
Every finding rated from critical to low, so your team sees what matters first and what can wait.
A maturity profile across six dimensions
The shape tells the story. A system strong in tokens and weak in governance fails differently than the reverse, and the profile makes that visible.
A recommended path forward
The specific next engagement, not a generic roadmap. Sized to what we found, named plainly.
A report written to be read
Your team keeps it. It works as a working document, not a slide deck that gets filed away.
§ How it runs
We read the files, the code, and the documentation, and we talk to the people who work in the system every day. No workshop theater, no survey blast.
The examination fits the system: a focused pass for a young library, a deeper one for a system carrying years of history. Either way, you see everything we see.
§ Questions
Do we need to prepare anything?
No prep deck, no cleanup. We want to see the system as it actually is — read access to your design files, your component code, and your documentation is enough.
What if our system is a mess?
Mess is information. Where the system drifted tells us how the team really works, and that shapes a path forward your team will actually follow. The audit is a diagnosis, not a judgment.
What happens after the audit?
The report names a specific next engagement, sized to what we found. Some teams take the diagnosis and run with it themselves. Some continue with us into a Build or Care engagement. Both are good outcomes.
What does it cost?
Let's talk about what fits. Scope depends on the size of the system and what you need examined, so we shape the engagement to the situation rather than quoting a flat package.
Let's talk about what fits.
Tell us where the system hurts. We'll tell you honestly whether an audit is the right first step.