Work / Order Tracker

Where's my rug?

WISMO ("where is my order?") was the largest single category of inbound CX tickets at Ruggable. The data was there, just spread across two pages. CX brought the issue to UX. I led the redesign, consolidating the Order Tracker and Product Tracker into a single card-based system with state-aware copy, and helped cut WISMO ticket volume by nearly a third.

RolePrincipal UX Designer · Lead
CompanyRuggable
PlatformWeb · Mobile web
Status Shipped · 2025
28%↓ WISMO ticket volume
(post-launch · 90d)
100%↓ Post-ship "where is it"
email inquiries
3.2× Self-service
resolution rate
+11pts Post-purchase NPS
vs. baseline
01 · The problem

The data was there. Just not where customers expected it.

Ruggable had two post-purchase pages: an Order Details page (where customers landed) and an Order Status page that lived behind a "Track Item" link inside Order Details. The status data customers actually wanted (shipping state, tracking, delivery estimate) was on the status page, one click further than most people went.

WISMO ("where is my order?") was 10% of inbound CX tickets, the largest single category by volume. CX brought the issue to UX with a clear ask: consolidate the two pages into one, redesign around what customers actually need on the page, and deprecate the Order Status page.

Old Order Details page — where customers landed
01 Order Details where customers landed
Old Order Status page — behind a Track Item click
02 Order Status one click further
The two-page split that caused the WISMO load. Customers had to click "Track Item" inside Order Details to reach the actual status. Most didn't.
From the brief
"Key details on status are on the Order Status page, which requires an additional click to get to. We think many customers are missing this, expecting instead that the status/key details should be on our Order Details page. To offset CX tickets, we want to consolidate & redesign our Order Tracker (deprecating the standalone status page)."
02 · Brief & process

How a project moves at Ruggable.

Tickets at Ruggable start with a PM, who scopes the problem and writes the brief. UX takes it from there. Research, references, ideation, then rough directions back for review. We loop with PM and the rest of UX first, then bring CX in. Engineering builds in continuous feedback rounds with us so what ships looks and reads right.

For this one, CX had pulled both the volume picture and the qualitative. My job wasn't to gather raw research. It was to turn the brief into design directions.

Reference work first

Before opening an artboard, I built a reference board in Figma. Post-purchase tracking patterns from peer DTC brands, carrier-side experiences, app and email order updates, and the existing Ruggable pages annotated with what was working and what wasn't. The reference board became the team's vocabulary, so when we discussed concepts later, we could point at it.

Reference board collage of post-purchase tracking patterns from various brands and apps
Reference board · post-purchase tracking patterns gathered from peer brands, apps, emails, and carrier sites. Built first, designed second.
Insight from the references
The trackers that worked best treated each piece of order info as a modular unit (status, ETA, tracking, line items, address), not a fixed page layout. That framing pointed straight at a card-based system: composable, state-aware, easier to evolve.
03 · Concepts

The configuration space, not the directions.

The reference board pointed at a card system early, so the interesting question wasn't which approach. It was which configuration: what goes where, in what order, at what hierarchy. I worked through that exploration on both surfaces, with the same cards composed differently each time.

Mobile · top-area variants

On mobile, the variation lived almost entirely in the top section. The answer to "where's my rug?" had to come first, but how to compose ETA, status, and the product itself was open. Below the fold the content was identical across variants.

Mobile concept · expandable variant Mobile concept · swiper variant Mobile concept · third explored variant
Three mobile top-area variants. Same content, three ways to weight ETA, status, and product against each other.

Desktop · full-page variants

Desktop opened up at the page level. The variation moved to multi-item orders, where to slot promotional touts, and how to surface the latest update without burying the timeline. Each variant tested a different balance.

Desktop concept variant 1 — stacked estimated-delivery blocks for different states Desktop concept variant 2 — latest-update card and status timeline with sidebar tout Desktop concept variant 3 — multi-item layout where each line item carries its own status and tracking
Three desktop variants. The third (multi-item) became the direction. The information flow inside it kept evolving from there.

The resolved direction

We landed on the expand-and-collapse pattern. Each item card minimizes to a compact row by default and expands for the full tracking detail. It handled the multi-item case cleanly, kept simple single-item orders from feeling sparse, and gave touts and updates a stable home that didn't shift between states.

Resolved direction — multi-item order shown in both collapsed and expanded states
Same page, two states. The expand-and-collapse mechanic is what made the system handle every order shape with the same vocabulary.
04 · Building the cards

Listed every card before building one.

Before drawing any UI, I listed every card the system would need: order status, ETA, tracking number, line items, payment summary, customer service link, delivery address, exception messages, line-item drilldown, shoppable upsell. The list kept me organized as I worked. I could see what each configuration was missing, drop in new cards when ideas came up, and decide which earned a spot in the final set. MVP scoping became a content decision rather than a layout one.

I designed each card individually (default, empty, edge cases), then assembled layouts from them. Each state got its own configuration: order received, label created, shipped, out for delivery, delivered, delayed, returned, plus the logged-in / logged-out variants and a handful of error states. Some cards earned a permanent slot. Others got pulled into MVP-deferred (line-item drilldown, shoppable elements, how-to LP links) so we could ship the most important cards first and add the rest later without redesigning the page.

Card library — every card type grouped by purpose (card states, timeline states, multi-item imagery, logged-out, any product type)
Card library. Every card type grouped by purpose, with MVP-shipped and deferred variants both visible so scoping was a content conversation rather than a layout fight.

Team review & CX feedback

Two or three solid configurations went to the team, PM and my UX lead first, then CX. CX feedback was mostly content-level: phrasing, hierarchy, copy that read like a person rather than a system. Because CX had been in the loop as observers from the early rounds, the formal review was a tightening pass rather than a reset.

Cross-team note
One non-design challenge: the new states needed a unified source of truth for order data, which engineering had to wire up across internal systems. They led that integration; my job was to design the surface that would consume it cleanly.
05 · The solution

One order can be many shipments.

A Ruggable order isn't always one box. Items get grouped onto shipping labels and bundled into the parcels they actually travel in, so a customer who ordered several rugs can end up with three or four shipments, each one moving on its own schedule. The redesigned tracker stacks each shipment as its own card: a plain-language status up top, expandable to the full timeline and the items inside it when the customer wants the detail.

We designed for the worst case on purpose. The old tracker assumed the simple order, one box, one timeline, and fell apart the moment a customer ordered a lot. Building the stacked, expandable pattern around the messy order first meant the simple order was just the one-card version of the same system, not a separate design.

Redesigned order tracker showing one order split into multiple shipments, each stacked as its own expandable card with its own status
One order, three shipments. Each label stacks as its own card with its own status, expandable to the full timeline and the items inside.

Language that calms the wait

The biggest copy work happened in the in-between states, the days after a customer submits their order but before the package physically ships. That gap is where anxiety builds: "is my order actually being made? did anyone see it? when does this turn into a tracking number?" The old page just said "Order Received" and went quiet.

The new copy answers the unasked question. Each state surfaces an expectation the customer would otherwise email about, things like "typically ships within 1 week" or "scheduled to ship by Jan 8", paired with the status itself. Same data the system always had; we just decided to say it out loud instead of leaving it implied.

Order Received state — copy detail showing typical ship-by date and scheduled ship date
Pre-ship "Order Received" state · the language layer that did most of the WISMO work. Customer knows what to expect before they think to ask.
06 · Mobile

A true mobile experience, not a port.

Per the data team's analytics, a significant share of order-tracker traffic was mobile. I didn't design mobile first, but I treated it as a real surface. Single-column, generous tap targets, one primary action per state, and content prioritized for the smaller view. Mobile got the same care as desktop, not a shrunk-down version of it.

Mobile · Order Received state with typical ship-by date
01Order received
Mobile · Out for Delivery compact state
02Out for delivery
Mobile · Out for Delivery with drawer expanded showing tracking, address, and order details
03Drawer expanded
Three mobile states. The compact view (1, 2) shows status and the answer to "where is my order?" first; tapping the order item raises a drawer (3) with the supporting detail that lives in the desktop sidebar.
Mobile pattern
On desktop, supporting detail (tracking number, address, line items) sits in a sidebar next to the timeline. On mobile, that content lives in a drawer that slides up when the customer taps the order item. Same information, surfaced only when needed. The default screen stays focused on the answer to the question that brought them here.
07 · Outcomes

The ticket pile shrunk.

After ship, our PM tracked WISMO ticket volume and ticket types against the old experience. Within 90 days, the result was clear.

Headline result
28%
Drop in WISMO ticket volume against the old experience.
90 days post-launch
Self-service resolution
3.2×
Post-ship "where is it" emails
100%↓
Post-purchase NPS
+11 pts

Post-ship "where is my package" inquiries were effectively eliminated; the remaining ones are edge cases the page deliberately escalates. CX redirected the saved hours into proactive damage-claim outreach.

08 · Reflection

What I'd do differently.

What worked

Listing the cards before composing.

Building the card library as a complete set first (including ones we knew wouldn't ship in MVP) made composition fast and made scoping a content conversation rather than a layout fight. Adding a deferred card later doesn't redesign the page; it slots in.

What I'd change

Push for more than MVP.

I'd advocate harder for the deferred cards in the first ship. In my experience, "we'll ship that next sprint" often becomes "we'll get to that eventually." Priorities shift, new tickets land, and the deferred work quietly goes dormant. Holding the line on a slightly bigger v1 sometimes saves you from never shipping v2.

Open question

How much should the page be proactive?

We held back optional "we're watching it" notifications on stale states. The tradeoff is notification fatigue vs. reassurance. Worth A/B testing whoever picks this up next.

What's next

The card system has reach.

Returns and damage claims have the same problem: lots of data, no story. The same card pattern, with different content, is the obvious next application. It doesn't have to be redesigned, just composed differently.

Next case study
Ruggable · 2024 · PDP

PDP Drawer. Picking a size shouldn't feel like guessing.

Moved size and system selection into a right-side drawer to clear above-the-fold clutter and open room for richer guidance. Shipped on Flatwoven and Tufted desktop in August 2024, then expanded across the catalog.

Read PDP Drawer
Redesigned PDP, drawer closed