Muhammad Usman AdeebDesign system audit
A clear plan for a Figma library that has drifted.
I review your design system the way a new designer or engineer would meet it, then give you a written plan: what to fix first, what can wait, and what to stop doing.
What I review
- Tokens and variables. Whether colours, type and spacing come from tokens, and where hard-coded values have crept in.
- Component structure. Properties, variants, nesting and detached instances.
- Naming. Whether names are consistent and make sense to engineers.
- States and accessibility. Missing interaction states, contrast and touch target issues.
- Documentation and governance. How changes are made, versioned and communicated.
- Handoff. How designs reach engineering and where things get lost.
What you get
A written report with every finding, ordered by impact and effort, and a walkthrough call with your team. The report is yours to act on with your own designers, or with me.
Why me
I wrote the standards for a design system in a live product: naming, versioning and deprecation, interaction states, responsive and accessibility rules. An audit checks your library against the same kind of standards.
Questions
What do you need from us for an audit?
View access to your Figma library and a few of the product files that use it. If you have documentation or a token export from code, that helps too.
What do we get at the end?
A written report that lists what to fix, ordered by impact and effort, with quick wins separated from larger projects. I walk your team through it on a call.
Can you also do the fixes?
Yes. Many teams follow an audit with a design system setup project, using the report as the plan.
Start a project
Share a link to your library and a line about what is going wrong.