Shipping Intelligence
Platform
A dual-portal B2B logistics intelligence platform serving both merchants and carrier partners. Shipment tracking, exception management, automated claims, carrier performance analytics, and an embedded AI layer. Built as an investor-ready prototype targeting a mid-2026 launch.
Role
Lead Product Designer
Collaborator
Founding team
Timeline
Apr 2026 — Jun 2026
Status
Live Prototype
Cross-functional Team
Solo designer
Tools
Product Walkthrough
A guided walkthrough of both portals: the merchant dashboard and the carrier operations portal.
The platform was built as a fully functional React prototype across sixteen pages spanning two separate portals. Every screen shown here was built in code and used in live client demos and investor presentations.
Want a live walkthrough of both portals? Get in touch and I will walk you through every module in a 30-minute session.
Two sides of the same broken relationship.
The founding team came with a clear market thesis: ecommerce merchants shipping across multiple carriers had no unified view of their logistics operations. They were toggling between carrier portals, spreadsheets, and support emails to understand what was happening with their shipments, and losing money on exceptions they never caught and claims they never filed. The initial brief was a merchant-facing dashboard.
I was the sole designer on this project. Product direction, information architecture, interaction design, and build sequencing were all driven by me in direct collaboration with the founding team.
What changed the scope of the project was a question asked early in the engagement: if the platform was going to sit between merchants and carriers, what was the carrier's experience of that relationship? The answer was that carriers were equally underserved. No platform offered them earnings transparency, a structured claims response process, or a purpose-built operational tool for dock-level scanning. A single-sided product was only solving half the problem.
The build scope expanded from one portal to two. The merchant dashboard and the carrier operations portal share a single design system and data layer but were designed as entirely separate products for entirely different users, physical contexts, and success metrics.
System first. Pages second. Always.
The build followed a strict dependency order. Data architecture and TypeScript interfaces were defined before any UI. The design system was documented before any component was built. Shared components were assembled before any page was composed from them. This sequence meant that by page six of sixteen, every design decision was an arrangement of proven primitives rather than a net-new problem.
Project phases
Data Architecture and Design System
Defined all TypeScript interfaces, mock data structures, and data relationships before any screen design. Established the full design token system covering color, typography, spacing, and component patterns before building a single page.
Shared Component Library
Built KPI cards, status badges, alert banners, empty states, and table primitives before any page. Every subsequent screen was composed from these components. This approach compressed the build timeline significantly. Pages four through sixteen were faster than pages one through three.
Merchant Portal Build
Eight pages built in dependency order: overview establishing the visual language, then shipments as the highest-frequency use case, then exceptions and claims, analytics, AI insights, billing, settings, and managed agents. Each page deployed and reviewed before the next was started.
Carrier Portal as a Parallel Product
Full competitive analysis, persona definition, and product requirements documentation completed before a single carrier page was designed. The carrier portal was treated as a distinct product brief, not a reskin of the merchant portal. Eight pages built across overview, scan station, shipments, performance, claims, earnings, and rate card.
Merchants could see their orders. They could not see their logistics.
Every carrier its own portal. Every channel its own data. Nothing above them all.
Multi-channel ecommerce merchants selling across platforms simultaneously had a structural visibility problem. Each carrier operated its own portal. Each sales channel reported its own fulfillment data. There was no single layer that aggregated across all of them. There was no unified way to know which carrier was underperforming, which region was slow, which exceptions needed attention today, and what those exceptions were costing.
The cost of this invisibility was concrete. Claims for lost or damaged shipments were filed late or not at all. Carrier overbilling went undetected because reconciliation was manual and time-consuming. Regional hub delays were visible only after customers had already complained. And decisions about carrier allocation were made on intuition rather than performance data.
Existing solutions each solved a fragment of the problem. Order management tools handled fulfillment workflows but had no analytics layer. Carrier portals showed data but only for their own network. Infrastructure APIs provided data pipelines but had no merchant-facing interface. No product sat at the intelligence layer above all of them.
Core insight cards
The merchant was not the only underserved user
Carriers had no platform that gave them earnings transparency, a structured process for responding to claims, or a purpose-built tool for dock-level scanning operations. The platform's value proposition required both sides of the shipping relationship to be well-served. A merchant-only product would have been incomplete.
Exception management was reactive by default, not by design
Merchants were discovering exceptions after customers had already complained rather than before. The opportunity was not to speed up the response to exceptions. It was to surface them early enough to resolve them before they became customer service problems.
Channel-level performance data did not exist anywhere
Merchants selling on multiple platforms simultaneously had no way to compare logistics performance by sales channel. The platform's channel-level filtering capability addressed a gap no competitor had identified.
The right problem. Some wrong assumptions about how to solve it.
Research combined recorded client meeting transcripts as the primary source of product decisions with competitive analysis across the existing market of order management tools, carrier portals, and logistics intelligence platforms. Every significant design decision was traceable to either a client conversation or a specific gap identified in the competitive landscape.
Three findings that shaped the design
No competitor addressed the carrier side of the relationship
Competitive analysis across the major platforms confirmed that carrier-side earnings transparency with direct bank payout did not exist anywhere in the market. Every platform treated the carrier as a data source, not as a user. This was the platform's most defensible differentiator and it came directly from the research phase rather than the initial brief.
Speed to value had to take priority over completeness of onboarding
The initial assumption was that onboarding should walk users through a complete setup before showing them any data. The research finding was that merchants needed to see value immediately to trust the platform. The onboarding was redesigned to use sign-in as the primary action, route users directly to a populated dashboard, and defer store connection to a welcome modal that did not block access.
The scan station required designing for a completely different physical context
Every other screen on the platform was designed for a seated desktop user with a keyboard and mouse. The carrier scan station was designed for a standing operator with a scanner gun in a noisy dock environment. The success metric was not task completion rate. It was peripheral vision confirmation with zero friction between scans. No competitor product had designed for this context at all.
The decisions that were actually hard.
Several decisions on this project had two or more valid approaches with genuinely different consequences for how the product would be used. These were not aesthetic choices. They were product decisions with design implications.
Decision 01
Dark sidebar with light content area over full-light or full-dark
Three options were evaluated: full-light, full-dark, and split. Full-dark was rejected because it reads as consumer or gaming rather than operational B2B. Full-light loses spatial hierarchy between navigation and content. The dark sidebar paired with a warm content background creates the clearest visual separation between where you are and what you are looking at, which is the primary function of navigation in a dense data product.
Decision 02
Carrier abstraction in merchant-facing UI
The merchant portal never shows carrier brand names. Carrier services appear as generic service tiers instead. This was not a legal decision. It was a product positioning decision. The platform is the relationship layer between merchants and carriers. Showing carrier logos in the merchant portal would make it read as a carrier portal aggregator rather than an independent intelligence layer. The abstraction rule is implemented as a constant mapping applied uniformly across all merchant-facing components.
Decision 03
Exception count as a product positioning decision
The demo data shows four unresolved exceptions, not fifty-eight. This was a deliberate choice. The platform's competitive positioning is built around the concept of near-zero unresolved exceptions. Demo data that showed a large exception backlog would have undermined the core product claim. Mock data values are product decisions, not placeholder content.
Decision 04
Scan station as a full-screen operational tool, not a dashboard panel
The carrier scan station could have been designed as a panel inside the standard dashboard layout. It was designed as a full-page tool with a three-panel layout because the use case was entirely different: a standing operator scanning packages at high frequency needed the scan input zone centered and large, the manifest progress visible at a glance, and the confirmation feedback visible without reading. The full-screen color flash on each scan result provides peripheral vision confirmation that works at a distance.
Decision 05
Volume-gated onboarding with immediate dashboard access for both paths
The platform needed to serve both self-serve merchants and enterprise accounts. The decision was to gate by volume at onboarding. Below threshold routes to self-serve, above threshold shows a contact confirmation. Both paths land on the live dashboard immediately. No path blocks access. The enterprise path shows a message that the team will be in touch, but never prevents exploration. Speed to value was more important than completeness of qualification.
Two portals. One system. Sixteen pages.
The platform deployed as a fully functional prototype across two separate portals sharing a single design system and typed data layer. Both portals were built to investor-demo and client-presentation quality across every screen.
0
portals
0
pages
0
design system
Eight surfaces for merchant operations
Overview
Full logistics command center
Four KPI tiles covering on-time delivery rate, exception volume, claims recovery, and average delivery time. Sales channel filter pills for per-channel performance breakdown. Action-needed cards surfacing the highest priority items. Shipment map with AI alert overlay. Carrier performance comparison and exception breakdown panels.
Shipments
Volume trends and full shipment detail
Volume trend chart, status breakdown bar, full shipments table with channel identification, and order detail view with complete event timeline and proof of delivery.
Exceptions and Claims
Proactive exception surface with auto-filed claims
Consolidated exception summary, trend chart, carrier breakdown table, auto-filed AI claims feed showing claims resolved without manual intervention, and full claims management table.
Analytics
Hub-level drilldown and forecast chart
Regional performance cards with hub-level drilldown for major distribution hubs. Each hub shows specific root cause factors and performance against network average. Forecast chart with confidence range projection.
AI Insights
Attributed insight cards and escalation resolution
AI-attributed insight cards with topic filters, and an escalation resolution panel tracking the platform's progress toward near-zero unresolved exceptions.
Billing
Credits, payment, and savings summary
Credits balance, active payment card with spending limit visualization, backup payment enforcement panel, revenue versus cost trend chart, and savings summary.
Settings
Nine configuration tabs
Nine configuration tabs covering security with full two-factor authentication flow, multi-location address management, connected stores with channel logos, API key management, and notification preferences.
Six surfaces for carrier operations
Overview
Manifest progress and payout preview
Manifest progress tracker, per-route driver performance breakdown, payout preview with trend chart, and SLA compliance snapshot.
Scan Station
Full-screen dock-level scanning tool
Three-panel operational layout with scan input zone centered, recent scan history on the left, and manifest progress on the right. Full-screen color flash on each scan result provides peripheral vision confirmation. Five distinct scan result states. Damage report modal accessible inline.
Performance
Weighted scorecard and hub coverage map
Weighted scorecard with composite performance gauge, on-time delivery trend against network average, and hub coverage map.
Claims
Carrier-as-respondent with full response workflow
Carrier-as-respondent view with full response workflow, dispute escalation path, and platform decision states.
Earnings
Net-30 payout ledger and dispute modal
Net-30 payout ledger, bank connection panel, revenue trend chart, and line-item dispute modal for individual payout challenges.
Rate Card
Active rates and CSV upload with column mapping
Active rates table, CSV upload with column mapping preview, and aggregator connection panel.
A prototype detailed enough to spec the production build.
The prototype is live and being used for client demos and investor presentations targeting a mid-2026 launch. Every screen reached production-ready quality. The level of detail in the build was sufficient to generate the engineering specification for the production development team directly from the prototype.
The scope expansion from one portal to two was itself a product outcome. The decision to build the carrier portal emerged from the research phase rather than the original brief, and it became the platform's most differentiated capability. A product that serves both sides of the shipping relationship creates a compounding dynamic that a merchant-only tool cannot replicate.
The build process produced three living documents alongside the prototype: a full design system specification, a product requirements document used as the engineering handoff, and a session log tracking every scope and data decision made during the project. These artifacts are as valuable as the prototype itself.
What this project reinforced.
Building sixteen pages across two portals under demo timeline pressure compressed the feedback loop between design decisions and their consequences. Every data value, every abstraction rule, and every layout choice was visible in a working product within hours. That proximity between deciding and seeing the decision rendered changes how you make decisions.
Mock data values are product decisions.
The difference between four exceptions and fifty-eight is not a data choice. It is a positioning choice. Every number visible in a demo represents a claim the product is making about itself. Treating mock data as placeholder content misses this entirely.
Design tokens and shared components before any page, without exception.
By the time the build reached page ten of sixteen, every new page was an arrangement of existing primitives. The investment in system work at the start paid back many times over. Starting with pages and building the system reactively would have produced an inconsistent product by page four.
Two-sided platforms require two separate product briefs.
The carrier portal was designed correctly because it was treated as a distinct product with its own persona, use context, and success metrics rather than as a variation of the merchant portal. The scan station could not have been designed from a merchant-first mental model.
What comes next
Mobile-responsive layouts for merchants checking logistics on the go. Real map SDK integration replacing the SVG shipment map. Live carrier API connections replacing the mock data layer. HIPAA-adjacent data handling for any healthcare adjacency. The architecture was built to support all of this from day one.