Booking.com

New Content Moderation UI

Role: Product / UX Designer
Timebound: 1 year
Tools: Figma, Maze, Google Forms, remote and in-person usability testing, Documentation, Internal Dashboards
Team: Project Lead, Product Managers, Engineers, Moderators, Associates, Mentors, TLs

Note: Due to confidentiality agreements, specific details about the platform and proprietary design elements cannot be shared.

The messy starting point

"Filters don't do anything until I've processed an item."

Content Integrity Associate

"I can't tell if I'm in accommodation reviews or re-moderation."

Internal Content Moderator

When I joined, the interface was just out of production and was being tested with users.

Three different teams (Internal Moderators, Vendors Moderators and Content Integrity Associates) were struggling with the same screen, each for slightly different reasons.

Nobody could say exactly why things "felt clumsy" and "unnatural"; we just knew the process was breaking over and over and not running smoothly.

Unknowns on day one

Which steps in the flow actually cost time?
Could one UI satisfy three teams with different requirements?
Was the biggest pain cognitive (labels, shortcuts) or mechanical (navigation, queue logic)?

How I turned ambiguity into clear moves

Gray areas

Vague complaints about filters
"The queue mixes everything up"
Shortcuts felt random
Reviewers saved tricky items for later

What I did with it

Tracked sessions and recorded every click with timestamps. Filters only applied after the current item was processed, so I redesigned them to update instantly.
Heat-mapped usage and tagged each item by service. Introduced a colour-coded badge (Moderation / Re-mod / Appeal) visible at a glance.
Grouped hotkeys by mnemonic ("H" for Harassment) and added a cheat sheet beside the item.
Built a one-click "stash" so reviewers could park and batch-process edge cases without losing queue rhythm.

Bumps along the way

The first fix used an internal feature that engineers rejected due to performance issues. We had to redesign it using a simpler method.

Early colour palette failed WCAG. The accessibility team flagged it the day before the demo, so we swapped in the classic internal design system palette.

My first cheat-sheet pop-over covered the moderation item: moderators hated it. Moved it to the sidebar on iteration 2.

Ops worried stashed items would not be picked up later or would be used to avoid complex cases. Added an auto-ping after 12h to force resolution.

Taking the lead

Planned and ran research with ops to turn hypotheses into solutions.
Led a workshop that created four ready-to-build stories the team could deliver without extra costs.
Demoed early prototypes to engineers and the product manager, which freed up sprint time for other fixes.

Impact

What shipped & why it mattered

Real-time filters and colour-coded queues went live the next release. Median review time down 18%.
New shortcut map was adopted and training time for new moderators dropped noticeably.
Post-launch survey: "confidence in decisions" up 0.9 on a 5-point scale.
Ops metrics showed fewer escalations and faster first-response times: exactly what the business cared about.

Reflection

The project reminded me that small interactions build up quickly when repeated thousands of times daily. By focusing on those unclear moments where the tool didn't match real life, we helped the team avoid costly fixes later and gave moderators a console they could trust.

The hardest part was quickly dropping early ideas and keeping the team sure it was worth the effort. But fixing problems early helped us make lasting changes and saved the business from a complete rebuild later.