Section 1: Treating a design system as a product
Running an interface audit
An interface audit collects every variation of common interface elements across your products. It shows the size of the inconsistency problem, gives you a baseline and becomes the raw material for your first components.
What to collect
Pick categories that appear everywhere:
- Buttons and links
- Form fields, selects, checkboxes and radios
- Colours and text styles in use
- Icons
- Modals, toasts and alerts
- Tables and lists
- Spacing and layout patterns
For each, take screenshots of every distinct version from each product. Include different sizes, colours and states. Do not tidy anything at this stage. The point is to see reality.
How to run it
- Set a timebox. One or two weeks is usually enough for a first pass.
- Invite people from each product team. They know where the odd screens live, and joining the audit builds buy in.
- Use a shared board in Figma or FigJam with one area per category.
- Group duplicates and count variants. Eleven slightly different primary buttons is a powerful number in a presentation.
- Collect code evidence too. Search repositories for hard coded colours, count distinct font sizes in CSS and list component libraries in use.
Turning findings into a case
Present the audit as a story about cost and risk rather than taste:
- Duplicated work: three teams each built their own date picker, and none are accessible.
- Inconsistent behaviour: modals close on Escape in one product and not the others.
- Slow change: a brand colour update required changes in dozens of files.
Pair each point with an example screenshot or a count. Decision makers respond to specific evidence far better than to a general argument for consistency.
Prioritising what to build
From the audit, score each component candidate on:
- Frequency: how often it appears across products.
- Inconsistency: how many variants exist.
- Risk: accessibility problems, bugs or brand issues.
- Effort: how hard it is to build well.
High frequency, high risk and moderate effort items, such as buttons, form fields and modals, usually make the best first components. Rare, complex components like a rich data grid can wait.
The audit board stays useful long after this phase. Keep it as a record of where you started.