One PayPal spec. Two flagship brands. Zero divergence.
Macy's and Bloomingdale's share a checkout codebase but not a design language. The PayPal integration had to ship Express Checkout and PayPal-as-tender across both brands without forking the spec, the engineering work, or the conversion behavior.
PayPal had to feel like a first-class payment method on both brands without either brand having to do bespoke work.
Express Checkout (skip-the-cart entry from product detail) and PayPal-as-tender (selectable in the standard checkout flow) are different flows with different risk profiles. The temptation was to ship them as separate projects. We chose to design them as one system with two entry points — and to model the brand layer as a token swap, not a redesign.
The brand layer is a token swap, not a redesign.
PayPal's brand guidelines allow one of two button colors (yellow #FFC439, blue #003087) plus a small set of typographic variants. The interesting design problem was not the button itself — it was making sure the surrounding checkout state, error handling, and confirmation behavior were brand-agnostic by construction.
Macy's checkout
PayPal button uses the yellow guideline variant to match the brand's existing CTA hierarchy. Cart summary, error states, and tender confirmation rendered using Macy's typography and spacing tokens — but from the same React components as Bloomingdale's.
Bloomingdale's checkout
Bloomingdale's existing CTAs are predominantly black on cream; the yellow button would have read as alien. Blue variant + matched corner radius + subtle elevation kept the button consistent with the brand's premium-retail tone.
Treat the PayPal button as a brand-tokenized component (color, radius, type) but keep all surrounding behavior identical across both brands so risk, support, and analytics could be measured on a single funnel.
Two entry points, one decision tree.
Express Checkout enters from product detail and bypasses the standard cart review. PayPal-as-tender enters from the standard checkout and slots in alongside credit and gift card. The two flows look different to the customer but converge at the same risk-evaluation and confirmation logic.
Express Checkout — entry from PDP.
A PayPal button appears beside the existing "Add to bag" CTA on product detail pages. Tapping it opens a PayPal-hosted authentication overlay, returns the customer to a single-screen review, and posts the order. No standard cart or sign-in flow.
PayPal-as-tender — entry from checkout.
The standard checkout flow presents PayPal as a payment-method option alongside saved credit cards and gift cards. Selecting it surfaces the PayPal authentication overlay; on return, the customer continues through the standard review and confirm steps.
Convergence — shared confirmation + error handling.
Past the auth handoff, both flows route through identical confirmation, error, and post-order state. This is what made the integration shippable in one sprint cycle instead of two: design specs for failure modes were written once.
Risk + fraud handoff.
Risk evaluation runs server-side on both flows using the same evaluation API. The design ensured operators in the risk console could not distinguish which entry point produced an order — preventing tooling fork — while customer-facing decline messages stayed flow-appropriate.
The two PayPal paths, mapped end to end.
Express Checkout collapses the shopping bag straight into a PayPal-authenticated review. PayPal-as-tender slots in at the Payment Method step alongside Credit Card and Klarna. Different entry points, same authentication handoff and the same confirm logic.
images/paypal/macys-bag-express.png
images/paypal/macys-payment-method.png
PayPal-eligible carts converted 18.4% better.
Comparison is against the eight-week pre-launch baseline on the same product set and the same audience cohort. The largest single lift came from Express Checkout on mobile — customers who entered from PDP and never touched the standard cart.
What I'd defend.
Designing express + tender as one decision tree with two entry points. The temptation to ship them as two projects was real and would have doubled the maintenance surface immediately.
What I'd do differently.
Get the risk team into the design review earlier. Several of the error-state copy decisions had to be re-litigated late because risk hadn't seen them in context. I now bring risk + legal into the second design review, not the fourth.
What changed for me.
This project was where I stopped thinking of "the design" as the screens and started thinking of it as the spec — the set of decisions captured well enough that other people can build from them without coming back to ask. That shift is what separated senior craft from lead craft in my own practice.
Why it mattered.
A payment integration is mostly invisible when it works. The point of the project wasn't a beautiful screen — it was a reliable confirmation that the customer's order is in. Designing the failure modes mattered more than designing the happy path.
Elanco Knowledge Systems
Parent case study. Lead-level body of work — discovery, design systems, AI tooling, and operations as one program.
Read parent → 04 / 2020OpenELIS · International Usability
Lab software studied across four countries. The most rigorous qualitative work in this portfolio.
Read study → 06 / TemplatePlace of Arrival viz library
Data-vis scrollytelling template. The funnel above could be re-rendered as a scrolly explainer through it.
Open template →