Logistics mobile app
Booking freight like a product, not a phone call
A logistics service-request app: road, rail and sea freight, customs consultancy, bonded warehousing and storage — multi-step request wizards, an offer marketplace and a state-driven dashboard, designed for an industry that still runs on calls.
- Role
- Product Designer — UX/UI · DecentraHubs engagement
- Client
- EasyLogi
- Period
- Studio engagement
- Platforms
- iOS · Android
- Tools
- Figma
- Status
- Selected screens from the working file
Overview
Freight buyers juggle carriers, customs brokers and warehouses over phone and e-mail. EasyLogi turns that into structured product flows: describe the shipment once — mode, load type, origin, destination — and let providers compete with offers.
The design problem is form-heavy complexity: a road/rail/sea request wizard with loading and arrival stages, container and trailer variants, plus customs and warehousing services — kept navigable on a phone.
Scope
- Mobile app UX/UI
- Multi-step request wizards (road / rail / sea)
- Offer & quote comparison
- State-driven dashboard design
The challenge
Logistics requests have real branching: three transport modes, full/partial loads, bonded-warehouse and customs variants — each changing the questions that follow. Flattening that into one endless form would kill completion; the wizard structure had to carry the branching invisibly.
My role
UX and interface design across the request wizards, dashboard and offer flows — a studio engagement with the working file as the source of truth for what is shown here.
Product decisions
3 that shaped the productSegment the dashboard by request state, not by date.
WhyA freight buyer's question is never 'what happened Tuesday' — it is 'which requests have no offers yet, which offers await my approval, which jobs are done'.
ImpactA slider-based dashboard with dedicated states — awaiting offers, incoming offers, approved, unapproved, completed with review — so the next action is always one glance away.
Build one wizard skeleton, branch by mode inside it.
WhyRoad, rail and sea requests share a spine — load, origin, destination, timing — and differ in the details.
ImpactLoading-place and arrival-place steps reuse one interaction pattern across all modes and service types, so learning one request teaches them all.
Treat the offer as the product's core object.
WhyThe marketplace lives or dies on offer quality and comparability.
ImpactOffer detail pages carry structured pricing and terms, and the request detail keeps package and requirement context attached for fair comparison.
Product surface
From first open to signed offer
The core journey: onboarding, the state-driven dashboard, service selection across six logistics products, and the offer surfaces where requests become deals.
Outcome
verified, qualitative where honest- 01
A coherent mobile design for a six-product logistics marketplace — request wizards, offer flows and a state-driven dashboard designed as one system.
- 02
Branching complexity (mode × load type × service) absorbed into a single reusable wizard pattern.
