eBay
One support experience three countries could launch at once, and every other market could inherit.
eBay’s Online Customer Support portal looked years older than the marketplace around it, and it had to serve localized sites across the globe. This was the first project where I owned the UX, and I loved the puzzle of it: 3 countries, 3 different sets of functionality actually available to build with, and one design approach that had to hold all of them. I led the redesign (wireframes, visual design, and developer specs) for a simultaneous US / UK / Germany launch built to scale to eBay’s entire global footprint.
the modular contact kit, blocks a market keeps or drops
Every country gets its own portal.
eBay ran localized sites across the globe, each with its own functionality, regulations, and support needs. The immediate mandate was a coordinated launch across three markets at once, US, UK, Germany. The harder, easy-to-underestimate mandate: whatever we built had to scale to sites that weren’t yet in scope but would inherit the framework.
Flex across genuinely different functionality and legal constraints, without a custom rebuild each time.
Pull the portal into the same clean, modern era as the rest of eBay.
What was I actually assuming here?
We went in with two working beliefs, each mapped straight onto a launch KPI. The assumption buried underneath them turned out to be the real risk.
Customers with ready, obvious access to self-service tools will use them to resolve their own inquiries. ↑ self-service use
A cleaner design reduces the mis-clicks, landing in the wrong area, that send frustrated customers straight to a call. ↓ calls to support
Before a single screen: a global site inventory.
Working with each market’s Product Manager, we catalogued the features and support flows across eBay’s global sites and laid them side by side, an OCS Global Site Matrix recording each site’s current and intended state, its contact channels, its help-page layout, and its KPIs.
How might we design one support experience that three countries can launch on at once, and every other eBay site can adopt later, without designing it three times?
the Topic / Contact-options pattern, every issue, same structure
The choice that made everything else possible.
The default move is to design end-to-end flows. But flows are brittle across markets, Germany needs a step the US doesn’t. A regulatory requirement in one country blows up a fixed flow in the next.
So I designed a kit of modular pieces , components that could be assembled and removed without breaking the UI. Each country’s team could compose its own portal from the same shared system. Support topics resolved into a consistent Topic / Contact-options pattern. The contact panel’s blocks (Call us, We’ll call you, Chat, Email) were discrete, included or omitted per market.
Why did self-service go first?
Before committing, I explored 3 landing layouts, and self-service first was one of the options on the table. I chose the one that made the whole bet legible: listing the common problems directly, front and center, is what pulls people into self-service and away from the phone. The others either split the user’s attention or buried the very thing we wanted them to reach for.
Common problems listed directly, front and center, the shortest path off the phone.
A promo band competed with self-service for the same attention. Split focus.
Leading with search pushed the common problems below the fold, the opposite of the bet.
The redesigned help landing, and the payoff.
The base page put the whole bet on self-service: a center “What can we help you with?” panel listing the common problems directly, browse-help down the left, and “Contact us” pulled to a quieter right rail with an always-on Emma agent absorbing questions before they became calls. Then the real proof of the modular thesis, in one screen: the exact same base page, localized for France , same layout, same structure, same quiet contact rail. Nothing was rebuilt. The framework simply localized. That’s what “design it once, adopt it everywhere” actually looks like.
the redesigned help landing, US · English
the same page, localized, France · Français (nothing rebuilt)
Self-service first, with channels that recede, not break.
Any issue, “Didn’t receive an item” or “Buying on Half.com”, slotted into the same recognizable two-tab structure. The help landing page put self-service first, with an always-on automated agent absorbing questions before they became calls.
a market without phone support, channels recede in place
Recede, don’t break.
Modularity became a named track in the program: a Framework workstream for the reusable base, and a separate “graying out channels” workstream for exactly the case where a market didn’t offer a channel. Rather than delete the block and reflow everything around it, the channel grays out in place, and containers were specified to scale to their contents, so the same component holds more or less per market.
Overlays layer on top of the flow.
Interactions that a fixed flow would bury became overlays that layer on top of the base page: an item-retraction picker, and a “Call us” panel with live estimated wait time and a one-time PIN, down to an IP-Relay path for customers who are deaf, hard of hearing, or speech-impaired.
item retraction, overlay picker
call us, wait time, PIN, IP-Relay
Redline specs so engineering never had to guess.
The work was detailed and handoff-ready. I wrote full developer specifications, redline documents pinning down type, color values, pixel spacing, iconography, and component states. In a system meant to be reused, ambiguity in the spec would have multiplied across every market that inherited it.
a redlined component spec, the help panel, pinned down
Full redline documents pinned down type, color values, pixel spacing, iconography, and component states, so an engineering team could build to them without guessing.
Did it ladder up to what eBay was measuring?
eBay’s Online Customer Support program (internally, OCS) set four objectives and a multi-year plan to reach every global market. Those were set above me. My modular framework was the delivery vehicle design used to execute against all four at once, market after market.
Trust
A familiar, consistent experience on every eBay site.
Accessibility
One shared structure surfacing the same channels everywhere.
Usability
A cleaner page with fewer mis-clicks into the wrong area.
Resolution
Self-service first, common problems front and center.
Five timezones, three countries, and a brand mid-change.
The coordination problem was harder than the design one, stakeholders in five timezones plus an offshore team in India. What fixed it was discipline: deliberate daily check-ins, being the reliable clearinghouse for four PMs, and processes so “who has the latest, and what’s next” was never a mystery.
Then something I did not see coming. We were the first team at eBay to take on the rebrand, and once the vertical worked out that we were not building the way the other teams in it were building, we got pulled out of the standard design reviews and left to our own devices. So the modular approach got built outside the process that would have asked it to match everyone else.
Design components that compose and decompose cleanly.
The portal launched across its target markets on a framework built to scale to eBay’s wider global infrastructure. That modularity paid a second dividend I hadn’t fully priced in: it made the design future-proof. The same framework carried into further market waves and stretched to cover adjacent features (Answer Center, Call Me, notifications, Report This Item) each one another piece composing into the same system. Remnants of the work are still visible on eBay’s support site today, and serving wildly varied needs without fragmenting the experience is a pattern I’ve used everywhere since.
The two launch KPIs were fewer calls to customer service and higher self-service use.