Spaarks CRM — content moderation tool

Spaarks is a hyperlocal social network — 100K+ downloads, 50K+ active users, 4.0 stars on Play Store. You post a "Spaark" to share an update, ask for help, find a job, sell something. Posts are visible to your local area without follow relationships, which makes discovery effortless and abuse easier in equal measure.

The CRM (Content Moderation Tool) was the first internal tool ever shipped for Spaarks. A single workspace for the moderation team to triage reported content, decide on violations, and process user appeals — keeping the community safe without breaking the trust that brought people in.

ML models were already doing the easy work — filtering posts before they went live for the obvious categories. But the network was scaling faster than the model's confidence. The model said "this might be a scam, I'm 62% sure" hundreds of times a day, and there was no human in the loop to make the call.

Three things were broken at once: when the ML flagged something, no moderator workflow existed to review it. When a moderator made the wrong call, the user had no way to push back. And when a moderator made any call, no record was kept of who decided what — so we couldn't audit accuracy or correct unfair outcomes.

The design question: build a workspace that gives moderators the right context to decide quickly, gives users a fair path to appeal, and gives the company an audit trail — without any of the three slowing the others down.

Most of the upfront research was done before I joined — PRDs, the violation taxonomy (scams, fraud, nudity, self-injury, false information, among others), and the shape of the ML model's output. My job started at ideation: turn the research into wireframes, flows, and an information architecture that moderators would actually want to use.

I worked closely with the founder and one other designer. Daily critique loops, hi-fi prototypes after week one, and usability tests with the actual moderation staff who would live in the tool. The insight that mattered most: moderators don't decide alone, they decide in conversation. The tool had to support that, not fight it.

I owned the design end-to-end: ideation → wireframes → IA → high-fidelity UI → interactive prototypes → usability testing. The founder and a second designer reviewed daily; engineering took the prototype straight to build.

Title said "Designer" but the scope ran wider. I wrote the moderator-facing copy (every status, every error, every confirm dialog), defined the violation-chip taxonomy, and shaped the appeal flow alongside legal and community-safety leads. The thing I learned: internal tools live or die on the wording, not the layout.

Every page in the CRM opens with the same content-summary header at the top — type of content, original author, timestamp, the moderator's notes. Moderators move between Reports → Appeals → Review without losing context. We picked this shared spine over per-page custom headers because moderators told us, in usability tests, that "finding myself on the page" was the friction they wanted gone.

1. 01

   Reports — the daily queue

   Surfaces every flagged Spaark with the ML category, user-report count, and content type at a glance. Moderator reads the post on the left, the report details on the right, and decides: pass or violation. We considered a single-pane Inbox layout; picked the two-column because moderators read the post first, then read the report — never the reverse.

2. 02

   Appeals — when the user pushes back

   When a moderator marks a violation, the user can appeal. The case lands here with the user's comment alongside the original report details. The moderator reviews both sides and either accepts the appeal (post stays) or rejects it (permanent violation). Designed the appeal entry as a fixed two-section panel so the user's side can't be missed in scroll.

3. 03

   Review — the second pair of eyes

   An optional layer where super-moderators audit other moderators' decisions. Same two-section spine plus the original moderator's ID and timestamp. We added this page in week three, after a usability session where two moderators independently reached opposite conclusions on the same Spaark. The Review page made disagreement a feature, not a failure.