Quality work is rarely the first idea.
It's the result of iteration — exploring multiple directions, discarding weak ones, refining promising ones, and gradually converging on something strong.
Your goal as a designer should be to move as high up the fidelity gradient as possible without sacrificing speed. You'll know you're getting better when you can output ideas at higher fidelity with the same speed.
the canvas is still the most highly shareable artifact for design. it's lighter than code, and your iterations are embedded. you can easily reference old work and pull from the past it's more beneficial for your creativity and inspires better ideas
Design is ultimately about sifting through hundreds of wrong answers to find the right one Use whatever tools/process/deliverables you need to achieve this
When I spent most of my day in Figma, iteration felt natural. I'd duplicate a frame, tweak it, duplicate again. Over time, the canvas would show a trail of versions. You could see the thinking. You could explain the progression.
Iteration was fast, and it left a paper trail.
In Figma, iteration is embedded in the canvas
Early in my design career, I learned that moving quickly at high fidelity improves the quality of feedback. People respond differently when an idea feels tangible, and that makes it easier to validate direction early. My process in Figma was always some version of the same loop: duplicate, iterate, compare, repeat. That rhythm made it easy to get past weak ideas while preserving the trail of how a solution evolved.
Duplicate a frame. Modify it. Repeat. No friction, and every idea stays visible.
As more of my design work moved into code — especially for stateful UI and data visualization — I lost that fluidity.
In code, exploration becomes slow
In code, that same rhythm is structurally awkward. Exploration becomes heavy the moment each variation needs its own branch, file swap, or preview environment. Comparison slows down, sharing gets messy, and good ideas disappear into stale branches.
To explore variations, you typically:
- Modify the current implementation, overwriting the previous idea
- Duplicate files and wire up conditional imports
- Create multiple Git branches
- Or juggle preview deployment URLs
None of these approaches feel like duplicating a frame. They interrupt flow, obscure history, and slow experimentation.
Which is quicker to duplicate an idea?
duplicating the frame
new git branches
The pattern I kept rebuilding
To solve that in my own work, I started using a small version-switching pattern: a wrapper component plus a versions file that mapped labels to separate implementations. That let me keep multiple UI directions alive inside a single branch and switch between them in the interface.
I used this pattern repeatedly at Token Terminal during the Explorer redesign. It was especially useful for the treemap, where layout, labeling, and density all needed rapid side-by-side comparison. Having a structured way to explore multiple directions in code, not just in Figma, changed how fast we could move.
From workflow hack to open-source tool
After rebuilding that pattern across multiple projects, I decided to turn it into a proper tool. The manual setup still had friction — creating files and updating version maps by hand was repetitive.
UIFork packaged the workflow into an installable system with CLI scaffolding, file watching, local version management, and a cleaner promotion path from experiment to chosen direction. While the structured versioning and instant comparison was always a part of it, the packaged version made it much simpler and more efficient to create new versions and stay in flow. I moved development into a monorepo with sandboxes for testing across different framework setups.
Built with AI, and for AI
I used Claude and Cursor throughout the project — to package the original pattern into a scaffolded workflow, evolve it into an installable package, and build out the monorepo with framework-specific sandboxes.
But AI wasn't just instrumental in packaging up the tool — it's also been part of how I use it. The architecture makes UIFork a natural fit for AI-assisted development. Each version lives in its own file with a parallel structure, so any coding agent or IDE can spin up a new variation without touching existing ones. The local dev server watches for file changes and reflects new versions automatically, which means you can use whatever tool you want — Cursor, Copilot, any CLI agent — to generate ideas in parallel and compare them immediately.
Explaining a dev tool for designers
UIFork is a workflow tool, so explaining it is half the problem. When you show someone something you made, one of the first things they reflect on is "What is this?" and "Why does it exist?" A dev tool for designers can't just be described; it needs to be shown in use.
To communicate the concept, I created a short promo produced entirely in After Effects. The goal was to make a technical workflow legible in under a minute — showing the tool in action rather than describing it.
Speed produces quality
Most ideas don't survive contact with reality. The faster you move through them, the sooner you reach the ones worth spending time on.
That's what kept pulling me back to this problem. When iteration is cheap, you stop protecting your first decent solution. You move past it, try three more, and sometimes realize the original framing was wrong entirely. Burning through weaker ideas quickly earns you time to sit with the harder questions — whether something should be built at all, what the right framing is, what good actually looks like.
UIFork started as a way to make code exploration feel more like design.
It ended up giving me more room to think.