Five tools. One platform.
Lead Product / UX Designer at Tank Design on FedEx’s developer platform. The work spanned pre-login through production, with biweekly user testing and a notification system that held the whole thing together.
challenge
FedEx asked for better documentation. Research said developers were leaving before they ever opened the docs. The barrier was onboarding, not content.
I argued for the bigger scope — a full platform redesign, not a doc refresh — and won the budget to deliver it.
research
Six archetypes. Five lifecycle phases. The choice: optimize for solo developers moving fast, or enterprise teams managing complexity.
I designed for both using progressive disclosure — simple on day one, deeper as needs grew.
transformation
Developer platforms often hide their value behind sign-up barriers. We designed a pre-login experience that answered three questions before asking for an account: what can I build, how hard is it, how good are the docs.
The homepage and API catalog work together to build confidence first, ask for commitment second.
how the work operated
A platform this big doesn’t survive on inspiration. It survives on cadence.
The work ran on biweekly user testing across multiple internal rounds at Tank, plus three independent validation studies with AnswerLab.
Coverage spanned the U.S., Canada, U.K., and India. Each round had a moderator guide, a per-participant note-taking workbook, Likert scoring, and a comparison matrix that mapped every screen against every test.
Toasts, alerts, modals, and gates were authored once as a system, not designed per screen. Every notification followed the same template: description, icon, body, variable interpolation, button hierarchy. That discipline shows up in production: the live copy file uses the same primitive across every surface.
And the work ran inside FedEx’s product increment cadence — eleven design briefs across PI 01/24 and PI 02/24 covered third-party onboarding, the developer agreement, web services retirement, the webhooks-disabled message, the pricing calculator, and the TPP post-login home.
deep dive 01 — webhook routing
Webhooks were the platform’s newest product, and the most operationally complex. I designed for the four paths that don’t end in success.
No billing account. No shipping account. All accounts already associated. Contributor without admin permission. Each one a first-class lane, not a leftover.
create webhook flow
five-step create flow — with branches for every gate the user might hit
deep dive 02 — admin progression
The post-login home wasn’t one screen. It was four states — new user, organization created, accounts and projects added, full administrator. The platform grows with you.
post-login state progression
empty → org → accounts → projects
deep dive 03 — notification primitives
A platform this dense generates a lot of system messages. We built toast, alert, modal, and gate as named types with shared structure and variable interpolation.
Consistency at scale, without copy-pasting.
state progression
early concept → refined → production
Most developer platforms hide what can go wrong. This one didn’t.
The temptation in B2B is to design the happy path and treat errors, gates, and partial states as edge cases. Tests with real developers told us the opposite: the trust is built or lost in the failure paths.
The decision was to first-class the in-progress lane, the permission gate, and the system-state message — same care as the create flow.
Show the value before asking for a login. Then design every path past success as carefully as the success itself.— design intent, fedex developer platform
result
3 yrs
leading product and UX across the entire platform.
biweekly
research with real developers across multiple rounds, internal and AnswerLab-led.
11
PI design briefs across two product increment cycles.
live
across pre- and post-login, APIs, webhooks, org admin, and the component library.
Three calls that shaped the platform.
Reframed a docs project as a platform redesign.
FedEx asked for better documentation. Research said developers were leaving before they ever opened the docs. I argued for the bigger scope — and won the budget.
First-classed the in-progress lane.
Saved-but-incomplete projects, permission gates, and system-state messages were treated as primary surfaces, not edge cases.
Authored notifications as a system.
Toast, alert, modal, gate as named types with shared templates — one pattern, every surface.
Let's make something work.
Boston & remote · Open to full-time & contract