Token input (left) → generated style guide + component library (right). The before/after transformation in one composed image. Show both iOS and Android columns visible.
Marc JSON
A Figma plugin that turns messy tokens into 30 platform-authentic components.
My Role
Solo designer-developer. Problem identification, token architecture, Figma Plugin API, iOS HIG compliance, Material Design 3 spec study, TypeScript implementation.
Figma
Platform
Solo
Design + Dev
30
Components
4 formats
Input support
“Design tokens exist everywhere — Notion tables, JSON files, Tokens Studio exports. Getting them into Figma as a usable component library is still manual, tedious, and inconsistent.”
Key Design Decisions
The moments that shaped the product.
A token named 'action-blue' in the input, the correct primary-colored component in the output. Annotation connecting the two with the keyword array visible in small code text.
Naming inconsistency is the default state, not a user error
When a Button needs 'primary,' the resolver searches for ['primary'], ['brand'], ['main'], ['accent'] in priority order with graceful fallbacks. A designer naming their primary color 'action-blue' should not break the tool. The tool must be more robust than the inputs it receives. This is a design-of-systems insight applied to code architecture.
The 4-mode segmented control in the plugin UI. Each mode highlighted in sequence with its consequence text displayed below. Progressive risk visualization.
Graduated sync: control proportional to risk
Figma Variables sync is destructive if you get it wrong. Four graduated modes — Don't Sync → Add New → Smart Update → Replace All — each with clearly scoped consequences visible before execution. A graduated path from safe to powerful. Progressive disclosure applied to a destructive operation.
Two-column Figma canvas: iOS components left, Android MD3 components right, generated from a single run. Same token input visible at the top of both columns.
Built Android rather than deferring — a product stance, not a scope decision
A tool claiming design systems support that only generates one platform makes an implicit claim that the other is an afterthought. The token resolver was already platform-agnostic by architecture. Deferring Android would have been scope management as avoidance. Building it was the better argument for what the tool actually is.
A generated component output next to a deliberately incomplete token input. Caption: 'Partial data produces partial output, not failure.' Show the fallback chain in a small diagram.
Partial data produces partial output, never failure
The plugin degrades gracefully at every layer. Font loading falls back from requested family → Inter same style → Inter Regular. Token resolution always returns a value. Variable sync on free Figma plans catches the exception, logs it, and continues. Fail loudly only when the user gave us nothing at all.
Process
Token-to-Figma handoff is manual, tedious, and breaks when teams name things differently.
Semantic resolver that treats naming as a constraint to design around, not correct.
15 iOS HIG components, then 15 MD3 Android components — zero resolver changes.
Tested against W3C DTCG, Tokens Studio, flat JSON, and markdown input formats.
What Shipped
30
Components
4
Input formats
2
Platforms
0
Resolver changes for Android
30 components generated (15 iOS + 15 Android), supporting W3C DTCG, Tokens Studio, flat JSON, and markdown input. 4-mode Figma Variables sync with automatic light/dark mode generation.
- 30 components generated (15 iOS + 15 Android)
- Supports W3C DTCG, Tokens Studio, flat JSON, and markdown input
- 4-mode Figma Variables sync
- Automatic light/dark mode generation
What I Learned
The hardest problem wasn't code — it was accepting that users would give incomplete, inconsistent input. Every fallback chain and fuzzy match exists because the answer to 'what if a designer names tokens weirdly?' cannot be 'it breaks.'
Signals for Recruiters