Booking.com
Localization Routing UI
TL;DR
Problem: Routing rules lived in a database, so every tweak meant opening an engineering ticket.
My move: Designed a self-service interface with drag-and-drop logic, real-time validation, and a clear job dashboard.
Impact: Operations teams now edit rules without dev help; translation requests move faster and satisfaction scores rose in post-launch surveys.
Design of Booking.com's Localization Team Routing UI
Timebound: 6 months
Role: Product / UX Designer
Tools: Figma, Miro, Whiteboard
Note: Due to confidentiality agreements, specific details about the platform and proprietary design elements cannot be shared.
Where we were guessing
We knew localization project managers (LPMs) were stuck waiting on developers.
Unknowns on day one:
Which decisions needed daily edits, and which could stay hard-coded?
How much “technical” language could LPMs comfortably use?
How do we create a logic dashboard for such a complex system?
Gray areas
LPMs kept side-spreadsheets to track job status
Ops Slack was full of “quick rule-change” pings
From issues to solutions
What I did with it
Built a live dashboard: colour-coded streams, SLA heat-map, and sortable queues
Designed a step-by-step rule wizard that let LPMs add, edit, and test routing logic
Non-technical users feared “breaking the tool”
Added real-time validation + drag-and-drop canvas that flagged conflicts inline
Bumps along the way
Localization of long language names broke grid; swapped to language codes with tooltip to ensure clarity.
Wizard needed instant rollback, but backend had no transactions. Collaborated with engineers to add a “draft” mode that saves data in a separate table until users hit Publish.
The first validation was direct and red; pilot teams felt criticized. We softened the tone and used inline tips instead of pop-ups.
Leading through the process
Deep-dive week on routing UIs: I mapped patterns from workflow engines (HubSpot, Marketo, Salesforce, Zapier) to understand how they work, then distilled the findings into three design rules we referenced all project long.
Ran a daily 15-minute huddle with engineering and PM so any rule-builder blockers were surfaced and fixed quickly.
Shadowed two localization managers during a live rollout; their on-the-spot feedback fed straight into the next sprint’s backlog.
Impact
What shipped & why it matters
Self-service rule builder replaced developer built scripts: ops edits went from 3-day ticket to same-day change.
Visual dashboard lets LPMs spot stuck jobs early, cutting follow-up pings to dev by half.
Scalable templates handle new clients without extra code: engineering confirmed zero regressions after launch.
Reflection
LPMs didn’t want more control - they wanted safe control. By giving clear feedback, hiding risky actions behind confirmations, and adding escape options (like a break-inheritance toggle), non-technical users could work quickly without fear of mistakes.
The main challenge was bridging two worlds. At the first tech kickoff, engineers talked in technical terms like "regex" and "null-safe strings," while I was still figuring out user flows. Realizing I wasn’t fully understanding the side effects, I involved the PM in every design-dev meeting. Their clear explanations kept decisions focused on user needs, not just coding.
Giving operations a tool they can adjust without a developer’s help frees engineers for other problems and keeps localization moving. Small wins, but with big impact over time.