Previously @ Amazon Artificial General Intelligence, designing human-in-the-loop tools for data scientists to expedite AI development.
About me
Resume
Previously @ Amazon Artificial General Intelligence, designing human-in-the-loop tools for data scientists to expedite AI development.
About me
Resume
Designing fleet visibility at scale
Replacing device-by-device inspection with answers at every altitude, across 180+ fleets.
You can’t manage 21K+ devices by opening them one at a time. The console could list everything in the fleet hierarchy but not tell you how any of it was doing, so the only way to judge a fleet was to inspect its devices by hand. I redesigned fleet visibility around progressive disclosure: a layered health model that answers a different question at every altitude, and the Workcell Explorer, a query-based page that folded three separate PM asks into one. The visibility work it's part of has realized roughly $27M in operational value to date.
- ~$27M operational value realized to date
- Health model shipped across the fleet hierarchy
- Workcell Explorer: 3 PM asks unified into one page
- 21K+ devices · 180+ fleets
Role, team, timeline
- Timeline: October 2025 to May 2026.
- Role: Sole UX designer on the console.
- Team: 2 PMs and 8 engineers. Each PM owned a separate slice; I drove the cross-cutting design direction that tied them together.
Context
The problemThe product is a management console for the edge computing devices that run across global fulfillment sites. Those devices sit in a hierarchy: fleet, partition (an AWS account and region), workcell, device, and peripheral. The console is where engineers, IT, and operations keep them running.
The hierarchy could list what existed at every level, but not the state any of it was in. With no aggregated sense of health, the only way to judge a fleet was to open it and inspect its devices one at a time. At 21K+ devices across 180+ fleets, that does not scale, and the people responsible were each rebuilding the same picture by hand.
The three audiencesThree groups lean on the console, and they want the same questions answered at different altitudes, not different products. An engineer asks whether a fleet is healthy enough to deploy to; local IT asks which stations at their site need a hands-on fix; operations asks where trouble is concentrating across many sites. So the problem was never per-persona customization. It was making each level useful on its own, for anyone.
How might we surface the right information at every level so engineers, IT, and operations can act without inspecting devices one by one?
Two constraints shaped the work. The data started locked to the partition level by AWS region boundaries, which capped any cross-fleet view until the backend caught up. And design direction was split across two PMs who each owned a slice, so the connective thinking, the part that tied their slices into one product, was mine to drive.
The principle: progressive disclosure
My through-line was progressive disclosure: each level of the hierarchy should answer its own question and reveal the next layer of detail only when you go looking for it.
| Level | Question it answers |
|---|---|
| Fleet | How is the entire fleet doing? |
| Partition | How is this partition doing? |
| Workcell | Which devices need attention? |
| Device | What exactly is wrong? |
| Peripheral | What’s the state of this hardware? |
| Site* | How is this physical location doing across all fleets? |
Progressive disclosure: Information table
Site is the exception: it cuts across the hierarchy, scoping by physical location rather than fleet. That gap is the one the Workcell Explorer later closes.
The solution: making each level answer its own question
From a single signal to a layered health modelBefore this work, the hierarchy could show you a list of devices, but not whether any of them were okay. Health was one crude signal, connected or not, repeated at every level. To judge a fleet, you still inspected it device by device.
I interviewed six fleet programs and scored roughly nineteen candidate metrics with them. The pattern was clear: every program cared about connection status across four subsystems, hardware, software, network, and peripherals. The deeper metrics (CPU, disk, temperature) mattered to some programs and not others.
| Category | Score | Key health indicator |
|---|---|---|
| Software | 6/6 | Connection status |
| Hardware | 6/6 | Connection status CPU and disk space |
| Peripheral | 5/6 | Connection status |
| Network | 4/6 | Connection status (important but not universal) |
That left a trap. One fixed health model could not fit programs with different definitions of healthy, but letting each invent its own would fragment the product. So I split the model in two: a universal baseline, connection status across the four subsystems shown the same way for every fleet, and an extensible framework inside it, where a program layers in its own metrics and sets its own Healthy, Warning, Unhealthy, and Disconnected thresholds. At the device level, a four-state model carrying a status, message, and timestamp gives those signals somewhere to land.
The payoff is one component that answers a different question at each altitude. At the fleet and partition level, aggregated counts; click a status to filter to the devices in it. At the workcell level, per-device columns to compare devices and find the one that needs attention. At the device level, full detail: every subsystem with its status, message, and timestamp. Same data, disclosed at the depth each level calls for.
This is the part that shipped, and it is the thesis in one feature: make each level legible on its own, so people stop inspecting devices one at a time.
From a static hierarchy to cross-fleet visibility: the Workcell Explorer
The console was built around a fixed hierarchy: fleet, partition, workcell, device. It answered “how is this one thing doing?” well and “what is happening across all of them?” not at all.
The site page that fell flatMy first answer was a dedicated Sites page, mocked in Figma off the partition page’s pattern. It worked on paper, but no one was excited, and I understood why: it was just another rigid view, one site at a time, when the people who needed it most ran across many sites. The framework could not stretch past the structure it was built on.
The failure was clarifying. It pushed me to see that three requirements, tracked separately by two PMs, were one problem wearing three hats: parity for devices migrating off a sunsetting platform, a long-standing ask for site visibility across fleets, and a request for universal search. Three teams were scoping three solutions; I proposed one. With a sunsetting platform to replace, the appetite for a single unifying page was already there, so the work was less about winning an argument than designing something that genuinely covered all three needs.
What made it possibleThis had been out of reach while the data was locked to the partition level by AWS region boundaries. A senior engineer proved out cross-fleet aggregation with a quick POC, and that was the green light: if the data could cross fleet boundaries, there was no reason to trap users in a single-site view.
The Workcell Explorer
So I designed the Workcell Explorer, a query-based page where you set your own scope with filters and the page assembles around it.
- Scope before data. You pick at least one fleet or site before anything loads, which bounds the query and quietly clarifies the audience: fleet and site owners, not component owners.
- Two altitudes, one page. A Dashboard for aggregated, threshold-aware health; a Workcells tab to drop down to individual workcells, devices, and peripherals.
- Health as a trend, not a light. Because connected does not mean healthy, the Dashboard pairs a point-in-time score with a 7-day trend and surfaces only the slices past a warning or critical line.
- Built to flex. Saved filter sets and a modular, add-your-own-widget layout, because different programs watch different numbers.
I took the concept through a design review that sold the PMs, and they carried it to leadership, where it was approved. The Workcell Explorer stopped being a page in the hierarchy and became a way to ask the system a question.
What changed: from checking devices to reading fleets
ValidationI tested the health model in prototype walkthroughs with five fleet programs, and the Workcell Explorer in five moderated sessions. The most useful finding cut against my first design: connected does not mean healthy. A station can be online and still be unworkable, a peripheral flapping every few minutes, for instance, so a point-in-time green dot misled people. That is what pushed the Workcell Explorer from a single status light to a score paired with a trend, surfacing only the slices that had crossed a warning or critical line. The trend, more than any single number, was what landed.
“Just because a station is connected doesn’t mean you can send an associate there.” — Software Engineer, Pack Program
The health model shipped, and it changed the default unit of work from a device to a fleet: people now read status at the altitude they need and drop down only when something asks for attention, instead of checking each device in turn. The broader visibility work it is part of has realized roughly $27M in operational value to date, with more projected as the Workcell Explorer rolls out.