Design system audit for messy libraries

A design system audit is a structured, mostly read-only review of your existing Figma library and production UI. Tokens, components, documentation, accessibility signals, adoption gaps. The output is a prioritized remediation roadmap, not a jump straight into a redesign. Clearly Design's audit offer is the commercial front door to messy-library cleanup and AI-ready systems work. We check whether humans and AI coding tools can share one source of truth (Taste Profile / DESIGN.md, tokens, and specs), then path into the live AI design systems project or a monthly design-partner plan (see pricing). The deep method for the code-side audit document lives in Article 3. This page sells the offer and the path after the audit.

This is a sibling to Design Systems for AI Teams, not a rewrite of it. If you want the how-we-audit-in-code walkthrough, start with Article 3. If you already know you need the full build, go straight to the project page.

When you need an audit (not another redesign)

Something's wrong, and you know it. You're just not sure whether the right fix is more screens or better foundations.

You already have "a design system," or a Figma library that claims to be one. It's messy. Components named Button copy 3 FINAL live next to the real button and nobody is sure which one production uses. Tokens exist in Figma but they are not the tokens in Tailwind. Engineering ships screens that look almost right and drift a little every sprint. Designers stop updating the library because it does not reflect reality. The team works around the system instead of inside it.

AI tools make this worse, not better. When Cursor or Claude reads your repo for context, it inherits the drift. v0 generates a screen that does not match the product you already shipped. The gap widens every week. What was a minor inconsistency becomes a compounding problem once an AI is producing new UI at speed.

You also need an audit if you are about to scaffold a new surface, hire your first in-house designer, or put real money into a system. Building more on sand is more expensive than finding out now.

What you do not need is a full product UI/UX redesign by default. A redesign changes what users experience. An audit changes what your team works from. If users are confused or converting poorly, consider a redesign. If your team does not trust the library, start here.

What Clearly's design system audit covers

The audit runs across two layers. Both are read-only until you choose a path.

Figma library and production code. We review the library against what actually ships: tokens (color, type, spacing), components and variants, theming, documentation, accessibility signals, and adoption. Coverage is a vanity number. Adoption is the real one. A library with 200 components that engineers ignore is worse than 40 they trust. We look for Figma↔code drift, duplicated primitives, and governance (or the absence of it).

AI-readiness. Can Cursor, Claude, or v0 read a single source of truth? Do tokens and specs exist somewhere a model can reference without inventing a new brand? We check whether a Taste Profile / DESIGN.md exists or needs to be created, and whether Claude Code design skills can run against a coherent system. If they cannot, we flag exactly what is missing. If the job after the readout is ongoing agent governance (not another library cleanup), that path is AI UI brand governance.

That is the wedge versus typical agency PDF audits. Those reports are good at tokens, components, docs, a11y, and a remediation roadmap. They are not framed for teams whose inconsistency is being amplified by AI coding tools. We are.

The output is decisions plus a prioritized remediation list. Not a surprise redesign mid-read. Not a new Figma library you did not ask for.

The deep method for the code-side document (.agents/design-system-audit.md) lives in Article 3 of the AI-ready series. This page is the commercial offer. That article is the how-to. Keep them separate on purpose.

Audit vs UX audit vs redesign vs AI design-systems project

Different problems need different work. Here's the honest comparison. More of this sits on our Solutions index if you are still mapping the shape of the engagement.

Work	What you get	When it fits
Design system audit (this page)	Prioritized remediation roadmap, AI-readiness gaps, decisions rather than new screens	Library is messy, Figma and code have drifted, AI tools inherit bad patterns, you are about to scale or hire
UX audit / product redesign	Heuristic review, flow improvements, new visual direction	Users are confused or converting poorly, the product needs a fresh direction
Full AI design-systems project	AI-ready system: tokens, DESIGN.md, Taste Profile, patterns, prompts	You already know you need the foundation built, not just mapped
Internal tools / portals	Prototype-first portal design and production Next.js	The problem is one internal product or client portal, not a shared design library

If the library is the bottleneck, stay on this page. If the product UI is the bottleneck, use the redesign. If you want the system built for Cursor and v0, use the AI design-systems project.

How it works

Four steps. All of them non-destructive until you pick a path.

1. Access and intake. You share the Figma library and grant read access to the repo. We ask a short set of questions: what's breaking, what the team avoids touching, which AI tools are in the stack. No three-week kickoff.

2. Read-only audit. We go through the library and codebase without changing anything. We're mapping what exists, what's used, and what AI tools can actually read. Tokens, variants, docs, a11y signals, governance.

3. Readout. You get findings organized by severity: what's broken, what's drifting, what's missing for AI-readiness, and where the highest-leverage fixes are. Priorities, not a wish list. We walk through it together.

4. Path choice. Three legitimate outcomes. Stay DIY with the report. Work the list on a design-partner retainer. Or move into the full AI design-systems project, where Week 1 is a structured audit inside that engagement.

The audit does not lock you in. It gives you enough information to fund the next step, or to decide the next step is not us.

Pricing

I scope this work in back-to-back 2-week Sprints instead of one fixed project fee. It keeps us honest while the product is still moving.

• Usually 1–2 Sprints for the messy-library readout. Cleanup or a rebuild comes after, as more Sprints or a monthly plan.

See pricing for the Sprint rate, and for the monthly plans if you want me to stay on after the first push.

What working together actually looks like

The pattern across Clearly clients is not "we needed prettier screens." It is "we needed a partner who understood the system behind the screens."

Andy Berkowitz at Suggestion Ox wanted to prototype fast and then have an LLM translate that work back into the actual application. That only works when the design system and the codebase are genuinely in sync. Without that sync, the model guesses, and the guess drifts.

Product DesignDesign Systems

Feature Design + Prototype

2 weeks

Employee Feedback Software

Designing Live Q&A for Suggestion Ox: A New Feature That Had to Feel Native

Suggestion Ox

A feedback product with strong product-market fit wanted to add Live Q&A for meetings: moderator controls, AI moderation, live answers, and audience upvoting. The feature had to feel like a native part of the existing system, and it had a lot of moving screen states to get right.

Prototype

Fully interactive

Every state built and clickable, not mocked up flat

Tooling

State switcher

Jump to any screen state to evaluate and plan them all

Handoff

Style guide for dev

Backend team builds the feature from a defined system

Will Andre at NodCards described a true partnership: the team envisions themselves as owners in the outcomes, not passengers in someone else's design process. That kind of ownership starts with a shared picture of what the system actually is.

Craig Hewitt at Castos has worked with Francois as a UX designer for years and is blunt about putting product and design first. A messy library does not just slow the team down. It erodes confidence in the system. Clarity restores it.

Roeland van Nieuwkerk at Wealthstack wanted product thinking beyond aesthetics. Wealthstack Budgets is an example of feature work that had to feel native to an existing product, not bolted on.

Jordan Gal at Hey Rosie pointed to a flat monthly fee, quick turnaround, and a high level of execution. The Hey Rosie product work is two years of Figma product design on a retainer, including a design system that now lives beyond the file it started in.

Product DesignDesign Systems

Ongoing

Since Sep 2024

AI Phone Answering for Small Business

Two Years of Product Design for Hey Rosie: From a Blank Canvas to a Design System

Hey Rosie

In 2024 an AI phone receptionist had no UI patterns to borrow, only the wrong ones. Rosie needed a product a non-technical owner could set up like briefing a new hire, that avoided chat-style AI patterns, and that could change every week for two years without drifting apart.

Engagement

2 years, ongoing

One flat monthly subscription since Sep 2024

Process

Figma to dev-ready

Every feature shipped from an annotated Figma spec

Foundation

1 design system

Lifted out of Figma into rosie.tasteprofile.io as the source of truth

None of those quotes are an invented "X% consistency" metric. They are why we treat audit as a front door, not a PDF souvenir. The method sits in the AI-ready design systems series. The full build sits at Design Systems for AI Teams.

Who this is for (and who it is not)

This is for you if:

• Your Figma library exists but the team does not fully trust it
• You are shipping with Cursor, Copilot, Claude Code, or v0 and the generated UI does not match
• You are about to invest in a system and do not want to rebuild on sand
• You need a prioritized roadmap leadership will actually fund

This is not for you if:

• You need greenfield brand-only moodboards. That is a different kind of work.
• You want someone to "just make it pretty" with no code access. An audit without the repo is half an audit, maybe less.
• You only need a one-page UX heuristic review. That is closer to a product redesign engagement.

Questions worth answering before we talk:

• Where does the team actually look when they need a component: Figma, the repo, or Slack screenshots?
• Which AI tools are generating UI today, and what do they get wrong first?
• Are you trying to clean the library, replace it, or find out which of those you can defend to leadership?

If you are in the right spot, the next move is a discovery call. Bring a Figma link and the willingness to grant repo read access. We'll tell you what we see, how we'd structure the work, and whether a readout, a retainer, or the full AI design-systems project fits.

If you already know the system needs more than a review, go to the AI design-systems project. If you're weighing an ongoing partnership, the monthly plans are on pricing.

Frequently asked questionsFAQ