Amazon Buy with Prime — Promotion Solutions
Merchants Needed Control Over Their Own Promotions. Nobody Had Built That Yet.
Buy with Prime was a new Amazon product — and in its early phases, it was invitation-only. Amazon was targeting a specific kind of merchant: established enough to be profitable, but not so large they hadn't committed yet. Think brands doing $500K to $3M in sales. Mid-market merchants who wanted Amazon's fulfillment and trust signals on their own websites, without selling through Amazon directly.
This merchant audience had no way to manage their own promotions. If they wanted to run a discount or a sitewide sale, they needed Amazon support to do it for them. That created friction, support overhead, and inconsistent adoption of a feature that should have been driving merchant engagement.
My job was to design the self-serve promotion experience that would fix that.
Working inside Amazon's product org as an embedded consultant meant something specific: I wasn't building from scratch. I was designing within an established system, alongside product managers, engineers, and stakeholders who each owned different pieces of a very large machine.
That environment rewards two things above everything else — precision and communication. You have to know exactly what you're designing and why, and you have to be able to articulate it clearly to people who are moving fast and have a lot of other priorities.
I was the sole designer on this feature. I had a design manager who set the broader direction, but the day-to-day design decisions, the discovery work, the cross-functional coordination — that was mine.
I started where I always start — understanding the problem before touching the design. Competitive analysis of how Amazon's own platform and Shopify handled promotions. Heuristic reviews of the existing merchant console. Whiteboarding sessions with product and engineering to understand what was technically possible and where the constraints were.
What the research surfaced quickly: merchants needed two distinct types of promotions — sitewide discounts and product-level discounts. Simple in concept. But as I mapped the full design, something else came into focus.
Promotions didn't just live in the promotion console. They touched the product catalog page. They touched the order summary page. Changing one without accounting for the others would create a broken, inconsistent experience downstream — the kind of thing that looks fine in a demo and falls apart in production.
Nobody had flagged this yet. I caught it through my own design process.
I documented the cross-surface dependencies and brought them to the Promotion PM and the designers and PMs who owned the affected pages. That conversation is what expanded the scope.
User flow — every surface the promotion feature touches across the Buy with Prime merchant console
Wireframes — annotated promotion creation flow showing ideation and stakeholder feedback
Surfacing that discovery was the easy part. What came next was harder.
I had to walk into conversations with multiple teams and their leaders — engineering, product management, stakeholders across functions — and make the case that we needed to slow down. That production should be delayed. That if we shipped without addressing the downstream pages, we'd be creating a UX problem that would cost more to fix later than it would to fix now.
That's not a comfortable conversation to have as a consultant embedded in a client's team. There's always pressure to keep things moving. But I knew what I was seeing, and I believed the right call was to address it.
They listened. We fixed it.
That experience taught me something I've carried into every project since: being persistent and persuasive across multiple stakeholders — especially when the message is inconvenient — is as much a design skill as anything you do in Figma. The best design in the world doesn't matter if it ships broken.
The promotion experience I built gave mid-market merchants full self-serve control over their promotions for the first time — sitewide discounts and product-level discounts, creation and management workflows, and full visibility into how promotions were performing against their orders and returns.
Product-level discount promotions required a catalog API integration that wasn’t in the original technical plan. I worked closely with the development team to scope what was feasible within the timeline while still meeting merchants’ actual needs — which meant getting product data into the promotion creation flow without requiring merchants to leave the console.
Mobile was a non-negotiable. Many Buy with Prime merchants operate with teams of fewer than ten people — they’re not sitting at desks managing dashboards. The mobile experience needed to support the full management workflow: creating promotions, reviewing status, responding to performance. Not a stripped-down version.
The order summary was a scope expansion that came out of the downstream analysis. Once we agreed to include it, the design challenge was specific: merchants needed to see not just which orders had promotions applied, but what happened when those orders were returned. The picture had to be complete — partial visibility would create more confusion than none.
Usability testing before launch validated the core flows. Two findings shaped the final refinements: search and filter capabilities significantly improved task success across the promotion management view, and merchants were meaningfully more confident completing the creation flow when promotions were clearly tied to their catalog inventory. The connection between a promotion and what it actually applied to had to be explicit.
In the first week after launch, 86% of eligible merchants used the promotion features. 180 automated promotions were created. $3.4K in Gross Merchandise Sales was attributed to those promotions in that first week. A clear signal: merchants were ready to engage the moment the tools existed.
Support overhead dropped. Adoption was immediate. The feature worked.
Amazon taught me how to operate inside complexity without losing clarity. When you're one designer in a large product org with many moving parts, the temptation is to stay in your lane and ship your piece. But design has a responsibility to the whole experience — and sometimes that means raising your hand when something is about to go wrong, even when it's inconvenient timing.
“The best design in the world doesn’t matter if it ships broken.”