Design, before code
Prompt-to-app tools take a sentence and start writing files, which means you find out what the interface looks like by reading whatever came out. That is backwards. Draw the screens first, argue with them while they are cheap, and only then let anything be built.
The interface is a contract too
The rest of NautFlow is built on one stubborn idea: write down what you are building before you build it, and measure the result against that rather than against a model's summary of it. Requirements, architecture, tickets, and an acceptance test written before a line of product code exists.
The Designer is that same argument applied to the part users actually touch. A screen is a decision about what matters, what is secondary and what is not there at all. Discovering that decision after the code is written means either living with it or paying to undo it.
Changing a layout in a mock costs a sentence. Changing it after the API, the state and the tests are shaped around it costs a week.
How it works
For anything with a user interface, a design pass drafts the primary screens as self-contained HTML mocks. They render live in the centre pane while you steer from a chat beside them. No component library to fight, no toolchain to install, nothing implemented yet. Move it, cut it, ask for a different arrangement entirely, and the cost is the sentence you spent asking.
Which is the whole point of doing it here rather than later. Cheap to change is not a nice property of the design stage; it is the design stage.
The craft brief is doctrine, not a setting
Ask a model politely for "a clean, modern interface" and you get the average of every interface it has seen. That average is real and recognisable: rounded cards in a neat grid, a hero, an accent colour doing all the work, and the distinct feeling that a component library assembled itself while nobody was looking.
So the design agent runs with an explicit craft brief instead:
- Restraint. Fewer elements, more considered. When in doubt, remove.
- Deliberate spacing. Tight to group, generous to let things breathe. Not one uniform gap everywhere.
- Real typographic hierarchy. Weight and scale doing the work, so the eye knows where to land.
- Asymmetry over grid-sameness. A layout with a point of view, not four equal columns because there were four things.
That brief is what separates a considered layout from a component-library assembly, and it is doctrine rather than a model setting. It does not live in a preferences panel where it can be forgotten. It is part of what the design agent is, every time it runs.
And then it is a real thing
The part people tend not to believe until they see it: what comes out is not a picture of an app. It is reachable. There is no separate publish step to remember, no build-and-deploy dance between "I like this" and "someone else can look at it".
That changes what the design stage is for. A mock you can send someone gets real feedback, because they are reacting to the thing rather than imagining it from a screenshot. Most of the useful corrections I have had on interfaces arrived within a minute of someone actually clicking something.
What it is not
It is not a replacement for a designer. It is a way to get to the argument faster, with something concrete to argue about. The taste still has to come from somewhere, which is why the brief above exists in the first place.
And it is not an excuse to skip the documents. The design pass sits inside the flow, after the requirements and the hostile review, not instead of them. A beautiful screen for the wrong product is still the wrong product.
I have shipped enough interfaces that were technically correct and unpleasant to use to know the difference is not effort, it is whether anyone made a decision. A design that looks like every other design usually means nobody chose anything. That is the failure the brief exists to prevent, and it applies to me as much as to the agent.
André