03 · Prepared for the Meta hiring team
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.

Why this piece is in my application
A governance-first audit tool I designed and shipped myself, which groups findings by root cause instead of counting violations.
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.
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.
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.
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 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.
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.
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.
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.
Next case study
WSJ+: Subscriber Onboarding Design Sprint
Read the case study →
Interested in how I approach personalization, AI, and systems at scale? Let's talk.