Concepts / Effective Feedback Collection

Effective Feedback Collection

Seamless feedback collection means gathering opinions through a channel built into the user's workflow, so that giving feedback needs no extra work.

  • Programming

Why a Good Question Can Still Lose the Answer

Imagine you have just finished exporting a report in a spreadsheet tool. Before you can close the window, a large dialog box fills the screen and asks you to rate the export feature on a scale of one to ten. You have no interest in rating anything. You want to close the dialog and get back to your day.

What do you think happens?

In this moment, what do you think most users do with the rating dialog, and what happens to the rating they would have given?

  • They answer the rating, because the question is reasonable

  • They click the close button as quickly as they can, and the rating they would have given is lost

  • They are asked again later, so the rating is never lost

Reveal answer
Answer:

Most people in this position click the close button as quickly as they can, and the rating they would have given is lost.

The request for feedback was made, but the way it was made taught the user to resist it. The question itself was not the problem; the placement and the effort it demanded were.

This article looks at the other side of that moment. Feedback is valuable to the people building a product, but collecting it has a cost, and the user pays that cost in attention and time. The question this article answers is how to design a feedback mechanism so that giving feedback is easy and the request does not get in the way of the work the user came to do.

Feedback as Part of the Existing Path

Definition

Seamless feedback collection means gathering opinions through a channel built into the user's workflow, so that giving feedback needs no extra work.

The central idea is that feedback should be treated as something that fits inside the user's existing path, not 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 the user did not plan to do, it is no longer seamless, even if the question it asks is a good one.

Key point

Seamless 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.

Tracing a Request Through the Workflow

To see how the properties work together, follow one feedback request from the moment the user finishes a task. The diagram below traces the possible paths. The request is only one branch of the flow. Most of the flow is the user's own work, and the feedback option is a side path that the user can take or leave.

Task finishedFeedback requestshownAnswer the ratingBack to the workSkip or closePrompt shows againDead end or penaltytask endsuser answersuser dismissesreturns at oncenothing lostskip is not respectedpenalty
After the task ends, the feedback request appears. Answering keeps the user in a short side path that returns to the work. Skipping should also return the user to the work with nothing lost; if it leads to a repeated prompt or a penalty, the mechanism has become intrusive.
  1. 1
    Find the point where the request appears. Is it after the task ends, at a natural pause, or in the middle of a step?
  2. 2
    Ask whether answering requires leaving the work, opening another screen, or filling in a long form.
  3. 3
    Ask whether skipping returns the user to the work at once with nothing lost.
  4. 4
    If both the answer path and the skip path pass, the request is integrated and non-disruptive. If the skip path 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 Four Conditions for Seamless Collection

The four properties to check are integration into the workflow, low effort, non-disruption with easy dismissal, and an incentive for good feedback. Each one can be checked on its own, which makes them useful as a review checklist when evaluating an existing prompt or planning a new one.

  • Integration into the workflow: the request lives in a channel the user already passes through while doing the task.
  • Low effort: answering needs little work, not a long form or a new screen.
  • Non-disruption with easy dismissal: the request does not stop the task, and the user can skip it without cost.
  • Incentive for good feedback: there is a reason to give thoughtful responses.

Why Ease of Ignoring Matters

Ease of ignoring is a requirement, not an optional extra. A request the user can safely skip respects their choice, and this tends to produce more honest responses. When skipping is hard or punished, people either answer without thinking so they can leave, or they click away and the opinion is lost. In both cases the feedback is less useful than it could have been.

Seamless Versus Disruptive Channels

The two channels differ in the extra steps, context switches, and effort they add for the user. A seamless channel asks nothing the user did not already plan to do. A disruptive channel adds a separate errand on top of the task.

Built into the taskSeparate full-screendialogAnswer in placeStops the currenttaskEasy to skipSkip leads to repeator penalty
Each column lists the features that define one kind of channel. The seamless column keeps the user in the task; the disruptive column adds steps and a context switch.

Redesigning a Prompt That Fails

Worked example

Moving a failing prompt into the workflow

A note-taking app shows a full-screen dialog after every save, asking How likely are you to recommend this app on a scale of one to ten, and the dialog must be answered or closed before the user can keep typing. Evaluate it and propose a seamless redesign.

  1. 1
    Trace where it appears

    The request appears right after a save, which is a point the user passes through often, but it blocks the next step of typing, so it interrupts the work.

  2. 2
    Test the effort

    A ten-point scale in a separate dialog asks for a deliberate decision and a context switch the user did not plan to make.

  3. 3
    Confirm that skipping returns the user

    Closing the dialog does return the user to the editor, but the prompt returns after the next save, so the skip is not respected.

  4. 4
    Redesign

    Show a small one-tap rating strip at the bottom of the editor once the save has completed. It needs no form, it does not block typing, and the user can ignore it by continuing to type, which dismisses it with nothing lost.

Result

The redesigned prompt is built into the workflow, asks for little effort, can be dismissed without cost, and sits at a natural pause rather than in the middle of a step.

Save completesFull-screen ratingdialogClose dialogResume typingSave completesInline rating stripKeep typingforceddismissbackshown beside workignored
In the before path, the user must deal with a full-screen dialog to return to typing. In the after path, the rating strip sits beside the work and the user continues without a detour.

Mistakes When Judging a Prompt

  • Common mistake

    Judging a prompt only by its question

    What it looks like

    A well-written question in a full-screen dialog is accepted as good feedback design.

    Why it fails

    Seamless is a property of where and how the request appears, so identical questions can behave very differently.

    Do this instead

    Trace where the request appears and what the user must do to answer or skip it.

  • Common mistake

    Treating a skip button as sufficient

    What it looks like

    A prompt has a close button, but closing it brings back the same prompt on the next action.

    Why it fails

    If skipping leads to a repeated prompt or a penalty, the user has been charged for declining.

    Do this instead

    Check that skipping returns the user to the work at once with nothing lost.

  • Common mistake

    Assuming the feedback option is the whole flow

    Why it fails

    The request is only one branch of the flow; most of the flow is the user's own task.

    Do this instead

    Map the full path, including the work the user came to do, before deciding where feedback fits.

  • Common mistake

    Asking for effort the user did not plan to spend

Checking Your Understanding

MEDIUM

A file-sharing app ends each upload with a required survey page that must be completed before the share link is shown. Trace where the request appears, test the effort, check whether skipping returns the user with nothing lost, and propose a redesign that meets the four conditions.

Hints
  • Start by asking at which step the survey appears relative to the user's goal of getting the share link.
  • Check whether the survey is required, which means skipping is not possible, and what that means for ease of ignoring.
  • A seamless redesign might place a small, optional prompt beside the share link rather than in front of it.

Key Takeaways

  • Seamless feedback collection gathers opinions through a channel built into the user's workflow, so giving feedback needs no extra work.
  • A request is judged by where it appears and what it demands, not only by the question it asks.
  • The four conditions are integration into the workflow, low effort, non-disruption with easy dismissal, and an incentive for good feedback.
  • Ease of ignoring is a requirement: a request the user can safely skip respects their choice and tends to produce more honest responses.
  • To evaluate a prompt, trace where it appears, test the effort it demands, and confirm that skipping returns the user to the work with nothing lost.

Related Topics

More concepts starting with E