Work / Shipping Planning & Reporting
Not built
Shipping Planning & Reporting
A planning and reporting tool for the Shipping Department. I built it as a clickable prototype with Figma's AI tool, then checked it for ease of use and accessibility and improved it.
Problem
Shipping schedules didn't line up with production or jobsite readiness, and exceptions lived across too many tools and people. The result was late trucks, out-of-order deliveries, and costly claims.
My Role
UX Lead for the Shipping Department redesign.
Tools
Figma Make (Figma's AI tool that builds clickable prototypes) · Figma · NN/G heuristics (Nielsen Norman Group's well-known usability rules) · WCAG 2.2 AA (the web accessibility standard)
Outcome
A 19-screen clickable prototype, a UX audit with 18 findings, 7 refined screens (record panels included), and a reusable component library with accessible colors and text styles. Not built: development hadn't started when I left the company. Everything is documented for handoff.
Understanding the shipping problem
IT was looking for a quick win for the Shipping Department. I worked from the department's own list of pain points, and seven recurring problems stood out. Here's each one, what the module does about it, and where:
Shipping schedules don't line up with production and jobsite readiness. What the module does: load-ready risk is a top-level dashboard tile, and each order has planning stages and a checklist, so "ready" is visible before a truck is booked. Where: Dashboard, Order Pipeline.
Shipments loaded in the wrong order cause construction delays downstream. What the module does: orders are sorted by ship and delivery dates, and each one shows whether it's linked to a shipment in the transportation management system, so gaps in the sequence show up early. Where: Order Pipeline.
Missing, damaged, or wrongly documented materials lead to costly claims. What the module does: every exception records its fault, root cause, and notes. Notes survive new data imports, so a claim has a paper trail. Where: Needs Attention, shipment record.
Truck delays and inefficient loading cut transportation productivity. What the module does: the carrier scorecard ranks on-time pickup and delivery against a target, and Costs flags high cost per mile and loads over benchmark. Where: Carrier Scorecard, Costs.
Scattered communication makes shipment exceptions hard to resolve. What the module does: one work queue with owners, bulk assign, and saved views. Each record has contacts and an activity log with notes. Where: Needs Attention, records, Carrier Profile.
Physical loading limits and transportation compliance complicate dispatch. What the module does: this is execution work, so it stays in the existing dispatch tool. The module shows weight and estimated trucks, then hands off with a link that opens the dispatch tool. Where: the handoff to the dispatch tool (see "Defining the quick win" below).
Unpredictable material availability and production changes break shipping commitments. What the module does: at-risk loads are ranked by severity, with a milestone tracker, and the top bar always shows how fresh the data is. Where: At Risk, the app bar.
None of these could be fixed by one screen. They pointed to a shared problem: the people planning shipments couldn't see risk early enough, and when something went wrong, nobody clearly owned it.
Key insights
Readiness must be visible before dispatch. Several problems started upstream, in production timing and material availability, but only showed up once a truck was late.
Exceptions needed an owner. Communication was scattered. Without a clear owner and history, exceptions were hard to track down and resolve.
Execution already had a home. The existing dispatch tool already handled truck assignment and loading. Rebuilding those tools would have slowed the quick win down.
Defining the quick win
To deliver value fast, I drew a clear line around the product. The new Planning & Reporting module would cover planning, schedules, exceptions, performance, and cost. The existing dispatch tool would keep truck assignment, loading, staging, and shipment creation.
Planning & Reporting module
What this redesign covers:
Order planning status and links to shipments
Schedules for visibility (load, pickup, delivery)
Exceptions: Needs Attention, At Risk
Performance: carrier scorecard, reports
Costs and lane analysis
Owners, notes, contacts, and activity
The existing dispatch tool
The existing tool, unchanged:
Truck assignment
Loading board
Load staging
Shipment creation
Corrected shipments
Hands-on actions in the transportation management system
Wherever someone needed to move from reviewing to doing, the design hands off with a link that opens the dispatch tool. Two physical issues, loading limits and compliance, stayed in the dispatch tool as execution work. The module shows the information that feeds those decisions, such as weight and estimated trucks.
Design
I started from the business users' own prototype and kept their terminology and report structure. Then I rebuilt it in Figma Make as a full desktop prototype with 19 screens in seven groups:
Overview: Dashboard
Planning: Order Pipeline, Purchase Order Report, Shipment Links
Schedules: Load, Pickup, Delivery
Exceptions: Needs Attention, At Risk, Missing Milestones
Performance: Load Ready, Pickup and Delivery reports, Carrier Scorecard
Financials: Lane Report, Costs
Data: Imports, Column Map, Backup
The first design focused on:
Bringing planning, exceptions, and cost into one place
Keeping the dense, row-level tables business users relied on
Calming the "button wall" and stacked colored bars of the original
Using color by meaning: navy for actions, orange for warnings, red for critical, green for complete
Staying compatible with the dev team's Material 2 / MudBlazor components
UX audit
I audited the prototype against Nielsen Norman Group's 10 usability heuristics, NN/G's dashboard and table guidance, and WCAG 2.2 Level AA, rating each finding on NN/G's 0–4 severity scale. The audit found 18 issues:
2
Catastrophic
8
Major
7
Minor
1
Cosmetic
Three themes stood out:
Accessibility was the biggest gap. Labels were 9–11px. Gray helper text measured 2.3:1 contrast, against a required 4.5:1. Status was shown by color alone: red, orange, and green dots, donut charts, and colored percentages.
The dashboard had no priorities. Eight metric cards had equal weight and none had targets. A drop of "↓ 2.1%" didn't say whether it meant percent or points, or whether it mattered.
Records were hard to work in. Owner, notes, and root cause sat on tab 7 of 8 in a narrow panel. "Unassigned" was shown in faded gray, with no way to act on it.
Refined design
I created 7 refined screens, record panels included, using a small set of shared components: status chips, metric cards, the app shell, and record panels. Every text color passes AA contrast, and every status pairs color with a shape and a word.
Leads with a "Needs action" band, ordered by urgency. Performance metrics show the number, the change, and the target, for example "Down 2.1 pts · target 95%". Donut charts became labeled bars that are easier to compare.
Screens are studio redraws. Names and data are invented.
Eight summary cards and eight duplicate tabs merged into one row of planning stages that doubles as the filter. The order record works like a customer record in a sales tool (CRM, or customer relationship management): owner first, then key facts and a planning checklist.
Before
After
Exceptions became a true work queue, grouped by priority. Saved views include "Assigned to me" and "Unassigned," and bulk actions let users assign an owner, set a root cause, or mark items resolved.
A five-step milestone tracker uses icons and plain language, such as "1h 30m late" or "3 days overdue," instead of colored dots. Fault and root cause are labeled fields, and saved notes survive new data imports.
Carriers ranked by on-time delivery, each with an inline bar against a 95% target marker and a status chip. Each carrier's late loads are split into late pickups and late deliveries, so it's clear where the delays happen. Four export buttons became one Export menu.
A record page per carrier: an 8-week on-time trend against fleet average and target, open issues, top lanes, and an activity log for calls and notes.
Cost exceptions open a review panel that shows the variance up front ("$6,400 over target rate (+32%)"), compares rates side by side, and includes a review form with owner, status, and notes.
Design Outcomes
The redesign wasn't built, but it left a clear, accessible direction for the Shipping Department. Every pain point has a defined response, the boundary with the dispatch tool is clear, and the component library is ready for development.
Figma Make let me turn the business users' rough prototype into a full 19-screen experience quickly, and AI sped up the audit and the Figma rebuild. Every finding and design decision still needed my judgment to match real shipping workflows and accessibility standards. AI can speed up the work, but deciding what's right for users is still a human job.
7 pain points mapped
Each problem on the Shipping Department's list has a specific design response or a deliberate handoff to the dispatch tool.
18 audit findings
Rated against NN/G heuristics and WCAG 2.2 AA. The 2 catastrophic and 8 major issues are addressed in the refined screens.
19 → 7 refined screens
A full Make prototype, then 7 refined dashboard and record screens (record panels included), built on reusable components.
Learnings
A quick win needs a clear boundary. Defining what the module would not do (truck assignment and loading) kept the scope small enough to deliver.
Accessibility is a priority from day one. Small text and color-only status were the most serious problems. Fixing them improved the design for everyone, not just users with disabilities.
Dashboards should start with what needs action. Counts without targets or owners don't tell anyone what to do. Grouping by urgency and adding context turned the dashboard from a report into a to-do list.
If the project resumed
Test with the people who use it. Run task-based tests with planners and managers, such as "Find and assign every critical issue" or "Explain why one carrier's on-time delivery dropped."
Confirm the business rules. Check the on-time targets, scorecard bands, the OTIF (on time, in full) definition, and the cost-per-mile limit with Shipping and Finance.
Do accessibility QA in the build. Check keyboard order, sortable table headers, focus moving into side panels, and 200% zoom.
Extend the patterns to the remaining 12 screens, then define success metrics such as fewer late loads, faster exception resolution, and fewer claims.
Read more
Have a tool that needs this kind of attention? Let's talk about it.