Ask for a screen and you get the screen on its best day. Full of content, nothing loading, nothing failed, permission already granted, network fine. The product as it appears in a case study rather than as it appears on a Tuesday.
This gets described as a limitation of the model. I think it's more specific than that, and the specificity is useful.
It learned from portfolios
Nearly every image of an interface that exists publicly is a marketing image. Screens on landing pages, screens in case studies, screens in design galleries — all of them curated, all of them full, all of them at their best.
Almost nobody publishes the empty state. Nobody puts the error screen in their portfolio. So a model asked for "a booking screen" produces the version it has seen ten thousand times, which is the version where everything went right.
It isn't failing. It's returning exactly what it was shown. The gap isn't in its capability, it's in what the world bothered to photograph.
Screen count is the number that misleads everyone
On a booking product: 68 functions, 44 in the MVP, seven flows, 28 main screens.
Twenty-eight sounds like a small project. The real artboard count came out several times higher, because a screen isn't finished until it has states — loading, empty, error, permission, offline, whatever this particular product can actually do to a user.
That multiplier is where estimates die. A team quotes 28 screens, generates 28 screens, feels ahead of schedule, and then spends the back half of the project discovering that each one has three or four siblings nobody counted. Same work, discovered late, at the worst possible moment.
States are product decisions wearing visual clothes
This is the part I'd argue hardest for.
An empty state isn't a screen with the content removed. It's an answer to: this person has nothing here yet — is that because they're new, because they filtered everything out, or because something failed? Three different situations, three different messages, three different actions, and only one of them is "add your first item".
An error state isn't a red box. It's a decision about whether the user can recover, whether they lose what they typed, whether it's their fault, and whether telling them the technical reason helps or frightens them.
A model can generate any of these convincingly. It cannot decide which situation you're actually in, because that information was never in the brief — and it will not stop to ask. It will pick the most common one and render it beautifully.
So the states get named before generation, not after
Every screen carries its required states as part of the screen list, decided when you still remember why the screen exists.
Doing it afterwards has a specific failure mode I've watched several times: the states get added as visual variants of a finished screen, so they inherit its layout, and you end up with an empty state that has a filter bar controlling nothing and a table header above no rows. It's technically an empty state. It's nonsense as a piece of product.
Deciding first also surfaces the questions that should have been asked in the brief. Half the states nobody wrote down are the ones where the answer is genuinely unknown, and that's exactly the conversation worth having early.
The same applies to components
A component that appeared once in one screen will be modelled in one state, because that's the evidence available.
But an input has focus, filled, disabled, error, read-only. A button has pressed, disabled, loading. A checkbox has an indeterminate state that will absolutely appear the moment someone builds a bulk-select. If the library only carries what happened to show up on a screen, the missing states get improvised later by whoever hits them first — usually a developer, usually under time pressure, usually differently in three places.
So the rule I use: you don't have to build every component archetype, but the ones you do build carry their full state matrix, whether or not a screen has demanded it yet.
Why this is worth the effort
Because states are where the product actually meets its user. Nobody's experience of a product is the marketing screenshot. It's the day the search returned nothing, the day the payment failed, the day they opened it on a train.
The polished screens are the ones that get shown. The states are the ones that get used.
What this doesn't solve
You can over-specify this. I've built full state coverage for screens that turned out to be cut from the product, which is expensive work thrown away — and worse, it makes the state list feel like bureaucracy to everyone who watched it happen.
There's also no clean rule for how far to go. Offline behaviour matters enormously for a field tool and barely at all for an internal dashboard, and the only way I know to tell the difference is to have thought properly about who's using it and where. Which puts you back at the beginning of the process, which is usually where the real answer is.
The whole thing, recorded on one real project
I recorded the full path end to end — brief, structure and flows, generated screens, locked token system, Figma with real components and variables, clickable prototype, developer handoff — on a single project, breakages included:
Claude AI UI/UX: Complete Workflow from Brief to Figma — the same path on one real project, brief through to a Figma handoff.
If you've got a state that's bitten you that most lists leave out, I'd like to know which one. Mine was permission.
Top comments (0)