Own work · Tooling
Role
Designer and builder
Period
2025 to now
Scope
Figma plugin, token documentation tool, AI-assisted development
Most design system problems I run into aren’t design problems. They’re handoff problems: information developers and AI agents need that never makes it out of the design file. When a workflow breaks or the same gap keeps coming back, I’d rather build a small tool than wait for one.
I don’t come from engineering. I build these with AI-assisted development, and that shapes how I work.
A prototype plugin that attaches a component’s non-visual intent, like accessibility labels, semantics, validation and behavior, to the component itself. It can flow into spec data without cluttering the designer’s properties panel. The concept is Nathan Curtis’s. This is my build of it.
Source-verified dictionaries. Seven component libraries, including Radix, PrimeNG, MUI, React Aria, Angular Material, Vuetify and Ant Design. Every prop checked against the library source, not memory.
Six archetypes. Action, Data entry, Feedback, Selection, Overlay and Media.
Visual states left out on purpose. Pressed, disabled and checked belong to variants. Their ARIA follows the active variant, so encoding them twice would only create two sources that drift.
A quiet health check. The plugin warns only when a component’s carrier is broken.
Auto-dismiss a message
Radix
duration
PrimeNG
life
MUI
autoHideDuration
Message semantics
Radix
type
PrimeNG
severity
MUI
role
Length limits
React libraries
minLength
PrimeNG
minlength
Same intent, different vocabularies. The plugin keeps each library’s native names instead of hiding them.
When a widely used Figma-based documentation script broke after Figma changed its API limits, teams were back to updating token docs by hand. I built a web tool that generates token documentation straight from a GitHub repository, with WCAG contrast checks and a view of how semantic tokens map to primitives.
I shared progress on LinkedIn and Bluesky while building it, and let the people with the same problem steer what came next.
AI over-helping. Asking for one small change sometimes got the whole codebase rewritten, breaking features that already worked.
Architecture trade-offs. The plugin’s carrier went through four designs: a plain frame, a component instance, a plugin-data hybrid, and back to the instance. Grouping in the panel won, at the cost of depending on a shared sources page.
Too many directions. Community feedback is useful until it pulls in ten directions at once.
A brief as guardrail. A written product brief the AI references on every step, with status tracking. Preserve working code, change one thing at a time.
Write down the trade-off. The plugin’s review notes record why each architecture was tried and dropped, and the health check covers the dependency it left behind.
Patterns over requests. I built what solved problems for several people, like the contrast checker, instead of one-off asks.
This is what AI-ready means in practice: getting the intent behind a component out of the designer’s head and into a shape that people and agents can both read.
Have a design system that needs this kind of work?