Generative UI

Reduce prototype creation

A creative tool that turns a prompt into a runnable prototype in the thread, so a designer can feel a flow before committing to build anything.

Product Design · Generative UI · Frontend Engineering · 2026

https://generative-ui-psi.vercel.app/

Prototyping one flow takes far too long

In the AI tools designers already have, testing a single flow is out of proportion to the question being asked. Either you scaffold an entire project to see one screen move, or you generate an image of it, and an image will not tell you how the thing feels. Both routes cost more than the idea is worth at the moment you want to check it.

A way to test a flow without committing to a project

I wanted the smallest possible distance between a prompt and something a designer can actually operate. One flow, running, in the conversation. No repository, no setup, nothing to tear down afterwards, so trying an idea costs about as much as describing it.

Generative UI: generated prototypes sitting inline in the conversation feed, each one runnable where it sits

The one KPI — target

30%less time for a designer to reach a working prototype

The target set at the outset, and the single measure the tool was aimed at.

Building it with Claude Code

I used Claude Code to write the stack, wired to Anthropic's Sonnet 5 and Haiku models, and worked by testing the generated code against real prompts rather than designing the surface first. The editor and the running thread stayed side by side throughout, so every change was judged against an actual generated reply.

The prototype card component open in the editor beside the running app, where a generated task-list prototype sits in the thread inside a phone frame

One minute is still a very long time

Generation got fast. It did not get comfortable. Even at around a minute, that minute is dead air, and dead air in a creative tool fills up with doubt: whether it heard you, whether it is working, whether starting over would be quicker. The speed problem had turned into a waiting problem, and cutting seconds further would not have solved it.

Generative UI: the waiting indicator, idle and during a tool-call phase

Three ways to fill the wait

I prototyped the waiting state three ways and watched how each one felt over a full generation, not as a static frame.

Option 1: shimmering text that keeps updating

Option 2: a skeleton holding the card's shape

Option 3: an ASCII torus turning on a phone mockup

Text and motion answer different questions

Neither half carried it alone. Running the shimmering text together with a moving visual is what made the tool read as working rather than stuck: the text says what is happening, the motion says it is still happening. Once both were on screen, the same minute stopped feeling like a stall.

Generative UI: generated prototypes expanded and running at full size

What I took from it

Fast is not the same as responsive
Cutting generation time was the obvious goal and it was not enough. Past a point, the work moved from making the wait shorter to making it legible.
A waiting state has two jobs
Say what is happening, and prove it is still happening. Text alone can look frozen and motion alone can look decorative. The pair is what reads as alive.
The constraint is the product
Refusing to scaffold a project is not a missing feature, it is the whole reason to open the tool. Keeping that boundary sharp mattered more than any single screen.