Interaction Feedback

Concept of the skill

Interaction feedback is the discipline of designing the observable signals a UI gives back to a user across the entire lifetime of an action or system state change. Every action that is not instantaneous travels through a sequence of states — idle, pending, partial, success, failure, retrying, cancelled, undoable — and feedback design decides, for each state, what the user sees, where they see it, how long it persists, and what control they keep. It is settled by four decisions: the expected duration class of the action (instant, short, medium, long, background, or unknown), the surface that carries the signal (inline state, button state, skeleton, banner, toast, progress row, modal, or job history), the transitions the user can observe along with the recovery affordances they retain (cancel, retry, undo, leave-and-return), and how honest the UI is about uncertainty — whether it shows a result optimistically before the system confirms it, and what happens when that optimism turns out to be wrong. Feedback is the user's proof that the system heard them, and it is a distinct concern from performance: a fast system still owes confirmation, and a slow system still owes staged, truthful communication about what is happening.

Coverage

Design feedback states for user actions and system changes. Covers immediate click feedback, loading indicators, skeletons, optimistic UI, pending and disabled states, progress, success confirmation, persistent errors, retry, undo, autosave, long-running jobs, empty and low-data states, and perceived-latency staging.

The full lifecycle of a non-instant action is the unit of work. The states to account for are: idle (nothing started), pending (acknowledged, in flight), partial (some of a multi-item action completed), success (confirmed done), failure (errored, recoverable or not), retrying (a recovery attempt in flight), cancelled (user-aborted), and undoable (completed but reversible for a window). Each state maps to a surface and a control set.

Duration classes drive the surface choice. Instant (<100ms) needs only the result. Short (100ms-1s) needs an immediate acknowledgement (button/inline state). Medium (1-5s) needs a determinate or indeterminate indicator with a skeleton for content regions. Long (>5s) needs progress, the ability to background the work, or a leave-and-return path with a job history. Background work needs an unobtrusive status surface plus a notification on completion. Unknown duration must be treated as long until proven otherwise.

Optimistic UI shows the expected result before the server confirms it, which removes perceived latency — but it is a debt: it must define rollback behavior (revert the UI on rejection) and conflict behavior (what wins when the optimistic state and the server state disagree). An optimistic update with no defined rollback is a UI that lies.

Philosophy of the skill

Feedback is the user's proof that the system heard them. Without it, users repeat actions, abandon flows, or assume data was lost. Good feedback is honest about uncertainty and gives recovery paths when the system cannot complete the action.