Reframing Delivery as a Confidence Problem
Reframing a delivery UX problem as a confidence problem changed everything — including the metric.
Analytics showed users going back and forth in H&M's delivery section. The team had framed it as a UX problem. Reframing it as a confidence problem opened the solution space and gave us a metric we could actually measure. Two rounds of unmoderated testing, three concepts, one clear winner. 46% faster delivery selection. +0.32% checkout CVR.
Users were going back and forth — but nobody knew why
H&M's checkout had recently been redesigned. Post-launch analytics showed unusual behaviour in the delivery section: users selecting an option, going back, selecting again. Hesitation, not confusion.
The brief that landed with me was vague: fix the delivery section. Before designing anything, I needed to understand what was actually broken.
The real problem wasn't delivery — it was confidence
The back-and-forth wasn't evidence that users couldn't find an option. It was evidence they weren't confident in their choice.
New framing: How might we make users confident they've made the right delivery selection — fast?
This changed the success metric. Instead of task completion, we measured time in the delivery section and checkout conversion — both direct signals of confidence.
Three concepts, each betting on a different confidence signal
Competitor analysis across major European retailers. Ideation workshop with the team. Three concepts, three different bets on what creates confidence at the point of delivery selection.
8 participants per concept. 32 tests total. Tasks: find the cheapest, fastest, and most sustainable option.
One-Screen pulled ahead — but it was the most expensive to build
One-Screen Overview performed best across all four test scenarios. But it required the most changes to the underlying checkout data structure — engineering flagged it immediately.
Rather than negotiate scope in a meeting, I took two engineering-friendly simplifications into a second round of testing.
Simpler to build. But would it still work for users?
Both simplifications preserved the core one-screen idea — just with fewer changes to the data structure. The question was whether the simplification would show up as a regression in user confidence.
The simplification wasn't a compromise
Four conditions: baseline, original One-Screen, and both simplifications. Simplification A — all options in one list — matched the original on confidence metrics while being significantly faster to build.
The testing removed the engineering tradeoff from the conversation. We didn't ship a compromise — we had evidence it wasn't one.
All options. One list. Pre-selected.
All delivery types in a single list, pre-selected to the most likely method and location. Speed variants expressed inline — no wizard flow, no hidden options.
Users could see everything and make one confident decision.
46% faster. +0.32% CVR. And a missed opportunity.
Delivery selection time dropped 46%. Checkout conversion rate increased 0.32% — statistically significant, and material in absolute revenue terms at H&M's transaction volume.
What I'd do differently: ship a roadmap alongside the fix. The team had appetite to iterate — estimated delivery dates, smarter pre-selection, sorting and filtering. Shipping the fix without a vision meant that appetite went elsewhere. A good outcome with a missed opportunity to compound it.