Booking.com
Content Moderation UI
TL;DR
Moderators were slogging through a tool that hid context and slowed decisions. By rebuilding filters, queues and shortcuts, we cut process friction and boosted speed + confidence. It wasn’t a straight line—one prototype failed in usability testing and user’s oriented solutions were refused by product teams —but the end result stuck.
Redesigning the user interface of Booking.com's Content Moderation tool
Timebound: 6 months
Role: Lead Product and UX Designer
Team: Product Managers, Engineers, Moderators, Associates, Coaches, TLs
Tools: Figma, Google Forms, Video Interviews, Documentation, Internal Dashboards
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.”
“I can’t tell if I’m in accommodation reviews or re-moderation.”
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)?
Grey areas
Vague complaints about filters
“The queue mixes everything up”
How I turned the grey areas into clear moves
What I did with it
Tracked sessions and recorded every click with timestamps.
Noticed filters applied only after processing the current item.
Redesigned filters to update instantly - without need to process current item.
Heat-mapped usage and tagged each item by service.
Introduced a color-coded badge (Moderation / Re-mod / Appeal) visible at a glance.
Shortcuts felt random
Grouped hotkeys by mnemonic (“H” → Harassment) and added a cheat-sheet beside the item.
Reviewers saved tricky items for later
Built a one-click “stash” so they could park and batch-process edge cases without losing queue rhythm.
Bump along the way
The first fix used am internal feature that engineers rejected due to performance issues. We had to redesign it using a simpler method.
Early color palette failed WCAG; accessibility team flagged it day before demo—scrambled to swap palette with 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 gut feelings into clear goals.
Led a workshop that created four ready-to-build stories the team could deliver without extra costs.
Demoed early prototypes to engineers and product manager, freeing up time during the sprint to focus on other fixes.
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.