<aside> ⚠️ Content note: online harassment, exploitation of minors, real world harm.

</aside>

For 6 years, Discord users could not report abuse directly from the app.

In 6 weeks, we fixed that.

Screenshot care of Brett Johnson

Making reporting accessible to humans

Once upon a time, this was how you reported abuse on Discord:

1. Google how to do it
2. Fill out a web form
3. Copy and paste the message permalink (wait, what?)
4. Find the original message to get the permalink — if it wasn’t deleted (and you could stand to look at it again, ugh)
5. Go back to the form and paste the permalink (okay, almost there)
6. Submit the form (SUCCESS!)
7. Then, do it all over again for (wait)
8. Every (no)
9. Single (please)
10. Message (AARRGGHHHH)

Suffice to say, it wasn’t ideal.

This wasn’t just a usability problem — it put us out of step with industry patterns and international law. Change was overdue.

hoo boy

gotta be an easier way to do this

Meeting conflicting needs

The top need was for reporting to be easy (for users) while remaining accurate (for agents).

We needed to make reporting accessible, but we also needed to accommodate the constraints of the size of our small (though quite mighty) Trust and Safety team.

However, what users think of as “abuse” and what T&S agents take action on are worlds apart.

User needs

The reasons to report vary, and boil down to the user’s intent. Non-exclusive examples:

• Report violations: ”I saw something bad [and Discord doesn’t allow it].”
• Express frustration: “I’m upset [even if it’s not an actionable offense].”
• Call for help: ”Something life-threatening is happening right the fuck now.”

Business needs

The ability to respond to a report is constrained by severity and available resources.

• Keep inbound reports at same or lower volume — more reports means more work and slower response time
• Reports must be accurate so agents can triage them appropriately, serving the most critical needs first

In the moments after being exposed to something that make them upset, a user doesn’t necessarily want to bother with accuracy. But that is critical information required by T&S to respond to it.

Guiding users to the right place

Never use a user flow where a spreadsheet will do. — my stubborn ass

The in-app flow needed to bring users to the end of the flow quickly, without thinking too hard, and mapping to users’ mental model rather than how T&S would categorize reports.

Bad stuff is bad, but we must know if it’s, like, BAD bad.

This was a “choose your own adventure” path with the goal being the shortest journey possible taking them from “Report” to “Submit.” I built in multiple avenues to arrive to keep users moving forward in the flow, so they wouldn’t get stuck.

We also added suggestions for blocking and contacting emergency services in categories where we anticipated users would be best served by those options.