A global notice area is not suitable for local operation results
Aliases: global notification · local feedback · toast notification · object-level feedback
What it is
Local-result feedback means that when a particular object is added, edited, deleted, sorted, or validated, its outcome first appears on that object and in its direct context, rather than only in a page-wide notice area. Global areas suit cross-scope events, system state, and history. The key evidence of a local operation is whether the object actually changed, what state it is in, and what can happen next. A top-corner “Saved” toast supplies a sentence but not necessarily the result to which it refers.
Why it happens
Local operations require an action–object–outcome loop. State change on the object is verifiable evidence and survives after a notice disappears. A global message is detached: with several consecutive operations, people cannot pair messages with items; when a notice fades, is covered, or sits outside view, the loop breaks. A system can therefore notify correctly while still provoking repeats, doubt about saving, or continued work on the wrong object.
Studying it
Have participants edit, batch-process, or handle similar objects in a list. Compare global toast, object-level state, and both for result location, error discovery, duplicate action, and undo. Observe how people verify the affected item after interruption and after a notice fades. Single-operation success is insufficient: global notices often pass that case yet fail under multiple items, scrolling, and asynchronous completion.
Where it stops holding
Local change does not rule out a global notice. Effects spanning objects, background completion, permission change, and cross-page trace need global presence; limited local space or a vanished object may require a global record and traceable entry. But object-level feedback cannot compress a complex system error into one tiny line. For deletion, use nearby change, undo affordance, or a clear list transition as evidence.
Applying it
- Define visible, persistent, verifiable object-level outcomes for each local command: field value, status badge, list position, error mark, or undo placeholder.
- Use global notices for scope, history, cross-page work, or long tasks, linking to affected objects rather than replacing their change.
- Give each object independent state during consecutive operations; one global “done” must not cover several distinct outcomes.
- Validate with multi-object tasks. After fading, scrolling, or interruption, people should identify what changed, its current state, and how to undo it.