When the screen remains silent after an action, people don’t stop working—they start repeating, refreshing, and checking.
Concept of the week · Feedback is a Promise
Fast feedback isn’t polish. It’s the moment your system either keeps its word—or pushes uncertainty onto the user. Under pressure, delayed feedback turns into extra steps: re-entry, double-checking, interrupted thought, and “did it save?” scanning.
So we treat feedback as a contract: acknowledge critical actions immediately and make state changes visible before users feel the need to repeat.
We worked on redesigning the user interface (UI) for a vital signs spot-check monitor for general ward rounds—built for semi-automated measurements and manual entries, such as counting respiration rate by observation. In the legacy software architecture, there was a several-second delay between a manual entry and the main UI reflecting it. That lag created a familiar loop: enter → pause → return → re-check → sometimes re-enter, because the system didn’t visibly register the action. The cost wasn’t just frustration; it also included waiting time, interruptions, and reconciliation work later (“Which number is real?”).
In the proposed new version, the scope of improvement went beyond the visual layer: interaction design and software architecture were considered part of a single end-to-end workflow. In simulation, nurses responded positively because the UI made the system’s “I got it” indication visible immediately—even when the backend still needed time to finalize. However, the architectural change couldn’t be implemented at that time due to the effort involved and potential side effects.
Lesson learned: when responsiveness protects safety and flow, it’s never “just performance”—it’s a non-negotiable product requirement.
In a flight booking checkout, the same gap appears when “Pay now” shows no clear progress or confirmation: people click again, refresh, switch tabs, and then spend time untangling duplicate charges and email receipts.
The Doherty Threshold assigns a number to this: aim to keep feedback within ~400 milliseconds to preserve flow and prevent repeated actions.
One thing to remember: Every delayed state change creates hidden work—retries, extra checks, and later cleanup—because users must manufacture certainty when the system doesn’t.
How teams ship this: Measure the time from user action → visible confirmation at the UI. Track it as p50, p75, p95, and max, and fail the build if p95 exceeds the agreed latency budget for any critical action. Treat this like availability—non-negotiable, not a nice-to-have.
Asset
Asset: Feedback Promise Playbook
A simple recipe for design + engineering—especially for high-stakes data entry where repeats create risk.
Inventory the actions · action list
List the critical actions (enter, save, submit/commit, acknowledge, delete, pay) and the exact on-screen confirmation users expect.Classify the risk · risk map
Tag each action as reversible vs. irreversible, and rate the risk (low/medium/high).Define the promise · requirements
For each action, specify: what confirms within 400 ms, what “pending” looks like (clearly not “saved”), and what “done” looks like (one unambiguous confirmation).Design repeat-safety + recovery · safeguards
Prevent duplicates (disable control, idempotency key, backend dedupe) and define recovery (undo/cancel/retry with status + audit trail).Prove it stays true · evidence
Enforce a p95 budget for action → visible confirmation, validate it in realistic simulation, and log action IDs, timestamps, and outcomes so regressions show up immediately.
Definition of done: users can’t create duplicates by repeating, and they can always tell “pending vs saved” at a glance.
Resource: Doherty and Thadhani’s IBM technical report, The Economic Value of Rapid Response Time (1982), shows—using transaction-rate data—that productivity rises sharply as system response time drops into the sub-second range. It’s a primary-source anchor for treating fast feedback as a workflow requirement, not UI polish.
Light wisdom & reflection
“When a computer and its users interact at a pace that ensures that neither has to wait on the other, productivity soars.”
If feedback is a promise, where in your workflow do people start repeating themselves because the system stays silent, and what would it take to keep that promise immediately?
Mindful practice
Think of a recent person-to-person moment where you weren’t sure you were understood (a text, a meeting, a handoff). What tiny signal would have reduced your uncertainty—one sentence, a nod, a repeat-back, a timestamped “got it”?
Where could you offer that signal to someone else today, before they feel the need to repeat themselves? Next time you notice a pause after you speak, notice how quickly your body starts preparing for a second attempt.
Best,
Andreas Walden
Share this with someone designing for clarity.