Responsiveness
How the interface should react to what people do — optimistic updates, loading states, feedback, and undo — so the Fortiv experience feels instant and trustworthy.
Principles
Responsiveness is about how the system reacts, not how things move (that is Animation). The system responds to people instantly and reconciles with the server quietly in the background.
The user never waits to see their own change
When someone renames a process or checks off a recovery step, the result appears immediately — before the server confirms. The network is slow and unpredictable; the user's intent is not.
The server confirms; it does not gate
The happy path is overwhelmingly common: the save succeeds. Design for that. Don't make every successful user pay the latency tax of waiting for permission that almost always comes.
The change is the feedback
When an action visibly does what the user expected, that is the confirmation. Don't stack a success toast on a change the user can already see — it trains people to ignore notifications.
Confidence over confirmation
Prefer designs that let people move fast and recover, over designs that interrupt to ask “are you sure?”. Reserve confirmation for the genuinely irreversible; everywhere else, prefer undo.
The responsiveness spectrum
Reversibility and risk decide how much the system trusts the user up front. Default to the top of the table — most BCMS interactions are edits to data the user owns and can change again.
| Action type | Examples | Strategy | Feels like |
|---|---|---|---|
| Cheap & reversible | Rename, toggle, check off a step, reorder, reassign | Optimistic — apply instantly, reconcile in background | Instant |
| Creating something | Add a process, add a row, post a comment | Optimistic insert — show immediately in a pending style | Instant, with a brief settle |
| Consequential but recoverable | Archive a plan, remove a dependency, bulk status change | Optimistic + undo — apply instantly, offer undo | Instant, with a safety net |
| Slow or heavy | Generate a report, run a simulation, import a file | Pending state — acknowledge, show progress, stay unblocked | Acknowledged, not blocking |
| Destructive & irreversible | Permanently delete, submit a BIA, finalize a review | Confirm first — a deliberate moment of friction | Considered |
Loading states: nothing > skeleton > spinner
The order of preference when the data isn't here yet. Never show a spinner on an action the user initiated themselves — that action should be optimistic.
| Situation | Treatment |
|---|---|
| User edited their own data | No loading state — optimistic update |
| First load of a list, table, or detail | Skeleton matching the content shape |
| Navigating to a previously-seen view | Keep prior content, swap when ready |
| Slow async job (report, simulation) | Inline progress + keep the user unblocked |
| Unknown-shape, unavoidable wait | Small contained spinner — never full-screen |
Feedback patterns
Match the feedback to where the user's attention is and whether the result is in or out of context.
| Result | Pattern |
|---|---|
| Successful in-context change | Silent — the visible change is the feedback |
| Success the user can't see (background job, async save elsewhere) | Toast |
| Field / form validation error | Inline, next to the field |
| Failed optimistic mutation | Quiet revert + toast explaining what happened |
| Destructive action completed | Toast with Undo |
In-flight affordances
While an action is settling, communicate intent without breaking the layout.
Show intent without layout shift
A button that triggered an action can show it's working, but must not change size or jump. Swap a label for a same-footprint spinner, or dim-and-disable in place.
Optimistic inserts and removes
Show a new item immediately in a subtly pending style, then settle on confirmation. Animate a removed item out on the user's action; if the server rejects, animate it back in and toast.
Disable, don't disappear
If an action is temporarily unavailable while something settles, disable the control in place. A control that vanishes and reappears is more disorienting than one that briefly dims.
Review checklist
Common responsiveness issues and their fixes. Use this when reviewing interaction code.
| Before | After | Why |
|---|---|---|
| Spinner on user's own save / edit | Optimistic update, no spinner | The user should never wait to see their own change |
| Blank screen while next view loads | Keep prior content, swap when ready | A view that never goes blank feels instant |
| Full-screen spinner on first load | Skeleton matching content shape | Skeletons set expectations and prevent layout shift |
| Success toast on a visible change | Silent — the change is the feedback | Redundant toasts train people to ignore them |
| Confirm modal on archive / remove | Act immediately + Undo toast | Undo beats confirm for recoverable actions |
| No handling for failed mutation | Quiet revert + explanatory toast | Optimistic UI must handle the rare failure deliberately |
| Form error in a top-level banner | Inline next to the field | Put the error where the fix happens |
| Button resizes / jumps while loading | Dim-and-disable in place, reserve space | In-flight states must not shift layout |
| Item appears only after server confirms | Optimistic insert in pending style | Show creation instantly, settle on confirm |
| Control disappears while unavailable | Disable in place | Vanishing controls are more disorienting than dimmed ones |
Use this as a Claude skill
This page is also a Claude Code skill. The same guidance you read here is what the agent applies when it writes or reviews code — so the product stays consistent with what is documented.