PayPal: The Most Useful Thing I Did Wasn't Design a Screen

Most of my case studies are about a screen. This one is mostly about a handoff — a broken one, stretched across a twelve-hour gap, that no amount of good design work could fix until someone rebuilt the process underneath it. The product was PayPal's developer demo portal, which showed working code implementations of every PayPal product so a developer or small-business owner could see exactly how the gateways worked. I owned its interaction and visual design. But the story worth telling is the other half: the process I built to let an offshore design team in India and an onsite dev team in the US finally work as one.

Developers stateside, a design team in India, an Agile cadence, a roadmap. And a design team churning through hours at roughly 200% of budget because no one stateside was managing expectations between the two groups. Scope, feedback, and commitments all flowed downhill faster than the offshore team could absorb. (This was PayPal while it was still part of eBay, which mattered — I had earlier eBay experience to lean on.)

The problem wasn't skill or effort — it was that no one was authorized to say no. Sprint planning, scope, and feedback all happened stateside. The offshore team, twelve hours away, absorbed all of it without a seat at the table. When I dug into the real painpoints, the honest answer surprised me: the offshore team didn't push back, because the relationship had never made room for it. So the task was twofold — reel in the onsite team's expectations, and give the offshore team both realistic deadlines and a way to own their own process.

I set two concrete targets: get offshore hours from 200% into the 95-to-105-percent range of budget, and establish a streamlined process with shared, realistic expectations. My bet was that efficiency and team happiness weren't the trade-off everyone treats them as. I started with the onshore group to pin down actual scope, then ran three audits. They made the root cause concrete: no one in a project-management role bridging two continents, and a set of collaboration tools sitting idle.

I set up daily standups directly with the India team at the end of my day — their morning — to actually understand their capacity instead of guessing. That gave me a current read on what they could take on, and meant I walked into the onsite standup the next morning able to speak accurately to their status. The twelve-hour gap that had been the whole problem became the thing I organized my schedule around.

I built a ceiling into the process, then right-sized it: one feature plus a small, fixed number of enhancements per sprint, stated up front. Even that was slightly too much — after a couple of sprints we dialed it back to essentially one feature per sprint. I also moved sprint planning later into the US day so the India team could actually attend the meeting where their work got committed — the difference between a team that gets handed a plan and one that helps make it.

I spoke to their capacity, pushed back on overcommitment, and made sure the plan we left with was one they could actually deliver. When work genuinely outstripped what they could do and it still had to ship, I stepped in as a designer myself and took some on — it mattered that the person defending their capacity would also pick up a brush.

Offshore hours came down from over 200% of budget to roughly 110% — just outside our target, but a dramatic correction, and the burn rate finally stopped climbing. The project completed on time and with a considerable budget reduction, and the process held after I rolled off. The lesson that stuck: on a distributed team, the loudest problem is rarely the root problem. The loud problem was an overworked design team; the root problem was that no one was authorized to say no on their behalf. It was also my first real turn on the producer side of the role — and I came away knowing I'm genuinely energized by it.

See the full case study → https://design-case-studies.vercel.app/paypal