Enterprise Platform
B2B Logistics SaaS
2023-2024
Unifying 5 disconnected logistics tools into a single enterprise platform which is serving 50+ clients across contract management, shipment tracking, and intelligence reporting.
Scroll to explore
My Role
Product Designer (End-to-End)
Client
Enterprise Logistics SaaS
Timeline
10-12 months for designing
Team
15+ across Design, Eng, PM
Platform
Web - Desktop First
Tools
Figma, Google Doc, Coda,
CJ Darcl Logistics - one of India's largest 3PL providers was running 30+ operational workflows across five disconnected systems. No shared data layer. No unified view. I was brought in as the product designer to help Fretron replace all of it.
Every cross-domain task required navigating at least three systems. No shared session. No common data layer. No handoff.
Operations
Tracking a single shipment required logging into TMS 1.0, cross-referencing against SAP, and calling the fleet team for an ETA. Three systems, one task, zero audit trail.
Finance
Freight billing reconciliation lived across SAP and WebXpress. Rate cards were in SAP. Actual shipment data was in TMS. Matching them took 4–5 days every month manually.
Fleet
No real-time vehicle visibility. ETA updates were phone-call-based. Fleet maintenance lived in a separate module with no connection to trip planning.
Leadership
Weekly MIS reports were compiled manually from exports across all five systems. By the time leadership saw the data, it was already a week stale.
I joined Fretron after TMS 2.0 had already begun, and within weeks the only designer on the project resigned. I inherited an incomplete platform, an active client engagement, and a 15-person team already mid-sprint.
Spent the initial weeks understanding the existing system through handovers, BRDs, Coda stories, and PM discussions before making design decisions. Worked directly with finance, operations, fleet, and leadership teams at CJ Darcl using their actual SAP systems and spreadsheets. Identified that the core problem was not just disconnected tools, but cross-functional workflows relying on manual coordination across calls, spreadsheets, and WhatsApp.
02 - Impact
80%
Reduction in manual excel exports for daily ops tracking
5 → 1
All five legacy system replaced by single system
3d → hrs
Finance billing reconciliation time, post-platform
50+
Enterprise clients deployed at launch
30+
Modules Shipped across fleet,contract, rail and billing.
4.1 -> 1.3
submission attempts after introducing inline validation in a 30+ field workflow.
90%
Structural complexity absorbed of contract module (3 types) without redesign
40+
Implementation gaps caught across 4 releases like data table states etc.
Platform-level outcomes as part of a 15+ person cross-functional team. Design-attributed outcomes are directly traceable to decisions I made.
Deployed · In production
03 - My Contribution
1
Discovery
High-Fidelity
Wireframes
Pushback moment
The PM's original scope was 6 weeks. After mapping the rate-card logic and its SAP dependencies in discovery, I flagged that the data model alone needed dedicated design time. We re-scoped to 14 weeks. The module shipped without a structural redesign post-UAT.
2
UX audit
Session Analysis
Design Sprints
The existing modules - Order Booking, Shipment Tracking, LSM, POD had been built for TMS 1.0 and carried years of accumulated UX debt. Audited all of them using FullStory session recordings, identifying 12 friction points across the tracking and fleet flows.
Result
The most consistent pattern: users were compensating for missing cross-module context by opening multiple browser tabs simultaneously. That observation directly informed the decision to build a unified detail view. Three design sprints. Twelve friction points resolved before Phase 1 go-live in February 2025.
3
Component library
Azure Devops
Design QA
Release reviews
Maintained a living Figma component library with User stories in Microsoft Azure throughout. With four frontend engineers shipping simultaneously across modules, the library wasn't optional - it was the only way to hold consistency at pace.
Friction moment
In Sprint 3, the frontend lead flagged that inline validation would require significant rework on their form component architecture. I walked them through the UAT data where users were failing contract submission 4.2 times on average with end-of-form validation. That number ended the conversation. The rework happened.
4
UAT facilitation
Stakeholder interviews
Backlog prioritisation
Participated in client-facing UAT sessions for 6 enterprise accounts under CJ Darcl. These weren't passive observation sessions. I was in the room translating raw user feedback into prioritised design actions that fed directly into the next sprint backlog.
Discovery finding that shaped the design
Enterprise users don't give you UX feedback. They give you operational complaints. 'This is taking too long' means the navigation has too many steps. 'I can't find it' means the IA doesn't match their mental model. Learning to translate operational language into design problems in real-time, in front of the client this is a skill I built on this project.
04 - Key Design Decisions
Three decisions. Each one a specific response to something observed.
Decision 01
Tabs over single page for complex modules.
During discovery, users were already working around the stepper: one browser tab for contract details, one for rate cards, one for SAP reference data. They had built their own parallel workflow out of the browser's native tab system.
What I rejected:
Accordion sections on a single scroll. Most natural alternative - everything on one page, sections collapse and expand. Simpler to build, familiar from SAP. Rejected because accordions still enforce top-to-bottom reading order. A finance user who only needs Rate Cards still has to scroll past Contract Details and Order Lines.
Key Insight
Accordions can't support a global completion indicator. The 40% progress bar only works with a tabbed architecture where each tab maps to a defined completion unit.
Decision 02
One detail page layout. Cross the entire platform.
FullStory analysis of TMS 1.0 showed a consistent pattern: users navigating from a shipment to its associated contract were switching tabs, opening parallel windows, or copying reference numbers into separate search bars. Every module team had designed their own isolated detail page. Different status badge placement, different action menu position, different tab structure.
Key Insight
This isn't a visual consistency decision - it's an IA decision. When the layout is predictable, users spend zero cognitive budget orienting themselves. They spend it on the actual task. By Phase 2, ops teams were navigating shipment-to-contract lookups as a single action. The same journey in TMS 1.0 required opening SAP in a separate browser.
Decision 03
Design the list for managers, not just editors
Most contract list views are designed for the person filling the form. At CJ Darcl's scale, the contract list is also a management tool. Team leads scan 50+ contracts simultaneously - deciding what needs attention, what's ready to verify, what's stalled.
What I rejected:
Saved role-based preset views - Finance View, Ops View, KAM View. The PM liked it because it demos well. Rejected for two reasons: first, someone has to maintain the presets when roles change. Second, branch managers at CJ Darcl weren't cleanly one role. They needed finance AND ops AND KAM columns simultaneously. Presets would have recreated the exact multi-tab behaviour we were trying to eliminate.
The Decision
Two decisions came directly from watching this in UAT. First is the 40% progress bar visible in every contract row without opening the record and the Second is 16+ configurable columns coverin KAM assignments.
05 - Final Design
The platform at a glance, 30+ modules across 6 functional domains.
Commercial
Contract Management
ETQ
Pricing Tables
RFQ Management
Operations
Order Booking
LSM
Shipment Tracking
POD
Transshipment
Fleet
Fleet Tracking
Fleet Load Assignment
Rail
Fleet Maintenance
Tyre/Battery/Fuel Management
Finanace
Customer Billing
Vendor Invoice
Payment Settlement
Shipment Costing
Intelligence
Freight Intelligence
Operational MIS
Data Management
Admin
Master Management
Accessory Management
Document Control
Module Deep Dive
This is the module I owned end-to-end. From discovery interviews through to the shipped component system. Customer contracts, vendor contracts, pricing tables, rate cards, and lease vehicle agreements - all unified in one module.
01
Contract creation was a multi-stakeholder task. The ops lead needed order volumes before confirming carrier allocation. Finance needed rate cards confirmed before approving vendor terms. Nobody could complete their part without input from someone else - but the system made them work sequentially.
A linear stepper enforces sequence. A tabbed layout with a persistent summary panel allows parallel context. I chose tabs.
Each tab Approvals are independently accessible. The summary panel shows live contract state regardless of which tab is active. Saving progress tab-by-tab means a finance user can complete rate cards and hand off to ops without either party losing context.
Progress bar
Completion state visible at list level. Ops managers handling 50+ contracts can scan and prioritise without opening a single record.
Column customiser
16+ configurable columns. Finance needs Amount and Bill Submission Rule. Ops needs Transit Days. One list view, role-specific configurations.
Verification CTA
Trigger co-located with Draft status. The action lives where the signal lives. No separate approval workflow to navigate to.
Designing for incomplete - not just complete
Enterprise contracts at CJ Darcl's scale are never filled in one sitting. A contract might be started by ops, handed off to finance for rate card completion, then returned to ops for lane configuration - across days, sometimes weeks. The 40% completion indicator at the top-right is calculated across all tabs, not just the active one. A user on the General Info tab can see the overall contract is 40% complete - meaning there are incomplete sections elsewhere they haven't visited yet.
Module 02
ETQ (Electronic Tender Query)
From registering a tender to receiving and comparing quotations. Designed the RFQ flow to support parallel supplier evaluation - viewing multiple quotes against the same tender spec without navigating away.
02
Module 03
Rail Planning Module
Cross-platform freight exports in real time. Dense data, very few actions. Used progressive disclosure to keep the default view scannable, with drill-down for detailed freight data.
03
06-Reflection
1
What worked
The tab segregation
As the time move ahead in the project everyone realised that showing tabs makes a lot of change in the view and that is why the modules shipped clean.
Pushing of scope
Pushing back on the 6-week scope estimate was the right call. Enterprise form complexity is almost always underestimated when scoping from requirements documents rather than actual user workflows. The re-scope to 14 weeks wasn't a delay - it's why the module shipped clean.
The Unified detail view
The unified detail view paid off by Phase 2. Operations teams were navigating shipment-to-contract lookups as a single action. That outcome doesn't show up in any individual screen. It shows up in how fast people move through the system.
2
What I'd change
Empty field visibility on the contract detail view
On the Vendor Contract General Info tab, a fully active contract still shows 8+ fields as NA - Tracking Mode, Rate Frequency, Based On, Reference Type, Reference Number, Movement Type, Tracking Preference, Customer Contract No. The reasoning at the time: show all fields consistently so users always know where to look. In practice, a screen with more NA's than actual values creates noise. Users scan past fields that don't apply to their contract type at all. I'd handle this differently now: conditional field visibility based on contract type. Show the data that matters for this contract, not the full schema of every possible contract.
3
What this project taught me
Observing vs Listening in UAT
The users who reverted to opening two browser tabs even when the unified detail view was available were telling me the navigation model wasn't intuitive enough yet. That observation drove a second pass on the detail view's entry points before Phase 2.
Enterprise users don't give UX feedback
They give operational complaints. 'This is taking too long' means navigation has too many steps. 'I can't find it' means the IA doesn't match their mental model. Learning to translate operational language into design problems in real-time is a skill I built on this projec