Early in our careers, we're primed to design for a demo. The demo where you show your idea to stakeholders, or where you show your craft on X or Dribbble. We optimize for a peak static moment, the one where someone instinctively praises the work: a beautiful screenshot at 1x retina, an interaction crafted to be watched.
There's a second pull, quieter than the first. When we're not designing for a demo, we design the only way we know how — ourselves. We design for our tastes, our idea of good and accessible.
We default to ourselves.
These two forces decide what we build, and they aren't a balanced pair. The demo is supposed to be the check on the default: the place where someone else catches the frame you couldn't see. But the demo is staffed from the same default it's meant to correct. When everyone in the room shares a blind spot, no one flags it. The demo doesn't catch the default. It ratifies it.
The gap between the frames we design and the ones we don't isn't a lack of empathy for the people who aren't like us. The gap is that we think and design fragmented states and screens, not systems.
The failures live in the frames we never consciously designed. Here are four.
The disappearing label
A placeholder doing the job of a label. It vanishes the moment you start typing. The screen reader treats it as a hint, not the name of the field. The form was designed empty and never mid-use, so nobody saw the label leave.
When we design the empty form and never the filled one, we miss how the thing works as a unit. The placeholder reads as a name to us, because we can see it. It stops being a name the second a user does the one thing the form is for.
There are instances where a disappearing label earns its place, like a search input above a table. The user is already in a focused data view, it's the only input there, and the label and the input's purpose are clear.
The empty state that's actually empty
A blank panel, or a flat "No data," as the first thing a new user ever sees. The team designed the full state — the dashboard with the charts, the table with the rows — and forgot that everyone starts at zero.
Skeleton screens that lie
Shimmer placeholders that don't match the layout that actually loads. The page wobbles when the real content loads because the skeleton promised one shape and delivered another.
A skeleton pattern is a promise about what's coming. Switch the shape on the user and you've broken the promise. The interface lied, and you shipped the lie.
Toasts that vanish before you can act
Feedback designed as a visual flourish instead of a functional message. It appears, it's pretty, it's gone. Brutal for a slow reader, for a motor-impaired user reaching for the action, for anyone who glanced away at the wrong second.
So what do these four have in common? It's not that the designer didn't care.
It's that the designer didn't understand what to design for, outside of their own lived experiences, and focused only on the happy paths for demo purposes. If you don't design the focus state, there's a good chance the product ships without one. If you don't include the unhappy paths in the demo, there's a good chance they get cut or de-emphasized when the team is deciding what to prioritize next sprint. I don't expect every state to show up in the demo. I do expect them raised at least once, and consciously mentioned.
The first four frames are design elements: Figma frames, screens, states you didn't consider.
The colour failure isn't that. The red/green error state with nothing else behind it was drawn; the designer made every frame and still shipped it. The first four are a designer who didn't look at a state. This one is a designer looking, and still not seeing it.
You can't enumerate the input you've never been. We are our own default, and if your input is a user without colour-vision deficiencies, you exclude everyone with one — unconsciously.
You can't expand your way out of a partial default. Reading widely, travelling, sitting with cultures that aren't yours broadens what you know. It doesn't hand you the input you'd have to live in a different body to hold. The default stays partial.
Knowing you can't read your way out of your default forces a discipline, one that only sharpens by consciously involving and co-designing with users unlike you. It pushes you to invite a diverse set of stakeholders and designers into your critique sessions.
Put the user in the room…but the room is the whole problem. The people who'd diversify the default — the ones carrying the input the team is missing — were filtered out upstream, long before the demo. Oga-driven design is the purest case of it: one person's default, ratified by a room that exists to agree with them.
The right people aren't in the room because the structure removed them. In many markets, the disability that gives you the missing input is the same disability that costs you the seat. So "put the user in the room" is working against a structure built to keep them out.