Flows, Wireframes and First Drafts

Critique is easier than creation

There is a reason designers work in pairs, run crits, and start by sketching six bad versions. Reacting to something is cognitively cheaper than producing something. Put a mediocre flow in front of an experienced designer and objections arrive in seconds. Put a blank artboard in front of the same person and they might spend twenty minutes rearranging their desk.

That is the honest case for AI at this stage of the work. It is not that the tool designs better than you. It is that it removes the blank page in about the time it takes to write the brief, and hands you something specific to be annoyed by.

Set your expectations accordingly. What comes back will be the median solution: the flow that most products in your category already use, described competently. That is disappointing if you wanted invention. It is extremely useful if what you wanted was a baseline to argue with, or a list of everything you forgot.

Work in text, not pictures

The model works in language. So does a flow, once you stop drawing it: a flow is a list of steps, decisions and branches, and that translates into text without losing much.

Layout does not. A wireframe is a spatial argument about what matters most, and spatial reasoning is not what these systems do. You can ask for a described structure and get something sensible, and you can ask for a rough generated screen and get something that looks like an interface. Neither is a judgement about hierarchy, because there is no eye behind it and no opinion about your users.

The other thing to be clear about: it cannot see your interface. If you describe your screen, it is responding to your description, which is already a lossy summary written by the person who is too close to the work. That gap is not fatal, but it means the model's confidence about "your design" is confidence about a paragraph you wrote.

You can narrow the gap, and it is worth the effort. Describe the flow the way you would to a new starter who has never opened the product: every screen in order, every control on each screen and what it does, what the user has to have decided before they arrive, what the system knows about them at that point, and what happens on each path out. It feels tedious and it takes ten minutes. It also produces noticeably sharper output, and it has a useful side effect: about a third of the time, writing the description is when you notice the problem yourself. That is not the tool working. That is the oldest trick in design, explaining the thing out loud, with the model as an audience that does not sigh.

The real win: exhaustiveness

Here is where this stage genuinely pays. Designers do not usually forget the happy path. They forget the fourteenth state.

A model does not get bored, does not get attached to the elegant version of the flow, and does not run out of patience at 4pm on a Thursday. Ask it to enumerate and it will keep going long after you would have stopped. Enumeration is the one thing in design where being a tireless average performer beats being an inspired tired one.

The states worth demanding for every meaningful screen:

That list is not exotic. Every experienced designer knows it. The difference is that a checklist you run every time catches things a memory does not, and the model is very good at running a checklist against a specific flow you describe.

Here is a flow I am designing: [describe it as numbered steps].
For every screen in this flow, list the states I need to design. Include
at minimum: first-use empty, user-emptied, loading, partial load, slow
load, recoverable error, unrecoverable error, offline, permission denied,
overlong content, and stale data.
For each state, tell me in one line what the user needs to know and what
they should be able to do next. Mark any state where you think the
correct answer depends on something I have not told you, and say what
you would need to know.

That last instruction matters more than the rest. A model asked to flag its own missing information will often surface the exact question your product manager has been avoiding.

This is a flow for [product, and who uses it]: [numbered steps].
List the ways a real person could end up somewhere this flow does not
handle. Cover at least: interrupting halfway and returning days later,
using it on a phone with a poor connection, doing it twice by accident,
sharing an account with someone else, having accessibility needs, and
arriving from a deep link rather than the start.
Rank them by how likely they are in ordinary use, not by how interesting
they are.

What you still have to bring

Three things stay entirely yours, and being clear about them keeps the first draft useful rather than seductive.

Which of these states actually matters. An exhaustive list is not a plan. Most of the value in that table comes from four or five states in any given flow, and knowing which four is the job.

The unusual move. If the model's flow feels familiar, that is because it is. Anything that differentiates your product will come from you, from your research, or from a constraint the model does not know about.

Whether the flow should exist. The most valuable design decision is often to delete a step, or to remove the screen entirely by defaulting well. A tool asked to design a flow will design a flow. It will not tell you the flow is unnecessary unless you ask, so ask.