The reporting entry must appear with the reportable content

What it is

In-context reporting places the reporting route next to reportable content, account, or interaction and preserves enough context to identify it. A harmed person or bystander need not leave the scene, find policy, or reconstruct what happened while still deciding whether it is safe to seek help.

Why it happens

After harm, memory, emotion, and continuing exposure raise action cost. An external form requires links, time, identity, and evidence, leading to abandonment or error. An in-context route pre-fills object and context. Visibility can also invite misclicks or let an abuser infer reporting, requiring protection and confirmation.

Studying it

• Paradigms: compare in-context and external forms on completion, context, and handling accuracy.
• Variables: position, steps, delay, evidence, misreport, handling, and safety.
• Methodological caution: more reports can mean a usable route, not more harm; pair with unreported-harm research.

Where it stops holding

Offline, private, and cross-content harm need a general route, and public buttons must not expose reporters. Urgent risk needs immediate protection outside ordinary forms.

Applying it

• Put low-friction reporting beside content, message, and account; prefill object and allow context.
• State anonymity, audience, urgent route, evidence preservation, and safe exit.
• Prevent target access to reporter identity or reverse identification.
• Verification: walk the path from an affected person’s view, auditing steps, context, misentry, and abandonment.

Related

• Same group: V7.05.2 Reporters need acknowledgement and outcome feedback · V7.05.3 Appeal needs review by someone other than the original decision maker · V7.05.4 Malicious reporting must be constrained · V7.05.5 Misjudgment needs executable remedy, not only reversal
• Nearby: V7.06 Harassment and protection · V7.04 Content governance
• Search terms: in-context reporting · reporting UX · safety reporting