[ Case study ]
DSI: Design System Intelligence
A governance-first audit plugin for design systems in Figma. DSI scores system health, classifies severity, and groups findings into root causes such as Missing Tokenization and Detached Local Styling, so teams learn what to fix first rather than how much is wrong. Designed, built, and published free on the Figma Community.
- Client
- Self-directed product
- Role
- Design and build
- Year
- 2026
- Disciplines
- Design Systems, Governance, Design Tokens, Accessibility, Product Design, Tooling
[ Impact ]
Root cause
Findings grouped into causes like Missing Tokenization, not a flat issue list
3 profiles
Baseline, Strict, and Enterprise, so strictness is a deliberate choice
No network
Runs entirely locally, so it is safe on confidential work
DSI is a governance-first audit plugin for design systems in Figma. It inspects a file for system health, groups what it finds into root-cause patterns rather than a flat list of complaints, and tells a team what to fix first. I designed and built it, and it is published free on the Figma Community for personal and commercial use.
Why an audit tool needed to exist
Design systems fail quietly. Nobody decides to abandon the system; a deadline arrives, someone detaches a component, a colour gets pasted in as a hex value, and the library slowly stops describing the product. By the time the drift is visible in the interface it is expensive to unwind, and the team has no shared account of how it happened.
Existing tooling mostly counted problems. Counting is the easy half. The hard half is judgment: which of these three hundred issues actually matter, which are symptoms of the same underlying cause, and what should a team do on Monday morning. DSI was built around that question rather than the counting one.
Root cause over issue count
The central design decision is that DSI does not present findings as a list. It scans for token compliance and hardcoded styles, accessibility and contrast risks, naming quality and structural consistency, and component and spacing signals, then looks across those findings for repeated patterns.
Two root-cause signals do most of the work. Missing Tokenization says the team never had a token to reach for. Detached Local Styling says the token existed and someone stepped around it. Those are the same symptom on the surface and completely different problems underneath: one is a gap in the system, the other is a gap in adoption. A tool that reports both as hardcoded colour is telling a team almost nothing.
Counting issues is the easy half of an audit. The hard half is telling a team which of them are the same problem wearing different clothes.
Making the output decision-ready
An audit is only useful if someone can act on it, so the output is shaped for a decision rather than for completeness:
- A Design System Health score, so the state of the file is one number a lead can carry into a planning conversation.
- Severity classification across Critical, High, Medium, and Low, so triage does not start from scratch.
- Fix First prioritisation, which is the screen most teams open and the reason the tool exists.
- Reveal in Canvas, jumping from a finding straight to the node that caused it, so a result is always traceable to the thing itself.
- Exportable reports in multiple formats, because the audit usually has to travel to people who do not open Figma.
Governance profiles: strictness as a setting
A design system at a startup and a design system in a regulated enterprise are not held to the same standard, and a tool that pretends otherwise gets uninstalled. DSI runs against Baseline, Strict, or Enterprise governance profiles, so the same scan produces an appropriate verdict for the team running it.
This is the part of the product I think about most. Encoding strictness as an explicit, chosen setting is more honest than shipping one opinionated ruleset and calling it best practice, and it means a team can raise its own bar deliberately as the system matures.
Cognitive and focus analysis
Alongside the system checks, DSI can optionally analyse layout density, hierarchy, and readability. These are softer signals than a contrast ratio, so they are opt-in and reported as signals rather than failures. The distinction matters: a tool that presents a judgment call with the same confidence as a measured violation teaches people to distrust all of its output.
Built to be trusted with a real file
DSI has no network access. Nothing leaves the file, which is what makes it usable on the kind of work that is under NDA, and that constraint shaped the architecture rather than being bolted on at the end. The plugin is free under a Community licence for both personal and commercial workflows, because a governance tool that only the well-resourced can run does not fix the problem it claims to address.
Where it stands
DSI is in its third version, used by design system teams, product designers, UX architects, and platform and governance teams, most often to review library quality before scaling a system or handing it off. It is also the tool I use in my own writing: the audit fixtures behind my published drift and conformance work are generated with it, which keeps the argument and the instrument honest with each other.