Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Feedback

Pattern

A reusable solution you can apply to your work.

Context

This is a tactical pattern within UX. Every time a user takes an action (clicks a button, submits a form, runs a command), they need to know what happened. Did it work? Is it still processing? Did something go wrong? Feedback is the system’s side of the conversation. Without it, users are left guessing, and guessing leads to frustration, repeated actions, and lost trust.

In agentic coding workflows, feedback operates at two levels. The software you build must give feedback to its end users. And the agent’s own output (its responses, progress indicators, and error reports) is feedback to you, the developer directing the work.

Problem

A user performs an action and nothing visibly changes. Did the system receive the input? Is it processing? Did it fail silently? Without feedback, every interaction becomes an act of faith. Users double-click buttons, resubmit forms, or abandon workflows entirely, not because the system is broken but because it failed to communicate.

Forces

  • Immediate feedback is best, but some operations take time.
  • Too much feedback (constant popups, verbose logging) is as bad as too little.
  • Errors need to be communicated clearly without alarming or confusing the user.
  • Different contexts demand different feedback: a loading spinner works on a web page but not in a CLI.

Solution

Ensure that every user action produces a visible, timely response. This response should answer three questions: What happened? Was it successful? What should I do next?

For fast operations, provide immediate confirmation: a visual state change, a success message, an updated display. For slow operations, provide progress indicators (spinners, progress bars, or status messages) that confirm the system is working. For errors, provide messages that describe what went wrong in human terms and suggest a concrete next step.

The tone of feedback matters. “Error: ECONNREFUSED 127.0.0.1:5432” is feedback for a developer reading logs. “Could not connect to the database. Check that PostgreSQL is running and try again.” is feedback for a person trying to get something done.

In agent-directed development, build feedback into your applications from the start. When asking an agent to implement a feature, include feedback requirements: “Show a loading indicator while the data loads. Display an error message with a retry button if the request fails. Confirm successful saves with a brief toast notification.”

How It Plays Out

A web form submits successfully but gives no indication that anything happened. Users click the submit button again, creating duplicate records. Adding a simple “Saved successfully” message and disabling the button during submission eliminates the problem entirely.

A developer asks an agent to build a deployment script. The first version runs silently for two minutes and then prints “Done.” The developer cannot tell if it is stuck or working. After revision, the script prints each step as it executes: “Building artifacts… Uploading to S3… Invalidating CDN cache… Deployment complete in 47s.” Same result, vastly better experience.

Tip

For CLI tools, follow the “rule of silence” thoughtfully: be quiet on success for scripted usage, but offer a --verbose flag for interactive use. When an operation takes more than a second or two, always show progress, even if it’s just a spinner.

Example Prompt

“The deploy script runs silently for two minutes. Add progress output that prints each step as it executes: building, uploading, invalidating cache. Show the total elapsed time at the end.”

Consequences

Good feedback builds user confidence. People trust systems that communicate clearly, tolerate delays when they can see progress, and recover from errors when they understand what went wrong. Feedback also cuts support load: users who understand the system’s state don’t file tickets asking what happened.

The cost is design and implementation effort. Feedback has to be designed for each context (success, failure, loading, partial success), and it has to be maintained as the system evolves. Stale feedback is worse than no feedback at all. A progress bar that lies, or a success message for a failed operation, actively erodes trust.

  • Refines: UX — feedback is a core component of user experience quality.
  • Complements: Affordance — affordance tells users what they can do; feedback tells them what they did.
  • Enables: Rollback — good feedback about failures makes it clear when a rollback is needed.