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. 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
Not one portal — every country’s 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 bespoke rebuild each time.
Pull the portal into the same clean, modern era as the rest of eBay.
Two beliefs — and one assumption I had to check.
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, streamlined 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.
Self-service first was a choice — here’s what it beat.
Before committing, I explored a few landing layouts — self-service first wasn’t the only option 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 wasn’t just a private mental model — it was 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 that layer on — never hardwired into a 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.
How it laddered up to the company’s goals.
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 wasn’t a tool; 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 a surprise from inside the building: eBay’s own design team pushed back — the work wasn’t “on brand.” But the brand was actively changing, and the support portal was exactly the low-stakes property to push the visual direction forward. I made the case, worked through conflicting feedback from design and product, and got everyone to a shared position.
Design components that compose and decompose cleanly — not fixed, finished flows.
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, not a bespoke rebuild. 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 — fewer calls to customer service, higher self-service use — were defined but measured after my involvement, so I don’t quote numbers here.