LogiOps — Web UI/UX Design Case Study

A concept built with the Carbon design system, using the real v11 kit: its components, its tokens, its data table, its UI shell. The product is an internal tool for a logistics operations team, and it follows one story the whole way. A shipment is delayed. Someone finds it, understands why, fixes it, and tracks the fix.

The LogiOps operations overview: five KPI tiles, a shipment health donut, activity bars, critical exceptions and regional performance — The overview. Five numbers, and the three exceptions that matter today.

The dashboard is not a report. The critical exceptions card is a queue, and every row on it goes somewhere.

The shipment health card enlarged: the donut with 86% on time and its legend — Shipment health, closer.

The table

The main screen is a data table doing everything an enterprise table has to do: search in the toolbar, filters above, sortable columns with the sort shown, bulk selection, status as tags, and pagination that admits there are 2,761 pages.

The shipments screen: filter dropdowns, a searchable data table with selection checkboxes, status tags and pagination — Shipments. One row is already selected; the delayed one.

One shipment

The detail page answers the first three questions in order: how late, why, and when instead. The timeline marks the exact step where the day went wrong.

Shipment details: a warning notification, a vertical timeline with an error step, current status and shipment information — SHP-28490. The old ETA is struck through, not deleted.

The shipment timeline enlarged: completed steps, a delay marked in red, and the two steps still pending — The timeline, closer. The error state comes from the component itself.

The exception workspace

Delayed shipments are not a filter, they are a workqueue with owners. Two rows have nobody; the blue link is the ask.

The exceptions workspace: a content switcher for scope and a table of exceptions with duration, priority tags and owners — Exceptions, sorted by how long they have been burning.

Opening one is the hero screen. The problem in one sentence, the cause under it, the blast radius as three numbers, and the fix as an ordered list with a button on each step.

Exception details: problem statement with cause, impact metrics, related information and three recommended actions with buttons — EX-2841. Decision support, not a log viewer.

The problem card enlarged: the delay statement and the reason it happened — The problem card. The why is written by the system, read by a person.

The recommended actions enlarged: three numbered steps, each with its own button — Step 1 clears the SLA risk for 31 shipments, so it goes first.

The fix

Assigning a vehicle needs the fleet, so the fleet screen exists to serve that moment. The available vehicle is already selected, and the panel ends in the only button that matters.

The fleet screen: a vehicle table with status tags and a side panel showing vehicle details, health and an assign button — VH-1832, available, 2.1 km away.

The vehicle details panel enlarged: driver, location, health bar, recent trips and the assign button — VH-1832, ready to take the load.

Analytics

Kept simple: four KPIs, one trend, and two ways of slicing the trouble. The charts use the system’s data visualization palette.

The exception types donut enlarged, with the categorical palette and counts — Exception types, closer.

Dark, from tokens

The dark theme is not a repaint. Every fill and every text on these screens is bound to a theme token, so the dark set is the same frames with the theme collection switched to Gray 90. Components, tags, tables and charts follow on their own.

The operations overview in the Gray 90 dark theme — The same overview. One variable mode changed, nothing redrawn.

The shipments data table in the dark theme

The exception details screen in the dark theme

Seven screens, both themes, and a wired prototype for the one flow that matters: dashboard to exception to cause to vehicle to resolved.