Your product is making people wait in the dark

Someone imports a CSV, starts an account review, generates an AI report, or asks support to escalate a billing problem.

Then the product gives them something that looks like a status:

• Importing customers.csv
• Under review
• Estimated ready 14:32
• This has been escalated

And these statuses are often completely true.

It's exactly why these statuses survive for so long, they look harmless and, of course are "correct". And every product has these lying around, and nobody quite owns them and that's because here "done" is "good enough".

But sometimes "good enough" just doesn't quite cut it. Users aren't trying to admire the backend state of your app, they are trying to work out what they can safely do next.

• Should I wait?
• Should I retry?
• Should I contact support?
• Can I close this tab?
• Is this still fresh?
• Has a person seen this?
• Is the product working, stuck, broken, or hoping I stop asking?

The product names the state it's in, but does not explain what that state means for the person that's stuck inside it.

Four ways waiting states go wrong

Importing can be a stale state if it never tells the user whether anything is still happening.

Under review can be an unowned state if no team, source, or checkpoint is attached to it.

Estimated ready 14:32 can be fake precision if the work is variable and queue-based.

This has been escalated can still be a dead end if the user has no idea whether to wait, chase, or try another route.

The annoying thing is that none of these look broken when you first scan the screen, or even when you were initially designing/building it. You did the supporting UI, added the ETA or some copy around it.

But when this is shown to a user who has actually navigated into that state, it's left them with the hard part. They have to work out whether the information/status is fresh, where it came from, how much confidence to put in it, and what happens if nothing changes.

That's the product work needed to be done on this screen.

You have to design the bit between the thing your team knows, the thing your system is doing, and the decision the user has to make while they wait.

A waiting state is part of the workflow

Your product made the wait one of the steps.

Take the import example: once someone starts importing a file, they are not only asking, is this processing?

They are asking, can I close the tab? Is it still doing something? Can I carry on with the rest of my work?

And that's where this becomes a workflow question before it is a copy question.

The same thing happens with an account review. Under review might be technically accurate, but the useful answer is more specific: what is being checked, who or what has it, whether the user needs to do anything, and when the next checkpoint happens.

Once your team treats the waiting state as part of the workflow, the design brief changes.

You're no longer just choosing a nicer label. You need to decide what the user can do next while the system is busy, uncertain, blocked, or waiting on someone else.

That might mean showing the current step, the thing being checked, the last update, the confidence level, the fallback, or the one action the user can still take.

It will not be the same in every product, which is kind of the point.

This is also why a single label can be so misleading.

Under review might mean the account is waiting for an automated check, sitting with a risk team, blocked by missing information, queued for manual review, or already decided but not updated in the UI yet.

Those are very different things that your users probably need to know.

So the useful work starts before the sentence gets written:

• What are the actual states?
• Which ones can the user influence?
• Which ones are internal noise?
• Which ones change the next safe action?

The copy is the visible bit but the design work is deciding which state the user is in, what the product knows about it, and what that means for their next move.

A useful version admits what it knows

If you make every one of these screens sound more certain, you make the problem worse.

If an estimate is rough, say it's rough. If the team is still diagnosing, say that. If the next update depends on a manual review, make that clear. If the system does not know yet, do not dress the unknown up as a neat timestamp.

That is why the AI report example is different from the import example.

The import might need progress and a safe next move.

But the AI report might need a range because pretending it will be ready at exactly 14:32 is fake precision made to look like it's being helpful.

The support escalation might need a fallback, because "we got your message" is only useful if the user knows whether to wait or chase.

You are trying to make the uncertainty usable, not remove it.

You see the same thing outside software.

When the power goes out in your area, the first fix estimate is rarely perfect. Conditions change, reports come in slowly, and the people fixing it might not know the full picture yet.

The useful outage update does not pretend the first estimate is gospel, it says what is known, what is still being checked, and keeps coming back as things get clearer.

Incident pages have the same problem. If the team goes quiet while they diagnose the issue, you cannot tell whether nothing has changed or nobody has come back to update the page.

Airline disruption alerts make it even more obvious. If the app, airport screen, text message, and third-party tracker all say slightly different things, you need to know which one is fresh enough to trust.

Six questions for a useful waiting state

That can sound like a lot of UI but it usually isn't.

This is not a rule that every waiting state needs all six answers, most of the time one missing answer is doing the damage.

• For the import, the missing answer might be: can I close this tab?
• For the account review, it might be: who has this and what checkpoint comes next?
• For the AI task, it might be: how confident is this estimate?
• For the support escalation, it might be: should I chase this or wait?

That's the job of the six questions. They should help you find the missing answer, not turn every status into a little operations essay.

There's no need to make every waiting screen longer, some of your updates should be tiny. If the user only needs to know that a file has uploaded, fine just do that.

But at the moment state becomes uncertain, delayed, dependent on someone else, needs manual review, costs money, carries risk, or is hard to recover from, the screen has to do more work.

It has to give users enough confidence to make the next decision.

Where I would use this first

I would not start by redesigning every status label, start with the places where people get twitchy.

• long-running imports
• approval queues
• onboarding reviews
• support tickets
• failed payments
• delivery updates
• incident banners
• AI tasks that take more than a few seconds
• anything where the user opens the same page twice to see if something changed

Those are moments where a vague state does real damage, because people are wondering whether to trust the product or route around it.

For each one, ask the normal status question:

What state is this in?

Then ask the more useful one:

What does the user need to believe or do because of this state?

That second question changes the work.

Now you are not just naming a backend condition. You are deciding whether the user needs freshness, source, confidence, a next step, or a fallback.

Sometimes the answer is tiny: safe to close this tab.

Sometimes it is a clearer owner: the risk review team has this.

Sometimes it is a more honest estimate: usually 10-30 minutes.

Sometimes it is permission to stop worrying: no need to send another message.

The point is not to make every waiting screen longer.

The point is to stop giving people an accurate state while hiding the useful part.