At our company retreat last month, our CEO showed up with a Replit prototype and 10 PRDs (around 12 pages each) for a new product. By the end of the day, I’d mapped the flow in Figma, mocked every screen using our design system, created a branch, and generated an HTML/JS prototype.
That prototype surfaced friction points in the actual flows, edge cases we hadn’t considered, complex interactions the written specs didn’t capture. All of this is expected. We spent the next week and a half iterating on the prototype, building out complex flows and super experimental UI patterns. Two weeks later, we had production-ready front-end code.
I’ve systematized this workflow; Figma for structure, design system for constraints, branch for experimentation, prototype generation for interaction testing. It works because I know where to apply rigor and where to move fast. I know which AI outputs to trust and which to verify.
Most designers are still looking where they fit in those workflows.
Looking for tools
Most AI prototyping tools fail in connecting to your existing design system. They generate a UI that looks plausible but doesn’t respect your system’s logic. Non-technical stakeholders see a working demo and think it’s production-ready. Designers and engineers know it’s not, but can’t always articulate why.
When I came across Supernova, their pitch aligned with what I’ve been trying to achieve: AI prototyping powered by your actual design system. Token-aware generation. Component libraries that propagate updates. Tools that wrap systematic workflows for teams to use.
Supernova’s value proposition addresses this directly: teams can generate high-fidelity prototypes using real design system constraints to surface issues before engineering starts. Not “anyone can generate production code”. That’s just not real. But “teams can prototype with the actual system to validate flows and interactions.”
That distinction matters.
So I decided to test whether Supernova could actually deliver on that promise. Could I set up our design system, so team members could prototype with it from day one?
Setting up: The token integration layer
Supernova connects to Figma through a plugin. Free tier allows one Figma file as source, and multiple on paid plans (it also integrates to Tokens Studio and Storybook). So I consolidated components into my tokens file. Not ideal for my file structure, but needed for testing.
The plugin syncs Figma variables and converts them to Supernova’s token model.
I’ve hit my first issue. Supernova needs explicit scope assignments to determine token types. I had font weights as numbers (ExtraLight = 100, Regular = 400). Supernova expected strings.
This isn’t a bug. It’s just how they expect the input. Figma variables use scopes to indicate usage (Width and Height, Font Weight, Corner Radius). Supernova maps those scopes to token types. If you have a number variable with a unique scope, it becomes the corresponding token type. Multiple scopes? Generic dimension token.
I went back to Figma and restructured. Changed the font weights to strings. Republished the library.
Then pushed changes through the Supernova plugin.
Then triggered sync in Supernova.
Three steps. The Figma publish is particularly slow. Republishing a library in Figma never feels fast, then a plugin push and a platform sync step layered on top.
Not a deal breaker, but it could be polished.
What works
The table view in Supernova is legitimately better than Figma’s variables panel. Cleaner, more readable, better for reviewing token relationships at a glance.
Token sets as custom properties work well. I can tag tokens as Primitives, Semantic, or Component tokens. That metadata carries through to documentation and code generation.
The collection metadata is preserved. My Color Primitives and Semantic Colors distinction remains clear. I would like to have separated primitives and semantic colors.
Mode mapping to themes is conceptually sound. Your Figma modes become Supernova themes, which then propagate through documentation and code pipelines.
What still needs work
You cannot move tokens or groups in Supernova. You can create new ones, but anything imported from Figma is locked to its original structure. Want to reorganize your taxonomy after import? Go back to Figma. Rebuild. Republish. Re-sync.
No bulk actions. You can add custom properties one token at a time. You can’t select 50 color tokens and tag them all as “Primitives” in one operation.
Can’t sort by collection. The table shows collections, but you can’t use them as a sorting or filtering dimension.
Redundant columns. The value column shows the same data for your default mode. It’s useful to see mode variations, but having two columns of hex codes when they’re identical feels wasteful.
Default mode visibility. I have a Default mode that I use for non-color tokens like size and spacing. Can’t hide it from the color token view. Can only delete it, which breaks those other token types.
I mean. The core sync works. The visualization works. But the sophistication needed for actual design system management at scale. Reorganizing, batch operations, filtering complex token sets, isn’t there yet.
I haven’t tested the AI prototyping layer yet. That ‘s next.
What I’m watching for
If Supernova is the foundation for AI prototyping that actually respects your design system constraints, that could be transformative.
The vision aligns. Supernova is trying to systematize the workflows I’ve built manually but on steroids. They’re trying to make AI-assisted design system work accessible to designers who don’t have my technical background.
That ‘s worth doing.
The execution has rough edges. Some are low hanging fruits (bulk actions, better filtering, reorganization tools). Some might be fundamental architecture decisions (one-way sync, three-step publish cycle).
The question isn’t whether Supernova is perfect. The question is whether it’s solving real problems for real teams, and whether the trajectory points toward closing those gaps or entrenching them.
I’ll know more after testing the AI prototyping layer. That’s where the actual value proposition lives. Can team members generate prototypes using our design system without hallucinating generic components?
If yes, the integration tax might be worth it.
More soon.