Case study · Amazon

Umbrella: the tool that saved Amazon $250M

When a storm is coming, Amazon extends delivery promises before the network slips. Umbrella is the platform that decides where those pads land, prices what each one costs, and explains a model's decision to the person who gets asked about it.

RoleSolo Design Lead

Timeline2022 – 2024

ScopeNorth America & Europe

Impact$250M+ saved

The situation

Accuracy is not speed

Amazon's network is measured on speed, cost and Delivery Estimate Accuracy, and they pull against each other
Accuracy: did the package arrive when the customer was told it would. Told Thursday, arrives Friday: a miss. Moved to Friday on Wednesday: accurate.
The promise can move. It just has to move before it expires.
The one thing Amazon can't automate is the weather

The basics

The promise pad lifecycle

Extend the promise before it expires, and it still holds when the weather hits.

A promise pad is a purchase: you spend speed to buy accuracy, and someone's targets pay for it.

Context

The same storm was getting three different answers

North America

Advanced machine learning system

Tramontane placed pads automatically from a machine learning model. Fast, hard to argue with, and it only handled snow.

Europe

Retrospective based system

A separate system with its own severity thresholds, built independently, and retrospective.

Canada

No system at all

Every pad was worked out and placed by hand, event after event.

None of them could see the others, and nobody could say what was happening across the network without assembling it by hand.

Design opportunity

How might we automate a decision this consequential, without taking away the control people need to defend it?

Research

Three groups wanted opposite things from the same product

A week-long workshop in Seattle with operations teams from both regions, with engineers in the room from day one
That's how the snow-only constraint surfaced in week one, not in a sprint review
Configurators wanted depth. Leaders wanted breadth. Mid-event operators wanted speed, and nothing else, all competing for the same screen.

Photographs and artefacts from the Seattle workshop, with walls of notes mapping the vision, personas and feature priorities across regions — A week in Seattle, mapping how each region actually handled an event.

Research · Personas

Three personas came out of the workshop, wanting opposite things

Configurators write the rules before the season. They need depth: every parameter, every threshold.
Senior leaders have one question: is my network about to be hit. They need breadth, in one glance.
Manual overriders place pads mid-event, with a storm tracking in. They need speed, and nothing else.

The three Umbrella personas: configurators who need depth, senior leaders who need breadth, and manual overriders who need speed — Depth, breadth and speed, competing for the same screen.

Research · Baseline

We scored the three tools before touching anything

SUS 58

Tramontane · North America

The strongest of the estate: operators genuinely liked seeing pads placed on a map of the US. What held it back was snow-only coverage, and reasoning nobody could explain upward.

SUS 47

Rulebook system · Europe

Retrospective by design: it told teams what they should have done after the storm had been and gone.

No score

Manual process · Canada

Nothing to put in front of a user: every pad was worked out by hand in spreadsheets, so there was no tool to score at all.

The industry average SUS is 68. Neither tool came close, and one region had nothing to measure in the first place.

Research · In their words

The scores had voices behind them

The map is the one thing I'd keep: you can see the pads land across the US. But it only speaks snow, and when a wind event hits, or leadership asks why a pad exists, I'm on my own.

Operations manager · North America

By the time the system speaks, the storm has been and gone. We are always reading last week's answer.

Configurator · Europe

Every event is a night of copy and paste. One typo in a postcode and the wrong city gets padded.

Operator · Canada

Research

Four findings came back. Every decision traces to one.

01

Needs pulled in opposite directions

Deep control, one answered question, or pure speed, depending on who you asked.

02

Nobody wanted full automation

Handle the routine 80%, but leave real control over the 20% that needs judgement.

03

Reporting was eating evenings

Leaders assembled weather impact reports by hand for every event, so the picture was always late.

04

The key trade-off was invisible

Teams chose between protecting the customer and protecting speed constantly, without ever seeing the price of the choice.

Workshop insight · Coverage

Cover every weather type from day one, and let models earn their place

Weather type	Placement at launch	Automation status
Snow	Tramontane ML model	Model live
High wind	Retrospective rules	Model in training
Heavy rain & flooding	Retrospective rules	Model planned
Ice & freezing rain	Retrospective rules	Rules only
Extreme heat	Retrospective rules	Rules only
Hurricanes & named storms	Rules + manual judgement	Rules only

The requirement that fell out of this: the product cannot care how a pad was placed. Model, rule or human, every pad lands in the same list with the same controls, so a weather type graduating to a model changes nothing for the operator.

Foundations · Tenets

The tenets of Umbrella

01

You only need one Umbrella

One product for every region, every weather type, and every way a pad gets placed. No more three answers to the same storm.

02

Umbrella should be low touch

You set a strategy before the season, and Umbrella does the rest. The routine 80% should never need a human hand.

03

Umbrella should report

What was protected and what it cost, compiled by nobody. The picture leaders used to assemble by hand, always there.

04

Umbrella should allow manual override

Automation people cannot overrule is worse than none. A person can always step in, and their pad gets the same standing as the model's.

Every decision that follows was argued against these four. One of them I knowingly broke, and the deck says where.

Foundations

One model of the work, before any screens

Three regions had three different definitions of what a “pad” even was
Before any UI: one object model, the objects, the states, the language, agreed with engineering
Once that existed the interface followed. Engineers built one thing, not a nicer version of three.

The Umbrella V1 information architecture, mapping every page and flow across the three persona types — One structure at three depths, rather than three products.

The work

Four decisions, and what each one cost

For every one, the option I did not take, and what choosing the other one cost us. That second part is usually the bit that goes missing.

Decision 01

One product layered by depth, not three tailored views

Separate views tested beautifully with each group alone
They fell apart when a leader asked an operator why is that pad there: two products, nothing in common to point at
One structure, three depths: cockpit → protections → configuration

What it costThe leaders' simplicity: their view carries a route into depth they will never personally use.

The Umbrella cockpit dashboard, showing weather event status and active protections across regions at a glance — The cockpit: the leader's question, answered without anyone compiling it.

Decision 02

The override belongs next to the result, not in a settings screen

Automation people cannot overrule is worse than none
System pads and human pads: one list, same controls on both
Accuracy and speed impact side by side on every row; the explanation one click away

What it costSafety: a Remove rule button inside a panel people open mid-storm. I have never been comfortable with how easy I made that.

The protections table, listing pads placed automatically by the system alongside pads placed by named people, with accuracy and speed impact on each row — Automatic and manual pads in one list; both sides of the trade on every row.

Decision 03

Show the real reasoning, and translate it in place

Operators answer for postcodes; the model thinks in its own weather regions. People were defending a decision they could not see.
The model's figures, unedited, with a plain-language glossary directly underneath
A friendly summary would have gone out of date the first time the model was retrained

What it costFirst-time readability: hardest on exactly the person opening it for the first time, mid-event, with someone waiting.

The model deepdive panel, showing the forecasting model's own figures with a plain language glossary beneath, alongside a snowfall chart and a regional map — “Why was this pad placed”: the model's own figures, translated where the reader is.

Decision 04

Price the pad before it counts, not after

The accuracy–speed trade was happening constantly, invisibly, in people's heads
Every pad shows its estimated effect on both, before it is submitted
Then it goes to a named approver, one at a time or hundreds at once

What it costSpeed, at exactly the moment speed matters, and tenet 02: the review step makes Umbrella higher touch, knowingly. I would still do it: the alternative is one person spending another region's speed with nobody agreeing to it.

The bulk upload review step, showing each pad with its location, type, timeframe and simulated impact on accuracy and speed before submission for approval — Bulk uploads expand into individual pads, so hundreds of decisions cannot pass as one.

Interaction design

Three ways to place a pad, one mental model

A form for precision, a file for volume, a shape drawn on the map for speed
Mid-event, people think in the shape of the storm; the system translates it back into delivery areas
All three land on the same review step. Speed changes the input, never the safeguards.

The draw pad location modal, where an operator draws a shape directly onto a map of the delivery network, with toggles to show delivery stations, sort centres and buildings inside it — Draw the weather, not the postcodes.

Craft · Design system

One design system: Meridian

A unified solution deserved a unified language: Umbrella is built on Meridian, the design system built for Amazon's transportation org
Most of the product is out-of-the-box Meridian: tables, forms, navigation, approvals. Deliberately unexciting, so nothing needs relearning mid-storm.
The gap was the map. Meridian had no map component, so we designed a new one and contributed it back, for every transportation team after us

Meridian: the transportation org's own system. Umbrella says “Built with Meridian” on every screen.

The product

The network, seen in place

The protections map view, showing active pads across the delivery network on a map

The protections map view: active pads across the network, running on the map component we added to Meridian.

The product

The report that used to eat evenings, compiled by nobody

The Umbrella performance page for promise pads, reporting what a pad protected and what it cost

Performance, per pad: what it protected and what it spent: the picture leaders used to assemble by hand.

Impact

$250M+

attributed to the weather padding programme that Umbrella made operable

The product

The Umbrella homepage: the Weather Contingency Padding Tool overview

Umbrella: one entry point for weather contingency across Amazon's global network.

Impact · Usability

SUS 84

Umbrella's score with the same operators who rated the old tools 58 and 47. Anything above 80 is an A grade; the industry average is 68.

Impact

The programme became usable

3 → 1

An automated model, a separate rulebook and a manual process, replaced by one product.

1 designer

Research, information architecture, every screen and the interaction specs, across two time zones.

0 → a function

A design function that hadn't existed at the start, with other designers hired into it and a product pipeline behind it.

Umbrella was the interface layer, not the model. What I own is that the programme became usable: a pad could be placed quickly, priced before it counted, and explained by name afterwards.

Thank you

James Peel · Senior Product Designer

Read the full case study All projects