nothing here. yet.
Empty does not mean broken.
An empty screen is rarely empty of meaning.
In a financial product, a blank table can mean almost anything. Nothing exists. Nothing has happened yet. The data is still loading. A filter has excluded everything. Or, slightly more concerningly, something has gone wrong.
The interface might look identical in every case. The user’s interpretation is completely different.
That is why empty states deserve more attention than the sad little illustration and “no results” message they so often get.
empty does not always mean nothing
The first mistake is treating every empty state as the same problem.
A portfolio with no holdings is very different from a transaction list with no transactions for the selected period.
A new account with no documents is different again.
The interface might look empty in all four situations, but the user needs completely different information.
That means the first question should not be:
What should we put in the empty state?
It should be:
Why is this empty?
Once you know that, the content becomes much easier to design.
tell me what has happened
A useful empty state should explain the situation without making the user work it out.
For example:
“You have no transactions in this period”
That is much more useful than:
“No results found”
The first tells me what the system checked and what it discovered.
The second tells me almost nothing.
There is also an important distinction between nothing exists and nothing is currently visible.
Imagine I filter transactions to “last 7 days” and there are none.
The data exists.
My current view just happens to contain nothing.
That means the best next step might be changing the date range rather than contacting support.
Good empty states help users understand that distinction.
give people somewhere to go
Once the situation is clear, think about whether the user actually needs to do something.
Sometimes they do.
A new client with no documents might need to wait.
Someone with no transactions this month probably does not need to do anything at all.
A user who has filtered everything out may simply need to clear the filters.
That gives us a useful pattern:
Explain the state first, then offer an action only when an action is genuinely useful.
This sounds obvious.
It is surprisingly easy to get wrong.
Interfaces often add buttons because an empty screen feels incomplete.
That is how you end up with things like:
No documents available
[View documents]
Which is a spectaularly impressive way of asking someone to view the thing you just told them does not exist.
empty states can reduce support calls
This is where a small piece of UX copy can have a much bigger effect.
Someone sees an empty transaction list and thinks:
“Have my transactions disappeared?”
That creates anxiety.
They refresh.
They log out.
They try again.
Then they contact support.
But:
There are no transactions for this account in the selected period. Try a wider date range to see more activity.
Suddenly, the interface has answered most of those questions before they happen.
The screen has become part of the support experience.
It is doing a little bit of explanatory work so that somebody else does not have to.
be careful with “nothing”
There is another reason empty states matter in finance.
Words such as “nothing”, “none” and “not available” can feel much more serious than intended.
No investments
could mean:
this person does not have any investments
the data has not loaded
the account contains no investments yet
the wrong account is selected
the user does not have permission to see them
That is a lot of ambiguity for three words.
Sometimes a better approach is to describe the actual state.
No investments are currently held in this account.
That is clearer.
It also avoids accidentally implying that something has gone wrong.
new users need a different kind of empty state
There is a useful opportunity here for onboarding.
A genuinely new account should not feel broken simply because it has not accumulated any information yet.
Instead of presenting a blank transaction table, for example, you can explain what the user can expect to see when activity begins.
Your transaction history will appear here once activity starts.
That feels intentional.
The product is effectively saying:
“You are not missing anything. There just isn’t anything to show yet.”
That little bit of reassurance matters.
do not fill empty space for the sake of it
Designers can be strangely uncomfortable with empty screens.
We start adding illustrations.
Then cards.
Then help links.
Then a “getting started” panel.
Then three related actions.
Before long, the empty state has more content than the actual populated state.
Sometimes an empty state should just be quiet.
If nothing needs to happen, say so clearly and get out of the way.
The absence of information is not necessarily a design problem.
The absence of explanation is.
the empty state should match the user’s question
There is a useful way to review these experiences.
Forget the component for a moment and think about the question the user is likely to have.
For a new portfolio:
When will I start seeing information here?
For a filtered transaction list:
Did I filter this incorrectly?
For an unavailable document:
Is something missing?
For an empty investment account:
Do I actually hold anything here?
Now design the message around answering that question.
This usually produces much better content than starting with a generic component and trying to find something to put inside it.
a useful checklist
When reviewing an empty state, ask:
Do we know why the state is empty?
Does the interface explain that reason clearly?
Could the user mistake an empty state for an error?
Is there a useful next action?
Are we asking the user to do something they do not actually need to do?
Would this answer the obvious support question before it is asked?
Empty states are easy to overlook because there is, quite literally, nothing there.
But that is exactly why they matter.
A full screen gives you plenty of clues about what is happening.
An empty one does not.
So when there is nothing to show, the product needs to communicate a little more, not a little less.
