Umbrella: The Tool That Saved Amazon $250M

The Problem

One of Amazon's most critical KPIs is DEA (Delivery Estimate Accuracy) - the percentage of packages that arrive when customers are told they will. DEA directly drives customer trust. When a package is going to be late, the only way to protect DEA is to proactively update the customer's delivery estimate before the original promise expires. If you tell a customer their package will arrive Thursday and it arrives Friday, that's a DEA miss. If you update them on Wednesday that it's now arriving Friday, that's accurate.

Severe weather is one of the biggest threats to DEA. Storms, floods, hurricanes, and extreme heat events disrupt Amazon's transportation network across hundreds of thousands of routes. When weather hits, the only way to maintain DEA is to add time to delivery promises in affected areas - what Amazon calls a "promise pad." A pad extends the estimated delivery window so the promise still holds even if the shipment is delayed.

The challenge was that there was no single system to manage this. Each region had its own approach. North America used a tool called Tramontane. Europe used a separate weather contingency system. Both were siloed, manually intensive, and couldn't talk to each other. Senior leaders had no unified view of how weather was affecting their network, and frontline operators were spending hours manually placing pads on individual routes.

The result was reactive instead of proactive: teams scrambling to respond to weather events after they'd already started impacting DEA, with no consistent framework for deciding when and how to intervene.

The Existing Landscape

The first step was understanding what already existed. North America and Europe had built their own weather response systems independently, each with different mental models, different workflows, and different levels of automation.

The NA system was more mature in some areas but lacked the configurability that EU teams needed. The EU system had more flexibility but was harder to scale. Neither system could give senior leaders a clear picture of what was happening across regions, and neither could handle the growing complexity of Amazon's network.

Research

I conducted extensive research across three distinct user groups to understand the full picture of how weather contingency worked at Amazon. Each group had fundamentally different needs and mental models.

System Configurators were the power users. They defined weather strategies, set thresholds, and configured how the system should respond to different types of events. They needed deep control and the ability to set rules that would scale across thousands of routes.

Senior Leaders cared about one thing: is my network going to be adversely affected by weather? They needed visibility and reporting, not configuration. They wanted to see the status of their region at a glance and communicate that status upward.

Manual Overriders were the frontline operators who needed to intervene when automation wasn't enough. A local weather event, a specific route that needed special treatment, a situation where the system's recommendation didn't match ground truth. They needed speed and precision.

Key Insights

• Fragmentation was the core issue. The problem wasn't that existing tools were bad individually - it's that having separate systems for each region made it impossible to build a coherent global strategy or get a unified view of weather impact.
• Automation needed guardrails, not replacement. Operators didn't want full automation. They wanted the system to handle the 80% of routine decisions while giving them clear control over the 20% that required human judgement.
• Reporting was as important as action. Senior leaders spent significant time manually compiling weather impact reports. The tool needed to make reporting a byproduct of operation, not a separate task.
• Speed vs. accuracy trade-offs were constant. During a weather event, teams had to choose between protecting customer experience (adding delivery time) and maintaining speed promises. This trade-off needed to be explicit, not hidden.

North Star Design Tenets

Based on the research, I established three design tenets that guided every decision throughout the project.

Design Process

As the solo design lead, I owned the end-to-end design process from research through to handoff. The design evolved through multiple rounds of iteration, working closely with engineering and product stakeholders across NA and EU.

I started with the information architecture: mapping out every workflow across both existing systems, identifying overlaps and gaps, and designing a unified structure that could accommodate both regions without forcing either to abandon their existing mental models entirely.

The key challenge was designing for three very different user types within a single interface. System Configurators needed depth. Senior Leaders needed breadth. Manual Overriders needed speed. The solution was a layered architecture where each user type could access the depth they needed without being overwhelmed by features they didn't.

The Solution

Umbrella was designed as a unified platform with four core surfaces, each serving a distinct purpose in the weather contingency workflow.

The Cockpit

A real-time dashboard showing weather event status across all regions. Senior leaders could see at a glance which areas were affected, what protections were active, and what the expected impact would be. This surface turned reporting from a manual task into a passive one.

Protections Management

The core operational surface where teams could view, manage, and override active protections. The map view gave spatial context, while list and facility views gave granular control. Operators could drill down from a region-level view to individual facility protections in two clicks.

Promise Pad Workflows

Adding and managing promise pads was the most frequent operator action. I designed a streamlined flow that reduced the steps needed to place a pad while maintaining the guardrails needed to prevent errors. Bulk upload capabilities meant teams could protect hundreds of routes in minutes rather than hours.

Performance & Analytics

The performance surface gave teams visibility into how promise pads were performing, volume share across regions, and deep-dive analytics into why specific pads were placed. This closed the feedback loop: teams could see the impact of their decisions and refine their weather strategies over time.

Handoff & Build

Handoff was a continuous process rather than a single event. I worked embedded with engineering throughout, reviewing implementations against designs, adjusting specifications based on technical constraints, and maintaining a living design system that evolved with the build.

The global scope meant coordinating across time zones with engineering teams in North America and Europe. I created detailed interaction specifications and edge case documentation that allowed teams to build independently while maintaining consistency across the platform.