By the end of the lesson, you can design the states of a main task (normal, loading, empty, error, success, and disabled state). You understand that an error message is not a technical log, but content that helps the user's next decision.
Why is the "ideal path" not enough?
The easiest part of design work is when everyone knows their job and everything works. Most real uncertainty, however, arises in non-ideal moments: when the network is slow, the places have run out, wrong data was entered, or the result is empty. If these are not in the design, the developer or the user makes something up, and it will rarely be good. One of the most important jobs of the designer is to think these through in advance.
There is more than the "normal" screen
For every main screen, think through at least the following UI states (the appearance and behavior of the interface at a given moment):
State
When does it occur?
What should it say?
Normal
All data is available
The main information and the main action
Loading
Something is in progress
That the system is working, and (if possible) for how long
Empty
There is no content yet, or the filter gives no results
Why it is empty, and what the next step is
Error
The action did not succeed
What happened, what was kept, what to do
Success
The action succeeded
What was achieved, and what the next step is
Disabled
The action is not available now
Why, and what is needed for it
A merely gray button is not necessarily understandable, especially when the user cannot see which condition is missing.
Loading and waiting
A loading state is an interface state that signals an operation in progress. Waiting causes uncertainty if the user does not know whether something happened, how long to expect, or whether they may try again. For a short wait, immediate visual feedback (for example the loading state of the button) may be enough; for a longer process, the system has to say what it is working on and, where possible, keep the data already entered. Avoid misleading progress: do not show a bar that stops at 90% if there is no real connection to the state of the process.
Empty state
An empty state is a state when there is no content yet, or none can be shown because of filtering. An empty list is not the same as an error. In a new account there may be no bookings yet, or the filtering gives no results. A good empty state names the situation, briefly states the reason, and offers a next step. "You have no saved events yet. Browse today's programs." is much more useful than an empty white area or a "No data" system message.
An error message as help
An error state is the communication of a situation that obstructs or makes uncertain the successful continuation of the task. A good error message answers three questions:
What happened? (understandably, in user language)
What is the consequence? (what was lost, what was kept)
What can the user do now? (a concrete next step)
Example: "Saving failed. Your changes were not lost; try again, or download them as a draft." The text does not have to reveal an internal error code, but if customer service needs it, it can be shown separately, in a copyable form.
In a form, the error should be tied to the field, and preferably also summarized after submission. Do not just write "required field", but name the missing data and the expected format. The error state should remain perceivable without color as well (see the previous lesson).
A useful difference: preventive and corrective error handling. Preventive: the field signals while typing if the format is wrong (but should not signal an error before typing!). Corrective: after submission it says what has to be done differently.
Success and the next step
A success state is a state that shows the result of the action and its possible next steps. The success state closes the current task, but often opens the next. After registering, for example, the user needs to know the date, place, the possibility of changing, and the way of notification. "Success!" by itself does not give enough trust. If the process has delayed processing, do not promise a final result: say that the request has arrived, and when a reply can be expected.
State diagram: searching in Mai program
flowchart TD
A["Start search"] --> B["Loading"]
B --> C{"Response received?"}
C -->|No| D["Error: explanation and retry"]
C -->|Yes| E{"Any results?"}
E -->|No| F["Empty: help to adjust the filters"]
E -->|Yes| G["Results: choosing the next step"]
D --> A
F --> A
The diagram shows that a single search has at least four outcomes, and each has its own interface state. If we draw only the "Results" screen, we leave the other three outcomes to the developer.
Worked example: a search with zero results
In Mai program someone sets the "tonight", "free", and "English-language" filters. "No results" is technically true, but does not help. A good state can show which condition narrows the most ("'Tonight' and 'free' together give 0 results; only 'free' gives 3."), offer the next day or a nearby location, and make the filters resettable with one click. The system does not force another choice, it just helps to understand the current result.
Common misconceptions
Claim
Clarification
"The error page is rare, so there is no need to design it."
In rare but high-consequence errors, clear communication is especially important.
"A spinner is enough loading feedback."
Only if the wait is short and the user knows what will change.
"The success state is decoration."
It can be the key to closing the task and understanding the next step.
"The error message should be as short as possible."
It is good if it says what happened, what the consequence is, and what the user should do; this often takes more words.
In brief
Every main screen has at least six states: normal, loading, empty, error, success, disabled.
An error message answers three questions: what happened, what is the consequence, what should I do.
An empty state is not an error; it names the situation and offers a next step.
The success state closes the task and informs about the consequence.
Review questions
Which states are missing from your current prototype?
Does one of your error messages say what happened, what was kept, and what to do?
How would you help a search with zero results without hiding reality?
What does the user need to know right after a successful action?
Errors, feedback, and states
Objectives
By the end of the lesson, you can design the states of a main task (normal, loading, empty, error, success, and disabled state). You understand that an error message is not a technical log, but content that helps the user's next decision.
Why is the "ideal path" not enough?
The easiest part of design work is when everyone knows their job and everything works. Most real uncertainty, however, arises in non-ideal moments: when the network is slow, the places have run out, wrong data was entered, or the result is empty. If these are not in the design, the developer or the user makes something up, and it will rarely be good. One of the most important jobs of the designer is to think these through in advance.
There is more than the "normal" screen
For every main screen, think through at least the following UI states (the appearance and behavior of the interface at a given moment):
A merely gray button is not necessarily understandable, especially when the user cannot see which condition is missing.
Loading and waiting
A loading state is an interface state that signals an operation in progress. Waiting causes uncertainty if the user does not know whether something happened, how long to expect, or whether they may try again. For a short wait, immediate visual feedback (for example the loading state of the button) may be enough; for a longer process, the system has to say what it is working on and, where possible, keep the data already entered. Avoid misleading progress: do not show a bar that stops at 90% if there is no real connection to the state of the process.
Empty state
An empty state is a state when there is no content yet, or none can be shown because of filtering. An empty list is not the same as an error. In a new account there may be no bookings yet, or the filtering gives no results. A good empty state names the situation, briefly states the reason, and offers a next step. "You have no saved events yet. Browse today's programs." is much more useful than an empty white area or a "No data" system message.
An error message as help
An error state is the communication of a situation that obstructs or makes uncertain the successful continuation of the task. A good error message answers three questions:
Example: "Saving failed. Your changes were not lost; try again, or download them as a draft." The text does not have to reveal an internal error code, but if customer service needs it, it can be shown separately, in a copyable form.
In a form, the error should be tied to the field, and preferably also summarized after submission. Do not just write "required field", but name the missing data and the expected format. The error state should remain perceivable without color as well (see the previous lesson).
A useful difference: preventive and corrective error handling. Preventive: the field signals while typing if the format is wrong (but should not signal an error before typing!). Corrective: after submission it says what has to be done differently.
Success and the next step
A success state is a state that shows the result of the action and its possible next steps. The success state closes the current task, but often opens the next. After registering, for example, the user needs to know the date, place, the possibility of changing, and the way of notification. "Success!" by itself does not give enough trust. If the process has delayed processing, do not promise a final result: say that the request has arrived, and when a reply can be expected.
State diagram: searching in Mai program
flowchart TD A["Start search"] --> B["Loading"] B --> C{"Response received?"} C -->|No| D["Error: explanation and retry"] C -->|Yes| E{"Any results?"} E -->|No| F["Empty: help to adjust the filters"] E -->|Yes| G["Results: choosing the next step"] D --> A F --> AThe diagram shows that a single search has at least four outcomes, and each has its own interface state. If we draw only the "Results" screen, we leave the other three outcomes to the developer.
Worked example: a search with zero results
In Mai program someone sets the "tonight", "free", and "English-language" filters. "No results" is technically true, but does not help. A good state can show which condition narrows the most ("'Tonight' and 'free' together give 0 results; only 'free' gives 3."), offer the next day or a nearby location, and make the filters resettable with one click. The system does not force another choice, it just helps to understand the current result.
Common misconceptions
In brief
Review questions