Skip to content

( Envase Technologies / November 2020 – March 2023 )

Envase TMS

The platform turned a fragmented legacy operation into one cohesive enterprise product spanning the dispatcher's desk and the driver's cab, and connected the two in real time.

My role
Lead UI/UX Designer
Timeline
November 2020 – March 2023
Category
Enterprise SaaS Product Design (Web and Mobile)
Status
Redesign, delivered

Tools Figma, Figma Prototyping, Material UI (MUI), Envase Design System

Generated schematic standing in for imagery of Envase TMS. It depicts nothing.
Generated schematic, not a screenshot of Envase TMS.

Generated schematic, not a screenshot. Real imagery to follow.

( The account )

Context

Envase TMS runs freight operations for trucking companies and freight brokers in the intermodal and drayage space, the first and last mile of ocean freight where a driver moves a container between port terminals and its inland destination, or the reverse. It is a high-volume, time-sensitive, heavily regulated corridor, and it is coordinated by two very different groups of people. Dispatchers, operations, and billing teams work at a desk. Drivers work from a truck cab, a terminal gate, and a warehouse dock.

The platform serves both. The web back-office is the command center where the full shipment lifecycle happens, from order creation and dispatch scheduling through in-transit tracking and document management to invoicing and financial settlement, across ten core modules: authentication and onboarding, a dashboard, four record-management modules (customers, locations, equipment, personnel), two operations modules (order management and dispatch), configurations, and integrated chat. TMS Mobile is the driver-facing field companion, covering load lifecycle management, a guided multi-stop execution workflow, integrated compliance documentation, multi-method proof of delivery, order-linked messaging, barcode and QR scanning, load search, and a full authentication and onboarding flow.

These are not two products. They are two ends of one loop. Before this work the two halves barely connected: information sat in silos across spreadsheets, phone calls, and legacy desktop software on the office side, and across calls, texts, camera rolls, and paper clipboards on the driver side, with nothing linking them but a phone call. The project existed to consolidate both halves onto one modern platform and close the loop between them in real time.

The problem

Intermodal trucking ran on fragmented workflows at both ends of the business. Office staff managed orders, dispatches, equipment, and personnel across spreadsheets, phone calls, and legacy desktop tools, with no dashboard for shipments, margin, payables, or last-free-day countdowns. Drivers received assignments by call, text, or a separate dispatch app, photographed compliance paperwork into camera rolls, collected signatures on paper or skipped them, and re-keyed container and seal numbers from memory. Between the two sat a broken loop: dispatch had no live view of the field and chased status by phone, and every gap created missed deadlines, demurrage charges, billing delays, and gate rejections.

Discovery surfaced six problems that spanned both surfaces:

  • Operational fragmentation at both ends. Office staff managed orders, dispatches, equipment, and personnel across a patchwork of spreadsheets, phone calls, and legacy desktop tools. Drivers received assignments through calls, texts, or a separate dispatch app with no unified view of their day. Critical information sat in silos on both sides.
  • A broken loop between the field and the back office. Dispatch had no live view of what was happening at terminals and chased status by phone. Managers had no central dashboard for KPIs like total shipments, weekly revenue, margin, accounts payable and receivable, or last-free-day countdowns, which led to missed deadlines, demurrage charges, and revenue leakage.
  • Cumbersome master data management. Customer records (credit checks, BOL and HAZMAT documentation, trade and bank references), locations, equipment (tractors, trailers, and chassis with VINs, plates, and lease status), and personnel (driver HAZMAT, medical, and drug-test compliance) were error-prone and scattered across systems.
  • Complex order workflows and error-prone data entry. Intermodal orders carry many data points (container sizes, equipment types, vessel and container availability, live or drop status, overweight, HAZMAT, expedite, and temperature flags), and moving them through status transitions while assigning drivers day by day was manual. In the field, container numbers, chassis IDs, and seal numbers were handwritten or typed from memory, and transcription errors cascaded into terminal gate rejections, detention charges, and misrouted freight.
  • Document, compliance, and proof chaos. The industry demands extensive documentation, from bills of lading to terminal interchange receipts to HAZMAT certificates to weight tickets and medical exams. Drivers photographed paperwork into their camera rolls and submitted it hours or days late. Signatures were collected on paper or skipped entirely, so delivery disputes often had no verifiable record. Without centralized document management on the office side, companies carried audit risk and billing delays.
  • Communication disconnected from the work. Dispatchers, drivers, and customers coordinated over phone calls, personal texts, and email, so conversation history was never tied to the orders it referenced and accountability gaps opened up.

What I did

The platform was designed as one system with two surfaces rather than a web product and a mobile product that talk to each other. That principle shaped every structural decision: the shared spine came first, and each surface was designed as the right expression of that spine for the person using it.

The shared spine is the order lifecycle. On the web, it runs as an explicit six-stage status pipeline (Dispatched, In Transit, Completed, Missing Paperwork, Approved for Billing, Invoiced) with count badges for instant operational visibility, and order events link directly to revenue items and payables. On mobile, the same lifecycle appears to drivers as four states with context-aware actions at each step. Load states, document types, and data structures were aligned across both, so every field action becomes a timestamped update the back office can act on rather than a message someone has to relay.

On that foundation, each surface then got the treatment its context demanded. The web platform standardized ten modules on Material UI so they shared one component vocabulary, one navigation shell, and one visual language, with a command-center dashboard on top for real-time operational and financial visibility. The mobile app was built around stop-level execution on the Envase Design System, governed by five principles: surface one thing at a time so primary actions appear only when the driver needs them (Arrive, Add Items, Upload Documents, Sign, Depart); reduce typing by scanning instead; prompt rather than assume; capture proof flexibly; and keep context together by tying chat to order IDs and documents to specific stops. The result is a single cloud platform that replaced spreadsheets, phone calls, legacy desktop software, camera rolls, and paper clipboards with one connected operation.

Outcomes

  • Consolidated fragmented workflows on both sides of the business (spreadsheets, phone calls, and legacy desktop tools in the office; calls, texts, camera rolls, and paper clipboards in the field) into a single connected platform.
  • Closed the loop between field and back office, turning each driver action into a timestamped status update visible on the dispatch board without a phone call.
  • Gave managers real-time operational and financial visibility through a command-center dashboard covering shipments, revenue, margin, accounts payable and receivable, and last-free-day countdowns.
  • Streamlined the full order lifecycle from creation through dispatch, execution, tracking, and invoicing with an explicit status pipeline that made operational state legible at a glance from either surface.
  • Created a clean digital compliance record by attaching documents to specific loads and stops, prompting for pending uploads before departure, and centralizing document types and upload queues on the back-office side.
  • Established verifiable digital proof of delivery through four signature methods that adapt to real-world delivery sites.
  • Structured DOT compliance into the platform through driver qualification tracking (HAZMAT, medical exams, drug tests) and compliance-aware customer, equipment, and location records.
  • Reduced transcription errors at terminal gates by letting drivers scan container, chassis, and seal numbers instead of typing them.
  • Supported demurrage cost control through last-free-day monitoring and container-availability tracking, and faster billing by linking order events directly to revenue items and payables.
  • Established a reusable Material UI component architecture that accelerated frontend development by replacing duplicated, one-off UI with a shared library.

What I learned

Designing both ends of a workflow surfaced problems that neither end could see alone. Dispatchers and drivers described the same broken loop in completely different vocabulary, and it was only in putting the two accounts side by side that the actual system problem became legible. Owning both surfaces was the advantage; the shared state model came out of that vantage point, and it is the decision the whole platform rests on.

The same operational concept has to be expressed differently for each user without becoming a different concept. The order lifecycle is one thing, but a dispatcher needs it as a six-stage pipeline with count badges and a driver needs it as four states with one obvious next action. Getting that translation right, rather than pushing one surface's model onto the other, is what let both feel purpose-built while staying genuinely in sync.

Time pressure changes what good enforcement looks like. In the office, structure and explicit status transitions helped. In the field, the same instinct would have backfired, so proactive prompts and scannable input protected compliance without stalling a driver who is paid by the move. Real-world variability at delivery sites rewarded flexibility over a single perfect path, and four ways to capture a signature handled the messiness of terminals and warehouses far better than one polished method would have.

In data-dense enterprise software, standardizing the component system early is the highest-leverage move. Across ten interdependent web modules, the value of consistency compounded far more than any single screen's polish, and it made every other improvement easier to apply.

( Tags )

  • Web
  • Mobile
  • Driver App
  • iOS
  • Enterprise SaaS
  • TMS
  • Transportation Management
  • Logistics
  • Drayage
  • Intermodal
  • Trucking
  • Freight Brokerage
  • Back-Office Platform
  • Field Service
  • Order Management
  • Dispatch
  • Fleet and Equipment Management
  • Records Management
  • DOT Compliance
  • Compliance Documentation
  • Document Management
  • Proof of Delivery
  • Barcode Scanning
  • QR Scanning
  • Order-Linked Chat
  • Billing
  • Legacy Modernization
  • UX Research
  • Information Architecture
  • Interaction Design
  • Design Systems
  • Material UI
  • Envase Design System
  • Data Tables
  • Dashboard Design
  • KPIs
  • Status Pipeline
  • Progressive Disclosure
  • Multi-Tenant
  • Component Architecture
  • Cross-Platform Product Design
  • Envase