Loading screens, error messages, confirmation dialogs — the liminal spaces of a product shape how it feels more than the features do
https://idominikos.com/articles/liminal-spaces-in-ux
I want to write about something that's been bugging me for a while, and once you see it you can't unsee it: we obsess over the primary interactions of our products — the dashboard, the editor, the checkout — and completely forget the spaces between them. The loading screens. The error messages. The confirmation dialogs. The three seconds where a page decides whether it wants to exist or not.
Design borrows a nice word for these from architecture: liminal spaces. Corridors, elevators, waiting rooms — places you pass through on your way to somewhere else. Nobody designs their product's corridors. That's the problem, because your users spend a surprising amount of their day standing in them.
Why nobody is happy in a CRM #
Think about email clients and CRMs. They work. Mail gets sent, deals get logged. And yet nobody is happy in them — these tools are emotionally welded to effort, friction and burnout. Why? It's not the core feature. It's the accumulated weight of a hundred tiny in-between moments: the spinner that tells you nothing, the "Something went wrong" that treats you like you did something wrong, the dialog interrupting you for the 40th time today to ask a question it should already know the answer to. Transitional moments either alleviate those feelings or exacerbate them. There is no neutral.
My favorite example is from the physical world (a classic industry story — I honestly don't know if it happened exactly like this, but it's too good): office buildings kept getting complaints about slow elevators. The engineering fix — faster elevators — cost a fortune. The design fix? Mirrors next to the elevators. Complaints dropped, elevators untouched. Nobody made the wait shorter; they made it feel shorter. Liminal design in one sentence.
What an in-between moment can carry #
Now the fun part. Some of these moments can be reimagined to actually carry something:
- Value — a loading screen with a genuinely useful tip about the thing you're about to do, not "did you know Ctrl+S exists"
- Delight — a small, calm animation that gives the product a pulse (small! calm! not a circus)
- Education — an empty state that teaches instead of announcing "No items yet" into the void
- Accomplishment — "you cleared 23 emails, inbox done for today" instead of dumping you back into the list
- Calm — an error message that takes the blame, explains in human words what happened, and gives you a way out
And here's the trap, and I'll be honest because I've fallen into it myself: the answer is not to decorate every spinner with confetti. That's adding for the sake of adding, and users smell it instantly. The real work is asking three questions for every in-between moment: where is the user emotionally right now, where are they coming from, and where are they about to land? A payment confirmation and a "your export is ready" live in completely different emotional universes. Everything is important, but nothing is important in the same way.
Map your corridors #
The practical idea — I've started doing this myself and it's humbling: map these states in your app. Literally list them — every loading state, error, dialog, redirect, wait. Prepare to be shocked by how many there are. Then for each one decide: improve it, rethink it from scratch, or kill it. Most just need honesty — tell the user what's happening and how long it takes. A few are golden opportunities hiding in plain sight.
Anyway, this connects to everything I believe about software: the product should adapt to the human's state, not the other way around. The in-between moments are exactly where a product shows whether it respects your state or ignores it.
If you run the exercise and find something interesting, hit me — I collect these.
topics covered
related reading
- Your vibe-coded database is a mess (mine was too)articlesSchema drift is the tax of AI-assisted coding — why it happens to every vibe-coded project, and the tool I built to squash it1 shared tag(s): product
- Our matching is not machine learning, on purposearticlesA rule matrix across fifty-odd lifestyle factors, chosen over a trained recommender — because a housing match you cannot explain is a housing match nobody should act on1 shared tag(s): product