Feedback is needed not for every button, but for every reasonable uncertainty: whether the system accepted the action, whether the work is ongoing, whether the result is final, and what can be done now.
Do not add a toast or spinner as a ritual. If the result is immediately and unambiguously visible in the object itself, a separate message only duplicates the interface.
First, pin down the transition
Describe in one line only the actually reachable states:
до → намерение принято → ожидание или предварительный результат → подтверждено / не удалось → что сохранилось
If it is unknown which state should occur, a product decision is needed or
edge-hunt, not this skill. Do not invent a mandatory set of emptiness,
loading, and error: design only the states reachable in this transition.
Find the moment of uncertainty
For each transition, check:
- whether the very fact of action acceptance is visible;
- whether silence can provoke a dangerous repeat;
- whether the person distinguishes a preliminary from a final result;
- whether in case of failure it is clear what changed and what was preserved;
- whether the next safe action remains available.
Do not mask unknown behavior with text. If the system itself does not know whether the operation went through, first determine a method of reconciliation or recovery.
Choose the cheapest sufficient signal
| Form | When it fits |
|---|---|
| The result itself | The change is immediately visible and cannot reasonably be read otherwise |
| Local status | The result is invisible or delayed, but relates to one element |
| Area status | The operation changes a list, form, or another integral section |
| Persistent global status | The operation continues after leaving the screen or affects multiple places |
Show the signal where the attention and the consequences of the action are. It should live as long as the uncertainty lives: not disappear before the result and not remain after it no longer communicates anything.
Distinguish the type of result
- Instant and visible: a separate confirmation is usually not needed.
- Deferred: show the accepted intention and do not pass off waiting as success.
- Optimistic: mark it as provisional if a later rollback noticeably changes the meaning or the data.
- Background: the state should be available after leaving the original screen.
- Partial: name the completed and uncompleted parts separately.
- Unsuccessful: report what did not happen, what was preserved and what safe action is available next.
Do not invent a cause of the error and do not promise an automatic retry if the system does not guarantee it. Decide on confirmation, cancellation or admissibility of retry in the behavior model; here check only whether the consequence and recovery are visible.
Check the live transition
Check not a static layout but a sequence over time. For the most risky transitions, reproduce the available variants: delay, failure, retry, leaving the screen and a late result. At each moment ask:
- what the person currently believes happened;
- whether this matches the real state of the system;
- whether the interface will push toward a dangerous retry or leaving before saving;
- whether the person will be able to recover without guessing.
The check should observe the same channel as the person. A successful API test does not confirm that the interface communicated the result; a beautiful toast does not confirm that the data was actually saved.
More details
references/01-heuristics.md— typical gaps between the system state and the person's representationreferences/02-checklist.md— checking by transition types