Design

Grayscale first, styling second.

A finished-looking mockup gets reviewed as a design. A rough one gets reviewed as a structure.

Download for macOS
v0.1.33 · .dmg · Apple Silicon & Intel
Signed & notarized by Apple · opens without a Gatekeeper warning
sha256 698955a0187bc039f4c74f5d05a9f10fbb27376a45788a0a241d1326b73873c7
Download for Windows instead
$curl -fsSL https://lucidtrain.com/install.sh | sh

When Design mode is building an app UI it starts with grayscale wireframe pages rather than finished screens. This is the well-documented effect that a polished mockup attracts feedback about colour and copy while a rough one attracts feedback about whether the flow makes sense. Once the structure is agreed, upgrading a page to full fidelity is a single action, and the content survives the upgrade because only the styling is rewritten.

Fidelity is a decision, not a stage you skip

The expensive questions in an application are structural: a flow with a dead end, a state nobody designed for, a screen reachable from two places that behaves differently. Those are visible when the page is grey boxes and invisible once it has a colour scheme, because attention moves to the surface. Starting grayscale is a way of asking the right question while it is still cheap to answer.

The upgrade preserves content

Going from wireframe to full fidelity rewrites the styling and keeps the content and the section structure intact. Section identifiers survive the transition, which is what stops the upgrade from being a regeneration that quietly loses the decisions you already made.

Per page, not per project

A multi-page project keeps a wireframe and a built version per page and lets you prefer either one when previewing. In practice that means a project mid-flight is usually mixed: two pages finished, three still grey, which is exactly the state a real design is in most of the time.

Reviewing structure needs different people

The other reason to hold styling back is that a grayscale flow can be reviewed by someone who is not a designer. An engineer or a product owner will tell you a step is missing from a set of grey boxes and will say nothing at all about a finished-looking screen, because a finished screen reads as somebody else's decision already made. Keeping it visibly unfinished keeps the review open to the people who know what the flow has to do.

One file, no build step

Output is one self-contained HTML document with every style inside a single style tag. No build step, no bundler, no external stylesheet and no framework. That is a real constraint and it is also why the result is portable: it opens in a browser, drops into a pull request, attaches to a brief and deploys to a static host without carrying a toolchain behind it.

Which engine runs it

Design runs on the Claude Code CLI or the Codex CLI installed on your machine, signed in as you. There is no separate design subscription and no API key for the design engine. Cursor CLI and OpenCode can drive coding tabs but not this one, because the design canvas has no provider implemented behind them.

FAQ

Questions

Do I lose my content when upgrading?

No. The upgrade rewrites styling only. Content and section structure carry across, which is the point of doing it in two steps.

Can I go back to the wireframe?

Each page keeps both versions and you choose which one to preview, so a built page does not destroy the wireframe it came from.

How is this different from the Diagram tab's app wireframes?

The Diagram tab draws screens as cards in navigation order, which is a picture of the structure. Design mode's wireframes are real HTML pages that later become styled pages.

Related

Last updated