Design the Edges First

Open any product team's design file and you can predict the layout: the happy path lovingly rendered across a dozen polished frames, and somewhere off to the side, if you are lucky, a single frame labeled "error state, TBD." The demo flows are cinema. The edges are an afterthought.

Then the product ships, and users spend a shocking amount of their actual time at those edges. The first-run screen before any data exists. The search that returns nothing. The sync that fails on hotel wifi. The table rendering a customer name that is 74 characters long because the real world does not respect your mockup data. Products are judged at the edges, because the edges are where the user is confused, frustrated, or new, which is precisely when trust is won or lost.

A few years into enforcing a studio rule about this, I can report it works: we design the edges first.

Why edges first, not last

The obvious argument is coverage: do the hard screens while energy and budget exist, rather than in the exhausted final sprint. But the deeper reason is that edge cases are design critics. They interrogate your concept.

An empty state forces the question "how does a user understand this feature before it has ever done anything for them?" If you cannot design a good answer, the feature's mental model is probably broken, and better to learn that in week two than after launch. An error state forces "what does the user do next?" and if the honest answer is "nothing, they are stuck," you have found an architecture problem wearing a UI costume. Loading states force you to confront how slow things really are, which has more than once sent us back to engineering with a performance conversation instead of a spinner.

When we redesigned onboarding flows with Aperture last fall, the empty-state work did exactly this. Designing the "no projects yet" screen revealed that the product's core object was unexplainable in one sentence, which turned into a naming and information architecture fix that improved every screen after it. The edge diagnosed the center.

The edge inventory we run

Every feature we ship gets walked through the same checklist before the happy path is considered done.

• Empty: first run, zero results, cleared data. Is there guidance, an action, and a reason to believe?
• Error: failed, forbidden, offline, expired. Does the user know what happened, whose fault it was, and what to do next?
• Loading: instant, brief, long. Do we show structure while waiting? Is there a point where we apologize?
• Extremes: the 74-character name, the 4,000-row table, the account with one item, the right-to-left locale, the 320-pixel viewport.
• Interruption: what happens when the user leaves mid-task and returns tomorrow?

None of this is exotic. What is rare is doing it first, with the same craft budget as the hero screens.

The AI product wrinkle

Edge design matters double in AI-native products, because the system itself is now probabilistic. The model will sometimes be wrong, slow, or uncertain, and those are not error states in the classic sense. They are normal operating conditions that need designed behavior: how confidence is communicated, how a user corrects the system, what a graceful "I am not sure" looks like in your product's voice. Teams that treat model fallibility as an exception to hide ship products that feel dishonest. Teams that design it as a first-class state ship products that feel trustworthy even when they miss.

That is the whole thesis, really. Anyone can make the sunny-day demo beautiful, and lately, anything can. The scarce craft is deciding how a product behaves when things are absent, broken, slow, or strange, because that behavior is the product's character. Design the edges first. The center will thank you.