Five tools. One platform.
Lead Product and 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. I won the budget to deliver it.
the platform, across desktop and mobile
mobile redesign
The mobile experience preserved the same confidence-building path: understand the platform, browse the APIs, and evaluate pricing before asking for a commitment.
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.
FedEx.com Homepage: Permission-Based Tile Architecture
The FedEx.com co-existence surface was one of the most structurally complex problems on the platform: a shared homepage serving two fundamentally different user states with different permission sets, different tile inventories, and different commercial objectives. The design had to work as a single rendering surface that conditionally assembled itself based on login state and account type, with no user-facing indication that they were seeing a different layout.
Manage Org: Designing the Admin Experience Across Three Surfaces
The Manage Organization section was the operational core of the post-login platform. Org admins managed users, linked billing and shipping accounts, and configured org-level settings including the irreversible delete org action. Each of the three tabs (Users, Shipping Accounts, Settings) was a distinct surface with its own data model, permission requirements, and edge cases. The content and design audit systematically tagged every element across four annotation types: Design, Opportunity, Content, and Global.
deep dive 01: webhook routing
Webhooks were the platform’s newest product, and the most operationally complex. Enterprise accounts use them to push real-time shipment event data directly into warehouse dashboards. Misconfiguration isn’t a minor bug, it breaks a logistics loop.
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
New components, built to live inside FedEx’s 1DX system.
I led the design library updates for this initiative, designing new components that would live inside FedEx’s 1DX design system. We ran weekly workshops with FedEx’s internal brand team so the platform and the broader brand system evolved together, with every pattern authored once, documented with its full set of states, and reused across every surface.
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
2.5 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.
