OptimalShip · Shipping/Logistics · Platform Design
Three product surfaces redesigned for OptimalShip, a USA-based shipping provider: marketing site, quote and tracking tools, shipment preparation dashboard.
Shipment preparation reduced from over 20 steps to 4–5.
I led design across the engagement, working with C-level, the head of customer support, and engineering.
OptimalShip is a USA-based shipping provider based in Allen, Texas. Authorised DHL service partner. Multi-carrier operation across DHL, UPS, and FedEx. Domestic and international freight.
Every customer interaction ran through a phone call. Customer service representatives prepared shipments, provided quotes, handled tracking, scheduled pickups. The business operated on human labour applied to regulatory complexity, transaction by transaction.
The operational expertise lived with CSRs. Customs documentation rules, carrier-specific policies, residential versus commercial addressing, hazardous goods classification, international tax, dimensional weight calculation. That knowledge was held by people, delivered through conversation, carried in the CSRs' heads.
Customer service was the product. The business sold a CSR's ability to move a shipment through complexity on the customer's behalf.
OptimalShip had built a prototype internally to digitise the shipment preparation flow. The result was a 20+ step process with confusing flows, frequent user errors, restart loops, and a CSR team still handling the overflow. The internal team recognised that what they had built did not solve the problem.
I was brought in as lead designer to resolve the platform problem.
The engagement covered three surfaces of the OptimalShip ecosystem: marketing site for acquisition, quote and tracking tools for conversion, shipment preparation dashboard for retention. I led design across all three. On the marketing site phase, a junior designer reported to me.
The engagement ran sequentially across the three surfaces. I started part-time on a defined design scope and moved to full-time as the work expanded beyond design into operational and strategic decisions. By the later phases, I was in C-level meetings on product roadmap and product development.
The research was diagnostic. The internal prototype had captured the forms without capturing the judgment CSRs brought to each transaction. The actual customer journey had to be surfaced, structured, and made transferable to software before any new design work could begin. That included the parts CSRs had always handled verbally.
Workshops and expert interviews with shipment preparation specialists and the tech lead. Mapping decision trees, customs and regulatory variation, friction points, error modes. Capturing what CSRs did on the phone that the prototype had not captured in screens.
Eight proto personas across three commercial relationships: Client, Guest, Visitor. Structured from OptimalShip's existing understanding of their customer base through expert interviews with customer support leads and the CEO. Each persona defined by shipping behaviour, access rights, billing method, and business value to OptimalShip. A structural model of who the users were.
Approximately ten shipping and logistics platforms analysed as full content trees, ShipHero among them. Pattern extraction across landing page structure, product presentation, pricing transparency, customer evidence, and support-flow integration.
Analytics integration was my push. The team was making design decisions from guesswork. I argued for Google Analytics, Hotjar, and Heap to be integrated into the product. Ground truth about user behaviour, funnel conversion, and where the product's actual problems lived. The payment flow diagnosis that follows was only possible because of this decision.
Initial analytics showed a high drop-off at the step immediately after payment. The surface-level reading was that the post-payment step had a design problem. I went into Hotjar session recordings and found the actual pattern. Users were confused at the payment step itself, proceeding to the next step in the hope that it would clarify, and dropping when it did not. The root cause was a specific OptimalShip payment policy. CSRs had historically explained it by phone, building trust around it in real time. Software, by its nature, had no equivalent moment for that explanation. The research surfaced a business policy problem that the software alone could not resolve.
The research produced a structural model of the customer lifecycle, grounded in user-type structure, behavioural evidence, and commercial reality.
A three-part lifecycle architecture. User-type structure. Critical Events. Retention framework. Three standard product frameworks applied to OptimalShip's specific commercial reality. The judgment was in knowing which three this business needed. The rigor was in how they were connected and applied across three surfaces.
Three user tiers: Client, Guest, Visitor. Each with distinct access rights, billing methods, and commercial value. The Visitor has no account and is evaluating the provider. The Guest can access quoting and shipment preparation up to the payment step without registering. The Client is signed in, billed on Client rates, and has full access to the shipment preparation tool. The intended progression is Visitor to Guest to Client. Each surface supports that movement.
Critical Events. The commercial milestones the business measured, defined against specific tools and user types. Quote Tool: User Gets a Quote. Ship Prep Tool: User Prints Labels. Quick Quote Tool: User Gets a Quick Quote. Each event tied to user type. Each event measurable.
The retention framework. A four-state model of user activity across time intervals: New, Retained, Resurrected, Churned. The retention cycle made explicit: active users are new users plus retained users plus resurrected users. The model exposes the movement beneath a single active-user number.
Supporting the three frameworks: financial cohorts (Uptrader, Downtrader, Stable, Lost 1 Month, Lost 3 Months), persona cohorts mapped against real user behaviour, and a metrics glossary covering DAU, WAU, MAU, CAC, LTV, ARPU. Operational language defined as part of the model.
The model gave the engagement a single language across all three surfaces. The same three user tiers govern the marketing site routing, the quote tool access model, and the shipment preparation tool's permission layer. The same Critical Events appear in the analytics schema, the personas' goals, and the UI copy. Three surfaces operating as three views of one customer lifecycle.
User Tiers // Critical Events // NRRC
Marketing Site
Quote & tracking
Customer dashboard
The lifecycle model runs across three surfaces: acquisition, conversion, retention. Each operates on one governing principle that follows from its function.
The marketing site carries the acquisition function. Governing principle: fast routing. The Visitor arrives with no account, no context, and limited time. The site establishes OptimalShip's credibility and capability, then routes the Visitor to the right digital tool without detour. Information architecture structured around five navigation sections and a parallel homepage hub. CSR access embedded on every touchpoint, because CSRs were the bedrock of OptimalShip's experience.
The quote and tracking layer carries the conversion function. Governing principle: transparency replaces trust-through-human-contact. Multi-carrier quote comparison with pricing breakdown. Guest versus Client rate differentiation built into the quote flow. Messaging system tiered by severity, with escalation paths to CSR preserved where the software could not carry the interaction. Standalone pickup scheduler independent of shipment creation. Quick tracking as a first-class surface.
The Shipment Preparation dashboard carries the retention function. Governing principle: users should never lose their work. The shipment preparation flow reduced from over 20 steps to 4–5. Transparent decision architecture: users review and edit previous inputs at any stage, without restarts, without data loss. Contextual customs guidance embedded where regulatory complexity created friction. Shipment preparation tool surfaces covering shipment creation, scheduled pickups, shipment status, tracking history, and drafts.
The three surfaces share a user model, a permissions model, and an event schema. A Visitor arriving on the marketing site, converting via the quote tool, and preparing a shipment in the shipment preparation tool is one customer traversing one lifecycle. The software treats that journey as continuous. The CSR team is no longer the integration layer.
A modular design system spanning all three surfaces. Package fields, currency fields, pickers, switches, form states, dashboard surfaces, marketing-site components. Built for iteration speed and cross-surface consistency.
Online usability testing conducted with CSRs and customers. Screen-shared sessions, recorded observation, documented behaviour.
Logo redesign as part of the engagement. A new logotype replaced a dated italic wordmark. A place-based colour system: Texas Red, Dallas Black, Allen Grey. Brand identity anchored to where the business operates from.
Custom illustration set covering shipment, money, packaging, delivery, and support. Deployed consistently across marketing site and platform. Tone: warm, grounded, human.
Design system components built for direct implementation. Agile delivery across a multi-phase engagement. Handoff coordinated with engineering throughout.
Research findings surfaced a business policy problem that affected user conversion. OptimalShip acted on the finding. By the later phases of the engagement, I participated in C-level meetings on product roadmap and product development.
The platform is live and in use. The business continues to run on it.
20+ → 4-5
Steps in shipment preparation
CSRs released
Shifted from integration layer to support function
A shipping business that ran on human labour now runs on a system designed to carry the full customer lifecycle.