Designing Feedback Mechanisms

Designing an AI application does not end when the model produces an output. A second design question is how the application should learn what users actually want. This article focuses on two parts of that question: when a system should collect feedback from users, and how a comparison between outputs can turn a user's choice into a useful training signal.

The example makes a point that the rest of this article builds on. Feedback is valuable to the people building a product, but collecting it has a cost paid by the user, in attention and time. The source frames the problem as more than whether to gather feedback. It is also a question of when and how to do it. A system that asks at every step would be tiresome, while a system that never asks would miss chances to learn. The goal is to find the moments where asking is worth it and to ask in a way that does not get in the way of the work.

The purpose of asking is stated directly in the source: the feedback helps increase the model's confidence about what to do. The user's answer resolves the ambiguity that the model could not resolve on its own. This means a feedback request is a response to a specific gap in the model's knowledge, not a general request for opinions. A system that asks a user about everything is not making a targeted decision about uncertainty at all.

The branching logic is the heart of this idea. When the model is confident about which action the user wants, it can act directly. When it cannot tell which of several actions the user wants, the feedback path becomes the reasonable choice. The flowchart below traces both branches and shows what changes once the user responds.

Read the diagram as a statement about purpose. The feedback branch exists to resolve a specific uncertainty, so a request that appears when the model is already confident is asking for something the system does not need. The request is justified by the gap, and the gap is what should trigger it.

When a model cannot tell which of several actions a user wants, one option is to output candidates side by side and let the user choose. This is why side-by-side presentation matters in feedback design. Showing two candidate outputs turns an open-ended question into a simple choice. The user is no longer asked to judge a single output on an abstract scale. They are asked to pick between two concrete options.

The choice itself is the signal. The source describes the user's choice between two outputs as a comparative signal. A rating of one output tells the system how that output scored in isolation, which depends heavily on the user's mood and the scale they happen to use. A pairwise choice tells the system which of two options this user preferred right now, which is a more direct record of preference.

The source states that comparative signals such as the user's choice between two outputs can be used for preference finetuning. The idea is that the system accumulates the choices users make and uses them to adjust the model so that it moves toward the kind of output users pick. Each recorded choice is a small piece of evidence about what people prefer, and finetuning is the step that uses that evidence to change the model.

The path from interface to model has three stages. First, the interface presents two candidates. Second, the user's choice is recorded as a comparison between them. Third, those recorded comparisons are used in finetuning. The source names a production example of this comparative evaluation, but it does not describe that example in detail, so the specific pipeline used in any real product should be checked against that product's own documentation rather than assumed from this overview.

Asking is a design choice with conditions, not a default. Two conditions follow directly from the source. The first is that the model must face a real uncertainty about which action the user wants. The second is that the request must not impose a cost the user is unwilling to pay. Latency is the most concrete form of that cost. Every moment the system waits for a response is a moment the user is not getting the result they came for.

Latency enters the design in two places. Generating two candidates instead of one may add to how long the user waits, and that is the assumption the source asks designers to check. Waiting for the user's own answer also takes time. Asking is reasonable when the value of resolving the uncertainty outweighs the delay it introduces. When the uncertainty is small, or when the delay would be noticed and resented, the better choice is usually to act without asking.

The central idea is that feedback should fit inside the user's existing path, not be treated as a separate errand added on top of it. A user who is already doing a task should be able to offer an opinion about that task without leaving it, opening another screen, or filling in a long form. If the mechanism asks for work that the user did not plan to do, it is no longer seamless, even if the question it asks is a good one.

The source makes a further point. Seamlessness is a property of where and how the request appears, not only of what it asks. Two identical questions can produce very different results depending on whether they arrive at a natural pause in the work or interrupt a step in the middle of it. Placement and timing matter as much as wording.

To judge whether a request interrupts the work, follow it step by step. The source traces one feedback request from the moment the user finishes a task. Most of the flow is the user's own work, and the feedback option is a side path the user can take or leave. The sequence below shows the order of events for the spreadsheet example, with the skip branch included.

Read each branch as a question. Does answering require leaving the work? Does skipping return the user to the work at once, with nothing lost? If both branches pass those checks, the request is integrated and non-disruptive. If the skip branch leads to a dead end, a repeated prompt, or a penalty, the mechanism has moved from seamless to intrusive, even though the feedback option looks harmless on the surface.

The source names four conditions that a well-designed feedback mechanism should meet. Each can be checked on its own, which makes them useful as a review checklist when evaluating an existing prompt or planning a new one.

Ease of ignoring deserves special attention. A request the user can safely skip respects their choice, and the source notes that it tends to produce more honest responses. A user who feels trapped tends to answer carelessly or not at all, which makes the feedback less useful even when a response is recorded.