WARP TRACKING
Warp · Public shipment tracking · Case study

Warp · Public shipment tracking · Redesign

Tracking Page.

The public page a stranger opens to see where their freight is. It is often the only piece of Warp they ever touch, and the old one lied to them in small ways they could feel.

I rebuilt it as an honest-states engine. The AI wrote most of the code under my direction. The problem, the states, the honesty rules, and the judgment are mine.

Role
Product design engineerWarp · solo deliverable
Work
Research, before-state reverse-engineering, IA, visual and motion design, a 12-rule status engine
Team
One designer. Rahul owns the production app. Troy, our CRO, set the frame.
Scope
Front-end only, zero backend change. Lumen design system. A vanilla prototype and an Angular drop-in.
Status
Redesign package, handed off. Standalone version rolled back. No traffic to attribute.
The redesigned Warp tracking page on a phone: a dark card that leads with the status 'On the way to Hialeah, FL', the estimated arrival time, a pickup-to-driver-to-dropoff journey strip, and the recent activity below, over a route map. Image1170 × 2532Redesigned tracking view on a phone
The surface a consignee opens from a delivery email
01 Counts Precision up front

Counts, not outcomes.

I want to be precise up front, because on this project the honest version is the strong one. There is no adoption chart here and no conversion line. What is real is the scope, the craft, and a status the page cannot fake. Everything below is counted, and I can point to the source.

19
shipment states designed from one data model, including every failure and terminal state. The backend knew nineteen; the old headline showed four.
12
priority rules that compute the true status locally, so the headline can never contradict the shipment. Verified in the shipped code.
0
percentages on the page. No fake progress bar, no invented ETA confidence, no soft number to make the wait feel shorter.
0
backend changes, proven by a live network audit of a real shipment. Everything the redesign shows was already on the wire.
88 to 56px
header chrome, trimmed. When fixed chrome competes with content, I shrank the chrome, not the content.
9.72:1
error-text contrast on the alerts field, AAA. Accessibility is part of care being total, not a thing bolted on at the end.

Solo design deliverable. Rahul owns the production Angular app I was modernizing. Troy, our CRO, set the frame: front end only, keep the map, make it something a customer would trust.

02 The before What it hid

The page told the user less than it knew.

The old page did not lack data. It looked like a hacker terminal, matrix green and monospace on a map, so a person opening it from a Walmart delivery email wondered if their package was even real.

And underneath the look, it was dishonest. The backend knew nineteen distinct shipment states. The headline showed four. So a truck near pickup and a truck near your door both read the same two words, and it could say In Transit on a returned order.

Retiredmatrix-green #00ff41 · status cyan #00ffff · saturated yellow #ffff00 · the green-glow shadows · monospace-everywhere

Two desktop tracking panels side by side, each showing a cancelled order. Left, the real captured original for a Walmart shipment: a matrix-green monospace layout greeting the order with 'Your order has been delivered! How was your experience?' above a five-star rating widget, while the stops below read Canceled and PickupFailed. Right, the redesign rendering the same cancelled state on a stand-in order: a calm dark card with a coral status dot that reads 'Order cancelled, reach out to support for next steps', a real Call support line, and no rating request. Image2880 × 1620A cancelled order · the real capture and the redesign
A cancelled order, before and after. Left is a real captured Walmart order, exactly as the old page rendered it: greeted by “your order has been delivered, rate your experience” while the stop right below it reads Canceled. Right is the redesign rendering that same cancelled state on a stand-in order, so no real customer’s shipment is on display. The cancellation was in the data the whole time. The old headline was the only part that lied about it.
There is not a single percentage on this page.

No fake progress bar, no invented ETA confidence, no “87% of the way there.” When the arrival time is unknown, the page says so, and it hides the field instead of printing a comforting number that is not real. On a tracking page a made-up number is the easiest lie to tell, so it is the one I refused to build.

03 The rules Three caught lies

Three rules, each from a caught lie.

I did not start with principles. Each of these came from catching the design tell a small lie, and I wrote it down so I would not repeat it. That is most of what senior looks like here. I still make the mistakes. Each one leaves a rule behind.

01

Say the true thing.

The headline is computed from the real shipment state, so it can never say “In Transit” on a returned order. When a state has nothing honest to show, the page hides the field rather than faking it. An empty ETA hides its card. An empty history hides its section. No comforting placeholder.

02

Chrome must equal function.

Every control that looked interactive had to actually do the thing it promised. I killed the decoys by building the function the chrome implied, not by deleting the chrome. The dead “More options” button became a real copy-link button. The “Contact support” button that opened an unrelated pop-up became an actual phone link.

03

Care is total, motion is earned.

Every state got the same attention, including the ugly ones. Pickup-failed and disposed auto-expand their full history, because that is exactly when a person needs the whole story. The motion is driven by the shipment’s state: one flag drives the live pulse on the status dot, the driver, the newest event, and the map pin, so they can never disagree about whether the shipment is moving.

The redesigned detail view for a shipment in transit: a floating header over a live route map, and a card that leads with the computed status 'On the way to Hialeah, FL', a pickup and arrival time, an origin-to-driver-to-destination journey strip with a live pulse on the driver, one arrival-alerts action, and the activity timeline open below. Image2560 × 1600Redesigned detail view · in transit
Fig. 01 · Say the true thingA status computed from the shipment, not from a leaky label. The card leads with the answer a person came for, reads like a sentence someone would say, and the live pulse only fires while the truck is genuinely moving.
A grid of nineteen small redesigned tracking cards, one per shipment state: pending, booked, dispatched, arrived at pickup, pickup successful, pickup failed, in route to dropoff, arrived at dropoff, delivered, complete, return initiated, in route to return, returned, cancelled, in route to warehouse, arrived at warehouse, departed from warehouse, disposed, and the home search view. Each card carries a status dot, a label, and a plain-language headline. Image2560 × 1600All nineteen states from one data model
Fig. 02 · Care is totalEvery one of the nineteen states, including the ones nobody wants. Pickup failed, cancelled, returned, disposed. Each got a status dot, a label, a sentence, and its own action, so a failed order reads as clearly as a delivered one.
04 The alerts control Three tries

The alerts control, in three tries.

The best story I have from this project is a small control I got wrong more than once in a single session. The lasting fix was not a widget. It was the habit the misses forced me into.

01
A toggle that opened a modal.I built the alerts affordance as a toggle. It did not toggle anything. It opened a setup pop-up, so the control lied about what a click would do.
02
A “real” toggle that flipped on.So I made it flip on for real. But there was no recipient behind it, no email, no number. It was claiming a state that did not exist yet. On with nothing to send to is still a lie.
03
A two-state setup, no toggle at all.Off, set up alerts when nothing is configured. On, email to [email protected], customize or disable once it is. The state becomes real at the moment you save, and never a click before.
The arrival-alerts row shown in its two honest states, side by side. Left, unconfigured: the label 'Off' next to a 'Set up alerts' link. Right, configured: 'Arrival alerts on', the line 'Email to admin@cascadegoods.com', and 'Customize' and 'Disable' controls. Image2400 × 1350The alerts row · unconfigured and configured
Fig. 03 · State before chromeTwo honest states instead of a toggle that claims one. The row can only show “on” once a real recipient is saved, so the chrome can never represent a state the system is not actually in.
Predict what the user does with a control, then criticize your own decision, before someone else has to.
The fix that stuck was a way of working. Before I ship a control now I run its three clicks in my head: the first click, the undo, and the cold-land.
05 Shipped twice No drift

Shipped twice, guaranteed identical.

A redesign is worth nothing if it drifts on the way into production. So I froze the backend, proved it, and shipped the design in a way that makes the built UI provably match the reviewed one.

01

Zero backend change.

I opened a real shipment in the browser and audited every network call. Everything the redesign shows was already on the wire, so the whole thing is a front-end job. That audit is what made the port cheap.

02

Reskin the data, not the UI.

For the Angular drop-in I refused to re-author the design in templates, because every re-typed pixel is a chance to drift. I reused the reviewed render and motion core byte-for-byte and adapted only the data layer.

03

A four-agent audit.

I put the drop-in through an adversarial ship-readiness pass that type-checked it under the real TypeScript compiler and caught a strict-compile blocker before a developer ever would. Then it was handed off.

The two build artifacts side by side rendering the same shipment identically: on the left the vanilla HTML prototype, on the right the Angular drop-in running through its data adapter. The status headline, journey strip, and activity are pixel-for-pixel the same because both reuse the one reviewed render core. Image2880 × 1620Vanilla prototype and Angular drop-in, identical output
Fig. 04 · No driftTwo artifacts, one render core. The vanilla prototype and the Angular drop-in render the same design because the drop-in reuses the reviewed core byte-for-byte and adapts only the data behind it, so a single engineer can integrate it with a guarantee that the UI matches what was reviewed.
06 Honest scope What I can prove

Honest about what it is, and isn’t.

This is a ship-ready, backend-audited, adversarially-reviewed redesign package. I deliberately rolled back a standalone deployable version, because a standalone app was not what the team needed. It is not a launch I can attach traffic to, and I would not draw a chart pretending otherwise.

What I can prove
  • Nineteen shipment states designed from one data model, including every failure and terminal state, not just the happy path.
  • A twelve-rule engine that computes the true status locally, so the headline cannot contradict the shipment. Verified in the shipped code.
  • Zero backend change, proven by a live network audit. Header chrome trimmed from 88px to 56px. Error text at 9.72:1 contrast.
  • An independent review of the validation pass came back “ship-ready, no blockers.” The Angular port reuses the reviewed code byte-for-byte.
What I will not claim
  • Adoption or traffic. The standalone version was rolled back and production integration was handed to the team. I cannot attribute usage to it, so I do not.
  • Conversion or support deflection. The promo shipped with analytics hooks specified, never instrumented. No number exists, and this page of all pages has no place for a fake one.

The honest value is the craft and the judgment, which live fully in the work whether or not anyone used it yet: a status a person can trust, every state told truthfully, and a package a single engineer can integrate with a guarantee that the UI matches the design.

07 Reflection The smallest surface

The smallest surface is the honest test.

A tracking page has no room to hide behind features. There is one job and one card, and about thirty seconds of someone’s attention. Every choice is either true or it is a small lie a person feels before they can name it.

The best thing
The reskin was the easy part. What mattered was learning to predict what a user does with a control before I ship it, and criticizing my own decision before a stranger had to.
What lasted
On this project I turned each miss into a rule instead of a patch, and those rules outlasted the page. I reuse them on every project since.
The refusal
A tracking page is the one place a made-up number would have been the easiest thing in the world to print, and the most damaging to build.

The AI wrote most of the code. What I brought was the refusal to let it print a comforting number that was not real, on a surface where that would have been the easiest thing in the world to do.