Six stages, one login flow

Most people use AI to generate screens. That’s the least useful thing it does. Here’s where I actually put it in the design process — and what it caught in a flow I thought was finished.

A designer asks an AI to “design a login screen” and gets a login screen. Centered card, two fields, a button, maybe a “Forgot password?” link in the right weight of grey. It looks fine. It is completely useless.

It’s useless because a login screen isn’t the hard part. The hard part is the fourteen other things that have to exist around it — the locked account, the expired reset link, the OTP that never arrived, the four hundred milliseconds after someone hits Submit where nothing has visibly happened. Those don’t show up in a generated screen, and they don’t show up in most Figma files either. They show up in QA.

The value isn’t in generating the design. It’s in having a second reader at every stage who never gets bored of asking “and then what?”

So I stopped asking for output and started using it as a checkpoint — six of them, mapped onto a process I was already running. Below is each stage, what to actually ask for, and the same worked example running through all six: a login flow. Simple enough that you already know how it works. Which is exactly why it’s a good test.

01 Read the problem statement

Find what the ticket doesn’t say

Every ticket is written by someone who already knows the answer to three questions they didn’t write down. Your job at this stage isn’t to solve anything — it’s to surface those three questions before you’ve drawn something that assumes the wrong answer.

So don’t ask for a solution. Paste the ticket or PRD in and ask for a restatement plus a gap list. The restatement tells you whether you and the ticket agree on the problem. The gap list is the actual deliverable.

On the login flow

“Users must be able to log in” is not a problem statement. It’s a feature name. The questions hiding under it:

• Is this a new identity system, or does it sit on top of one that already exists?
• How many methods — email, phone, social, enterprise SSO? Because if SSO exists, the entire screen architecture changes and you can’t put a password field on the first screen.
• What happens to a locked account, and who unlocks it — the user, a timer, or support?
• How long is a session, and does “Remember me” mean a longer session or a stored identifier?
• Are we willing to tell someone an account doesn’t exist? That’s a security decision that a designer will otherwise make by accident in error copy.

None of those are design questions yet. All of them will become design questions in about two hours. This is the stage where you take them to your PM, in one message, instead of five times over a week.

Prompt

Here’s the ticket. Restate the problem in one sentence. Then list every decision this ticket implies but doesn’t specify — flag which ones are product decisions, which are security decisions, and which are mine to make. Don’t propose a solution yet.

02 Think of a solution

Ask for options with the trade-off named

The failure mode here is asking “what should I do” and getting a confident answer. A confident answer is worse than no answer, because you’ll adopt it without knowing what you gave up.

Ask for two or three approaches, each with the thing it costs. Then you pick — and more importantly, you can defend the pick in review, which is most of what senior design work actually is.

Notice the third row. Choosing OTP doesn’t remove complexity, it relocates it — from “forgot password” to “didn’t get the code.” That’s the kind of thing that’s obvious in a table and invisible in a conversation.

Prompt

Give me three approaches to this. For each: what it’s good at, what it costs, and what has to be true for it to be the right call. Argue against your own favourite. No recommendation until I ask.

03 User Flows

Don’t ask it to draw the flow. Ask it to read yours.

This is the stage where the whole thing pays for itself, and it’s the one most people use backwards.

A generated flow is a guess about your product. Your flow is the truth about your product. So draw it yourself — and then hand it over to be checked, because a flow is a graph, and graphs have properties you can verify. Every node should have a way in and a way out. Every decision should have every branch drawn. Two parallel flows in the same product should be complete to the same depth.

I did exactly this with a login flow I’d built in FigJam — two boards, email/password and phone/OTP, maybe sixty nodes between them.

I thought it was done. Here’s what came back.

Six of those seven are things a reviewer would have caught in handoff, three days later, in front of four people. One of them — the asymmetry — probably wouldn’t have been caught until someone in support asked why nobody could get back into their account.

Prompt

Read this flow as a graph, not as a picture. List: nodes with no exit, decisions where a branch is missing, connectors that imply a policy decision nobody has written down, and anywhere two parallel paths in this same flow are complete to different depths. Don’t redraw it — just tell me what’s broken.

04 Wireframes

Wireframe from the flow, not from a reference

The rule that makes this stage work: if a state exists in the flow and not in the wireframe, that’s a missing screen. Not a nice-to-have. A missing screen. It has a place in the graph, so someone will reach it.

So don’t ask for a layout. Ask for the state list per screen first, then lay out against it.

Eight states, two fields. That ratio is the actual lesson of this article. It doesn’t get better on harder screens — it gets worse.

05 High fidelity

Point it at your design system, not at the internet

Left alone, an AI will produce a beautiful login screen in a design language that is nobody’s. The fix is boring and total: give it your system as the only source of visual truth. I keep a CLAUDE.md that points at our design language system, so component names, tokens, and spacing come from the library rather than from taste.

One rule holds the whole thing together: if a component doesn’t exist in the system, that’s a system gap — not permission to invent one. The output of a missing component is a conversation with whoever owns the library, not a one-off in your file. Every one-off you make is a divergence someone will have to reconcile later, usually you.

Prompt

Build this using only components, tokens, and spacing from our design system. If something I’ve asked for doesn’t exist in the library, stop and tell me — don’t approximate it. Flag anywhere the documented spec and the live component disagree.

06 Grill the design

Get asked the review questions before the review

This is the step I’d keep if I had to drop the other five. Before handoff, I have the design interrogated the way a sceptical engineer would — one question at a time, until it runs out of questions.

Stage four gave me eight states. Grilling is what happens when someone asks what each of them actually does. Three from the login screen, none of which I had drawn:

• Three failures, one error component. Wrong password, account locked and server unreachable all landed in the same inline error slot. One is the user’s fault and retryable, one is their fault and not retryable, one isn’t their fault at all. A single error style tells someone to try again in all three cases — and in two of them that’s wrong.
• Autofill breaks the submit button. The design enabled Submit on typing. A password manager fills both fields without a keystroke, so the button sits disabled over two full fields. It’s the most common login bug in shipped products, and it falls straight out of defining the enabled state as “user has typed” instead of “fields have values.”
• The locked state had no screen. I’d drawn the lockout branch, so it existed in the flow. Nobody had asked what the form looks like while locked — fields still editable? countdown or just a message? does Submit still submit? “Locked” was a node, not a design.

Three items on the simplest screen in any product, and that’s the trimmed list.

The honest limitation: it also raises things already settled — a session length your PM decided in a call, a lockout duration that’s a backend constant. You have to be willing to say “handled, drop it.” Though if a decision exists nowhere except in a conversation someone remembers, it isn’t handled. It’s just not written down.

Prompt

Interrogate these screens for handoff, one question at a time. For every state: what triggers it, what the user can do from it, and how they get out. Assume autofill, keyboard-only, and a slow network. Tell me what’s missing, not what’s good.

07 Prototype

Build it from the same components, so it behaves like the product

A click-through prototype is a slideshow with hotspots. It proves the screens connect. It cannot show you the thing that most often goes wrong, which is time.

So the last step is a real prototype, built in code from the same design system components — not a new artefact, just the high-fidelity design made operable. And because it’s real, it exposes what a linked prototype hides:

• The gap between clicking Submit and anything happening. On a linked prototype that’s instant. In the product it’s four hundred milliseconds where a user who sees no feedback clicks again.
• How an error arrives — does the layout shift when the message appears, pushing the button out from under the cursor?
• Whether the resend timer actually counts down, and what the button looks like during the cooldown.
• What the keyboard does. Tab order, Enter to submit, Escape to dismiss. Nobody catches broken tab order by looking at a frame.

This is also the artefact that ends debates. “Slow it down a bit” is an opinion. A prototype where everyone watches the same transition twice is a decision.

What this actually changes?

Not speed. I want to be precise about that, because “10x faster designer” is the claim everyone makes and it isn’t the one I’d defend. Stages one, two and three take me longer now, because I’m answering questions I used to skip.

What changes is coverage. The number worth tracking isn’t hours saved — it’s how many states exist in the handoff that wouldn’t have existed otherwise. For that login flow it was seven flow-level defects, one of which was a security decision I’d made without noticing, and one of which was an entire missing recovery path. Not one of those was a design skill problem. They were all attention problems, which is exactly the kind of problem a tireless second reader is good at.

A generated screen saves you an hour. A caught dead end saves you a sprint.

If you take one thing from this: stop asking for output. Draw the flow yourself, then hand it over and ask what’s broken. That single move — stage three, ten minutes — has caught more real problems for me than every generated screen combined.

Note: The examples here are generalised from enterprise product work. Flow node names are from a login flow built specifically as a teaching example — simple enough to follow, complete enough to break in realistic ways.

Six stages, one login flow was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.