Report abuse

Problem Context

• Reportable targets can include posts, comments, profiles, accounts, direct messages, group conversations, live chat, ads, listings, repositories, issues, pull requests, discussions, apps, contact links, or search predictions.
• Report reasons may include harassment, bullying, violent threat, hate, self-harm, sexual content, child safety, spam, scam, impersonation, privacy violation, copyright, trademark, illegal content, deceptive behavior, or platform-specific policy violations.
• The reporter may be the target, reporting on behalf of someone else, reporting a public safety issue, reporting while signed out, reporting from a blocked relationship, or reporting content they should not need to view again.
• Submitted reports often feed a review queue or specialist route, while reporters need confirmation, expectation-setting, personal-safety actions, follow-up preferences, and privacy protection.

Selection Rules

• Choose report abuse when a user flags content, behavior, an account, or an object as potentially harmful, abusive, spam, illegal, impersonating, privacy-violating, or against community rules.
• Use a local Report action when object identity matters; preserve target type, permalink or snapshot, author when safe, timestamp, and selected content range or messages.
• Ask for a reason using policy language that users can understand, then collect only the context needed to route the report and protect the reporter.
• Use review queue for the internal moderator worklist after reports are submitted, not for the reporter-facing flow.
• Use comments when users are discussing, resolving, editing, or deleting conversation content; report abuse is a separate safety route from ordinary discussion.
• Use security warning when a system threat verdict blocks unsafe navigation, download, submission, or preview before exposure.
• Use permission denied state when the issue is authorization or access, not harmful behavior.
• Use notification center for report updates and follow-up requests, but deep-link to the report receipt, reported object state, or safety center.
• Offer block, mute, hide, restrict, leave, save evidence, emergency, and legal or privacy-reporting routes as adjacent actions without pretending they are the same as an abuse report.
• Make clear when reporting is anonymous to other users, when reported text may appear in follow-up messages, and when report details may be shared with moderators or legal teams.

Required States

• Report entry point near a post, comment, profile, message, conversation, repository, ad, live chat item, or listing.
• Reported object snapshot with target type, author or account when safe, timestamp, selected messages, permalink, and content summary.
• Reason selection for harassment, spam, impersonation, privacy, legal, child safety, violent threat, self-harm, or other policy categories.
• Affected-person state such as myself, someone else, a group, everyone, community, or organization.
• Additional context or evidence state with limits, sensitive-data guidance, and no public disclosure.
• Multiple-content selection state for adding related posts, comments, or messages to one report.
• Route selection state for platform support, repository maintainers, privacy complaint, legal issue, law enforcement guidance, or emergency help.
• Submit pending, submitted, failed, duplicate, rate-limited, and offline draft states.
• Confirmation state with receipt, expectation-setting, report history or status, and post-report safety actions.
• Post-report content hidden or notice state that lets users avoid re-exposure while preserving access when they choose to view it.
• Follow-up state for more information needed, action taken, no violation found, unresolved, resolved, or report reopened.
• Reporter privacy, signed-out or region-specific reporting, blocked-account reporting, and mobile compact states.

Interaction Contract

• The Report action is reachable from the object being reported and carries object identity into the flow without asking users to manually re-enter obvious context.
• The flow states who or what is being reported before submission and lets users change the target if the wrong item was selected.
• Reason choices route to the correct specialist path and do not collapse urgent safety, privacy, legal, child safety, spam, and harassment into one vague issue.
• Optional context fields explain what helps review and warn users not to include unnecessary secrets, medical data, payment data, or private third-party information.
• Submission failure preserves the draft report, selected reason, and evidence so the reporter can retry without revisiting harmful content.
• Confirmation says the report was received, not that enforcement has already happened, unless an actual moderation action has completed.
• Post-submit safety actions are scoped: block or mute changes what the reporter sees; review queue actions decide platform enforcement; legal or emergency routes are separate.
• Reporter identity and report contents are not exposed to the reported user, public thread, analytics events, screenshots, or unrelated moderators beyond policy need.

Implementation Checklist

• Inventory reportable object types, source surfaces, policy reasons, specialist routes, required evidence, privacy obligations, and status values before adding the entry point.
• Model report target, reporter, affected person, selected reason, selected evidence, context text, route, receipt ID, status, follow-up preference, and post-report safety actions separately from moderator queue state.
• Preserve report drafts through network failure, mobile navigation, offline retry, blocked-account relationships, deleted content, and removed conversations.
• Provide safe post-submit actions such as block, mute, hide, restrict, leave conversation, save a report copy, open safety center, view report history, or contact emergency help.
• Throttle spammy submissions without blocking urgent safety reports behind inaccessible challenges or silent rate limits.
• Audit who can view report details, redact sensitive evidence in logs, and avoid exposing reporter identity or context to the reported user.
• Test post, comment, profile, direct message, group conversation, ad, repository, signed-out, region-specific, duplicate, failed, urgent threat, privacy/legal route, mobile wrapping, keyboard order, and screen reader announcement states.

Common Generated-UI Mistakes

• Treating Report as an instant takedown or ban action.
• Using one unlabelled report button with no reason, target, evidence, confirmation, or status.
• Forcing reporters to keep viewing harmful content to complete, retry, or check a report.
• Mixing block or mute, permission recovery, comments moderation, legal takedown, privacy request, and abuse reporting into one ambiguous flow.
• Revealing reporter identity, report text, private evidence, or moderator notes to the reported user.
• Hiding urgent threat or child safety routes behind ordinary spam categories.
• Dropping failed reports without preserving the selected reason and evidence.

Critique Questions

• What exact object, account, conversation, or content range is being reported?
• Which policy route owns this reason, and does the reporter understand the difference between reporting, blocking, muting, legal requests, and emergency help?
• Can the reporter complete the flow without re-exposure to harmful content?
• What evidence is captured automatically, and what optional context is truly needed?
• How are reporter privacy, follow-up content, report history, and status expectations explained?
• What immediate safety action remains available after submission?
• What happens when the content is deleted, already reported, blocked, unavailable, or the report fails offline?