O4.08.2Reporter feedback loopdesign

Case outcomes must be fed back to the reporter

Aliases: report feedback · case status notification · reporting loop

What it is

The feedback loop on case outcomes decides the long-term health of a reporting system: reporters who receive a "handled or not handled" notice with a reason summary keep reporting; reports dropped into silence teach users "reporting is useless," and genuine reports fall while malicious ones remain. Feedback is not courtesy — it is the fuel a reporting system runs on.

Why it happens

Feedback does three jobs: it sustains reporting motivation (the act was seen), calibrates reporting expectations (what gets accepted), and builds procedural-justice perception. Procedural-justice findings apply directly: acceptance of unfavourable outcomes depends mainly on whether the process felt fair — a reasoned rejection beats an unexplained silence. The engineering constraint comes from safety: telling the reporter "the content was removed" leaks to a malicious reporter that the target was acted on, enabling targeted abuse — so feedback splits into two tiers: outcome notices (accepted / rejected / needs more information) for the reporter, disposition details (what penalty the other party received) for nobody. Temporal structure matters as much: complex cases run for weeks, and staged status (received → under review → closed) sustains trust better than a single terminal message. And feedback cannot be faked: an automated "we take this seriously" followed by silence wounds more than no reply — the notified status must be bound to the real case state.

Where it stops holding

Feedback's ceiling is disposition detail: the penalty content (ban length, strikes) is the sanctioned party's private information, and the reporter's right to know ends at "the platform has taken action." At extreme scale, per-item feedback has a cost: platforms processing millions of reports daily run tiered schemes — instant feedback for clear categories, status tracking for complex ones — giving up "equal granularity for all," never "feedback for some and silence for others." Feedback wording can itself be abused: reason summaries written as template boilerplate lower justice perception rather than raising it — reasons must be specific to the case category.

Applying it

  • Model the report as a state machine: received / under review / closed / needs-info bound to the notification system, notifying on every transition — "submitted and never heard back" is banned.
  • Three levels of feedback content: the outcome (accepted or not), a reason summary (category mismatch, insufficient evidence — specific to the case), and next actions (how to add material, how to appeal).
  • Verification: compare reporter follow-up surveys ("would you report again," "was the process fair") before and after the loop ships; watch genuine report volume net of malicious reports — a working loop shows it rising.

Related

  • Same group: O4.08.1 Proximate reporting entries · O4.08.3 Appeals as the companion of automated decisions
  • Nearby: O4.13.2 Public statistics and external accountability · O4.13.4 Response deadlines
  • Search terms: reporter feedback · case management UX · procedural justice

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/O4.08.2