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
Tracking software deployments
Making deployment failures legible and recoverable across a fleet of 21K+ devices.
This is the deployment-tracking work within the same device-management console as the fleet-visibility study.
A status tool is only as useful as what it tells you to do next. When deployments failed, ours showed what broke but never the next step, so engineers fell back on an untracked Slack loop. I redesigned deployment tracking into a self-serve recovery workflow: failure states you can read, AI-assisted root cause, and one-click retry. Projected to cut support hours by 67%.
- Projected 67% fewer support hours (re-measured 60 days post-launch)
- Retry: 5–10 min to one click
- 200+ Slack support messages to in-UI troubleshooting
- 21K+ devices · 180+ fleets
Role, team, timeline
- Timeline: January to March 2026.
- Role: Sole UX designer. End-to-end interaction and UI design, 0 to 1.
- Team: I built the MVP solo; the redesign was staffed with a PM and five engineers across two teams.
Context
UsersSoftware engineers own the software on devices across fulfillment sites and lead troubleshooting when deployments fail. IT associates handle device-level issues on the ground. These users are technical, so the bar was legibility under pressure, not simplification.
How deployment works, and why tracking it is hardAcross our fulfillment sites, robots and edge devices run software and OS images that have to stay current and identical within each station. Those devices are grouped into workcells: a set that operates together and must run the same version. A deployment pushes a new version out to those workcells one group at a time, and each one either lands on it, fails, or rolls back to the last known-good version. Deployment tracking is the layer that makes the rollout legible, so an engineer can catch a bad version before it spreads.
The hard part is the hierarchy. A single deployment fans out across fleets, sites, workcells, and devices, and a failure can hide at any level. When the fleet moved from single-device stations to multi-device workcells, the old tracker broke. It followed one device at a time, so it couldn’t answer the question the new model created: which device in this group is the problem?
Current state: the MVP that shippedI designed the first tracking experience from scratch, before the project had a PM, and validated it through ten interviews across fleet programs. That MVP is what runs today: color-coded workcell status, a progress chart, a results table, linked device and log pages, and automatic rollback visibility.
One principal engineer called it “the exact feature we’ve been looking for,” and it is now the surface engineers use to monitor deployments across 180+ fleets and 21K+ devices. When the redesign began, the team grew to a PM and five engineers, and I led design across it.
Validation also showed where the MVP stopped. Engineers kept asking for more granularity: failure states beyond pass or fail, device-level context like connection health, a read on rollback rates across a group. The format worked; it just wasn’t legible past the top level. Of roughly 16,000 deployments a quarter, 3 to 9% fail each week, and rollbacks recover a workcell only 83 to 100% of the time. The tracker was fluent in what happened and silent on what to do next.
The problem
A clickable status is only as useful as what it tells you. When a deployment failed, you could click the failed state for the device and a short error reason, but the popovers were a coin flip: some helped, some came back empty, some didn’t open at all because the backend had nothing to return. For a tool people open precisely because something is already broken, that wasn’t a polish problem. It was the product failing at the one moment it existed for.
So engineers routed around the UI. Troubleshooting moved somewhere the product couldn’t see: 200+ messages across two Slack channels in three months, fielded by about five engineers, most not tracked as tickets. And amidst this, one key request showed up over and over again: “Can I just retry this without kicking off a whole new pipeline?”
How might we take an engineer from a failed deployment to a fix, without sending them to Slack?
The solution: self-serve recovery through progressive disclosure
Where does the troubleshooting detail live?The first instinct was to bolt a troubleshooting section onto the tracker page. It would have worked, but it would have made the busiest page in the console busier.
Once the project was staffed, the PM and I wrote the user stories together, turning the two gaps into scoped, buildable work. I ran design walkthroughs with engineers in the room so we could settle design intent and technical feasibility in the same conversation.
The hardest question, whether a workcell deployment details page should exist at all, had been debated and shelved six months earlier. We reopened it together once the backend could support real device-level data. And the backend had matured enough to support deployment timelines, device-level detail, and health checks, so there was finally enough data to justify a dedicated surface.
Then a key stakeholder reframed the problem: instead of hiding failed workcells from the summary, let people drill into them. That moved the question from “how much do we show on the tracker?” to “where does the detail live?”, the one progressive disclosure is built to answer.
The navigation decision, made on purpose
I made a decision to route the user to workcell deployment details page when clicking on workcell name from the deployment page. Then a walkthrough with a customer during early testing session surfaced a snag: this contradits the console wide pattern where clicking a workcell name always opens the workcell page, never a deployment view, and confused the user.
I chose not to change the existing pattern. A workcell name still opens the workcell page, now with deployment context waiting there, and the details page is one click further for the deep dive. The actions menu offers a direct path for anyone who wants the shortcut. Respecting the pattern protected every other workflow that relied on it without hiding the deep dive from the people who need it.
Three layers of self-serve resolution
Recovery should meet you at the altitude where you noticed the problem, so the fix is a progressive drill-down across three surfaces. A lot of recovery happens before a human is involved at all: the system auto-retries a failed deployment before flagging it, and it runs pre and post-deployment health checks, rolling a workcell back automatically if a device comes up with a connectivity or health problem. An engineer only steps in when a human is actually needed.
1. Tracker page
Rejected workcells (failed and rolled back) collect in their own section under the deployment chart, so failures stop hiding in a long table. Retrying used to mean opening a separate console and re-triggering by hand, 5 to 10 minutes an attempt; a retry button on that table makes it one click.
2. Workcell page
For people who arrive from another workflow, a red banner appears when a deployment fails and links straight to the troubleshooting view. It adapts to all 11 deployment states, so the surface stays accurate whether a deployment is in progress, delayed, blocked, or rolled back, and it stitches together two experiences that never talked to each other.
3. Workcell deployment details page
The deep dive, the page rejected six months earlier and revived once the backend matured. It carries a deployment timeline, rejected devices and peripherals with per-failure reasons, pre and post-deployment health checks that show whether a problem was pre-existing or introduced by the update, and the AI summary with its two actions: run an automated fix or cut a ticket.
When nothing goes wrong, the same page shows an all-green timeline and passing checks, making “everything worked” as legible as “something broke.”
Designing the AI summary to be trustedThe AI summary was the piece most likely to draw skepticism, so I anchored it in real data. It is generated from the deployment information the backend already records, the failed step, the device, the error reason, so it explains actual signals instead of guessing at them. It surfaces the likely cause and a resolution path, down to the CLI commands tailored to the specific failure, then hands the decision back: the engineer chooses whether to run the automated fix or cut a ticket.
Results
Testing changed the design, not just confirmed itBefore handoff, I ran five moderated sessions with software engineers across programs. The goal wasn’t validation theater; it was to find where the recovery flow still asked too much of someone who opens it a few times a quarter. Three changes came out of it:
| What testing surfaced | What I refined |
|---|---|
| The details page had the right data but risked overwhelming an infrequent user. | Made sections expandable: key context upfront, deeper data opt-in. |
| Engineers wanted to get from failure to root cause to fix more automatically. | AI summary leads with a likely cause and resolution steps; full self-healing scoped as a fast-follow. |
| It was unclear how a multi-device failure would surface at the workcell level. | A rejected-devices table surfaces per-device failure reasons. |
“Surfacing deployment failures so we don't have to visit individual stations is a big improvement. If you can get from issue to root cause to how to fix it more automatically, that would be huge. Today we go to each workcell: one timed out, so it's a simple retry; another has a full disk, and that's a separate issue.” — Senior Software Engineer, Fleet B
Impact and what’s nextThe redesign is handed off and waiting to ship, so the numbers I care about are still ahead of launch. What I can stand behind today is structural, and I made each call deliberately. I replaced an untracked support channel, 200+ Slack messages in three months, with troubleshooting built into the UI. I connected the tracker to the workcell page so no one lands on a dead end. And I collapsed a manual, multi-minute retry into a single action.
The 67% reduction in support hours is a projection, not a result yet. Sixty days after launch I'll re-measure Slack volume and ticket counts against today’s baseline, and I’ll use Pendo to see how many engineers actually click through to the troubleshooting flow, not just whether it shipped.
What comes next is gated by the backend, not by design. The location-based rollout, one workcell per site or site A finished before site B, waits on the system learning zones within a site. And a coming program that breaks the “every device lives in a workcell” assumption will reopen tracking for a broader redesign.