Save, submit, and publish feedback

A save can finish in 150 ms, where acknowledgement is enough. A submit can include validation and a network round trip. Publish, upload, and payment often last several seconds. Each duration needs its own interface language. Instant work benefits from a brief press response and state swap; short waits need a button that clearly enters progress; long waits need progress, permission to leave, or a clear place where the result will appear. One generic spinner flattens important differences.

Motion duration should follow system facts. A button press can settle in 80–140 ms so input and response feel connected; when the request begins, switch the label to Saving or Publishing. Once work finishes, success usually needs only 600–1200 ms for confirmation before the interface returns to useful work. Waiting is a matter of rhythm: people need one continuous causal chain rather than a series of unrelated effects.

After someone clicks Save, attention remains near the editor footer, the end of a form, or the toolbar. Resolve success there first: change the button to Saved, add a short adjacent status, and return the field boundary to a settled color. A global toast can add context, such as All changes synced, yet should not be the only confirmation. The farther feedback sits from the action, the more people must search for what just happened.

In-place feedback also makes failure easier to understand. A network error can restore the button while keeping Retry nearby; field validation can return focus to the exact input instead of sending someone to the top of the page; a failed publish should retain the draft and expose the reason. Continuity matters more than spectacle: one object moving from available to working to resolved lets people see the system handling their request. A crossfade, slight opacity change, and stable layout are enough to carry that meaning.

A feedback flow never has only a success path. People may click repeatedly, hit a timeout, lose permission during submission, or recover from offline work. Each case needs a predictable landing place in the UI. Disable duplicate submission on the primary action while keeping a path to cancel or return; do not silently restore a button after a timeout—explain whether work may still be running; surface a permission change so people do not assume content was published. Listing these edge states in the design makes a consistent state machine much easier to build.

Reversible actions deserve their own treatment. Delete, archive, and cancel invite can leave a list first, then expose Undo near the original location. The exit can have a short motion, while a stable placeholder or count change prevents the list from collapsing so abruptly that people doubt what they clicked. Final removal happens after the undo window. This gives people a way back while keeping the list’s spatial relationship clear.

After publishing, interfaces often stop at Success and leave people on a page with no obvious next move. A complete design shows what follows: open the published page, copy the link, continue editing, check review status, or return to the content list. Motion can shift attention from the Publish button to that next action: reveal a result card in the same region, then make Copy link available. Keep the sequence short and the destination close so people can continue without reorienting.

This is why a real product moment is more useful than a lone atomic animation. A publish success moment often includes press feedback, button state, progress, a result card, and a next action; they share one rhythm and hierarchy. Start with a Pack to see the full state flow, then return to press feedback, crossfade, and duration to tune local details. That is more reliable than assembling a few attractive animations from scratch. Motion serves trust here: people can understand it and continue.

Every flow benefits from a state table: what idle, working, complete, failed, and undoable show; which controls are available; where focus sits; and whether leaving the page is allowed. Motion attaches to state transitions rather than replacing state itself. This keeps product, design, and engineering discussing the same thing and lets tests check whether success, failure, retry, and undo truly work. Data state is the fact; animation simply makes the fact easier to see.

The contract also needs reduced motion. The default path can give a button slight scale and fade in a result card; the low-motion path keeps the same Saving and Saved copy, disabled button, and next action while shortening or removing decorative travel. Whether people use keyboard, touch, or a system reduced-motion preference, the core feedback chain should remain complete. Treat this as a pre-release check and motion becomes part of product reliability.