Reporting must be simple enough to use mid-match

What it is

The reporting entry's usability decides the reporting system's actual coverage: at the moment disruption happens mid-match (AFK, abuse, griefing), the navigation cost of the report flow (open menu, multi-level navigation, fill a form) means most reports either get postponed to after the match (key details forgotten) or never happen (cost exceeds will). In-match quick reporting—launched from the player list, done in two or three inputs, never leaving the current view—syncs reporting with the observation moment and maximises report-data collection.

Why it happens

Flow friction hits completion rates negatively and exponentially: every added step cuts completion significantly. In-match friction is even costlier—the player is also playing (the match continues), and any flow requiring leaving operation for more than seconds gets abandoned (nobody opens three menu layers mid-firefight). Quick reporting's key design move is compressing the decision into category selection: long-press Tab to open the roster → pick the target player → choose a preset category (AFK / abuse / cheating / griefing) → done, with no keyboard entry or text description required (a form channel remains for detailed descriptions). Preset category granularity must align with backend processing (categories route directly to handling pipelines): too coarse (a single "report" button) leaves the backend unable to triage, too fine (ten subcategories) overloads the in-match decision. Quick reporting also feeds automated detection: high-frequency reported accounts get priority review, and report data trains the detection systems.

Where it stops holding

Quick reporting's simplification is not quality abandonment—preset categories cover the main disruption types, while complex cases' descriptions (detailed accounts, evidence) need a supplementary channel; the post-match detailed form takes that role, the two channels dividing "in-match captures the moment, post-match gives depth." Quick reporting's abuse surface needs guarding: in-match convenience lowers malicious reporting's cost too (retaliatory and coordinated reporting), so report weighting (lower weight for low-credibility accounts, historical accuracy affecting weight) and abuse detection (one player's high-frequency reporting pattern against the same target) are companion mechanisms. The entry's visibility versus misclick balance matters: too hidden (deep in the roster) gets no use, too prominent (an always-on button) invites misclicks—the common in-match solution is summon-style (the roster must be actively opened to report). The flow's interruption cost also needs measuring: the view switch of opening the roster is itself risky in intense fights, so summon-select-return should complete within two seconds.

Applying it

• Implement roster-summon quick reporting in matches: open roster, pick player, choose category, confirm—four steps, never blocking the match view beyond three seconds.
• Align report categories with backend pipelines (each category with a clear handling path and latency promise), and offer an optional detailed post-match supplement form.
• Verification: measure report trigger rates against observed disruption events (share of matches with observed AFK/abuse that produced a report) plus quick-report completion and abandonment rates. Low trigger rates mean entry or flow friction remains; abandonment clustering on one step marks that step as the design problem.

Related

• Same group: W9.05.2 Blocking takes effect client-side instantly, not after review · W9.05.3 Report outcomes need feedback the reporter can perceive · W9.05.4 Punishment must scale with severity and repeat offences
• Nearby: W9.04 Disruptive behaviour · O1.03 Harassment and safety design
• Search terms: in-game reporting · report system design · player moderation · toxicity reporting