Five principles.
Each one earned on a shipped project. The links go to the evidence.
failure paths
Design the failure paths. Trust is built or lost when things go wrong. Webhooks that misconfigure, billing accounts that don’t exist, permissions that block a teammate: I design those recovery lanes as primary surfaces, each with its own content, actions, and next step. On the FedEx Developer Platform, the four paths that don’t end in success got the same design attention as the ones that do.
See it in the FedEx case studysystem state
System state is a designed surface, not an apology. Outages, empty states, and saved-but-incomplete work deserve composed screens, not error strings. The FedEx API status page treats disruption as information a developer can act on, and every notification is a named type with a shared template.
See it in the FedEx case studyconfidence first
Confidence first, commitment second. Enterprise platforms hide their value behind sign-up walls. The pre-login experience should answer three questions before asking for an account: what can I build, how hard is it, and how good are the docs. The same logic drove Cognex, where search had to prove itself on the first query.
See it in the Cognex case studywith engineering
Built with engineering, not handed off to it. Design systems fail as deliverables and survive as shared practice. The 67-component CDM Smith system and the Cognex library were authored alongside the teams that shipped them, with tokens, states, and documentation engineers actually use.
See it in the CDM Smith case studythe real problem
The brief is rarely the problem. FedEx asked for a documentation refresh. Research showed developers left before they ever reached the docs, so I made the case for a platform redesign instead, and won the budget to deliver it. Scope should follow evidence, not the purchase order.
See it in the FedEx case study