TMS logistics ecosystem
300+ hours saved per employee per year — a custom TMS that replaced the Excel, email and head-math a road-freight desk had been running on. Six surfaces, four years, ~500 trucks.
Web
Mobile
B2B
Logistics
Role
Sole Product Designer 2022–2025 Lead since 2026
Timeline
2022 – currently
Surfaces
6 in production
Team
2 x designers 1 x PM 11 x developers 2 x QA
Methods
Shadowing Users Stakeholder Interviews Information Architecture Design System Design Mentoring Visual Identity
Outcome
300+ hrs
saved per employee per year
30s → 5s
to judge an incoming offer
70%
fewer “where are you?” calls from drivers after the driver app
180k+
orders a year running through the system
The forwarder web app — the centerpiece the other surfaces feed
Overview
Five apps in production and a sixth launching, for a European road-freight operator. I joined in 2022, six months after launch. The four years since are mine.
I joined this project in 2022, six months after the first app went live, as the team’s junior designer. The client is a European road-freight operator: time-sensitive work, heavily regulated — customs, cabotage, tachograph rules, KSeF e-invoicing, several currencies across borders. Over four years I ran research, information architecture and design for every new surface and feature. Since June 2026 there are two of us, and I lead the design side.
The apps
Six surfaces, six case studies. Check out client portal if you want to know how I use AI tools in my design process, driver app if you want to know how I maintain a design system, see Forwarder app and how I handle information density, back office to find out how I improve UX, carrier panel - how I design information architecture.
Problem
Hundreds of trucks, a constant stream of offers — and the matching between them happened in people’s heads, patched together with Excel and email.
Around 500 trucks and a constant flow of freight — orders from clients, offers from the public exchanges — matched by hand. Forwarders sat directly on the freight exchange and updated a row in a spreadsheet after caught an offer. Dispatchers out of sync with the actual road situation costs real freight: empty kilometres, late penalties, cancelled lanes.
The brief was to build the TMS this team would work in, instead of around.
Eight roles from interviews and shadowing. One line per role: who feeds the forwarder, who the forwarder feeds
Key decisions
Two decisions belong to the ecosystem itself. The deep work lives in the sub-case-studies.
Decision 01 · The ecosystem
Separate surfaces sized to context, not one app for everyone
The alternative was one app with role-based permissions: cheaper to build, easier to maintain. The ecosystem went the other way — a surface per context of use. The forwarder gets density: dozens of fields, fixed row heights, everything at once. The driver gets a glance-and-tap Android app that works offline in a tunnel. The forwarder on a Sunday call gets a minimal mobile mirror. The external carrier gets a narrow surface showing only what is theirs. Same data underneath, different products on top.
The driver app shows how far context-sizing goes: designed with no direct access to drivers, through dispatchers and forwarders as a proxy. Its case study, and the carrier portal’s, are in the block above.
Why
One app for everyone means everyone gets a compromise. A driver glancing down mid-route and a forwarder comparing thirty rows have nothing in common but the data.
Trade-off
Six surfaces cost six roadmaps and six release trains. Features land on one surface later than users of another would like, and power users sometimes hit a missing module on mobile and open a laptop. Accepted: every module added to a small surface taxes the ones that earn it its place.
Decision 02 · The system
One design system for the desk, separate ones for every other context
The same argument runs one level down, into the systems the surfaces are built from. There are four.
One covers the three desk-bound web surfaces — forwarder app, back office, carrier portal. They share primitives: dense tables, long forms, data compared at scale, fixed row heights that have to survive a new column every quarter. A pattern proved on one of them pays for itself three times.
Everything else got its own. The driver and forwarder mobile apps are glance-and-tap interfaces used one-handed, often in motion, sometimes offline; built from desk components they would inherit the wrong defaults and override them everywhere. The client portal is separate for a different reason — it faces the customer, carries two brands and four languages, and its visual decisions belong to a brand the internal tools do not share.
Why
Components inherit the assumptions of the context they were designed for. Force one library across a dense desk app and a one-handed cab app and half the defaults are wrong on any given screen. A designer overriding defaults on every screen has a style guide, not a system.
Trade-off
Four systems mean four places to fix the same thing. An improvement to the web system does not reach the driver app, and nothing stops the surfaces drifting apart in the details. I took the divergence over a shared library that fits nothing well. The cost is real and it grows with every surface added.
Outcome
Five apps in production and a sixth in development, after four years of daily operation.
The time a forwarder needs to judge an incoming offer dropped from 30 seconds to 5.
Load-to-load matching and surcharge baskets, the two 2026 features, are designed and pre-launch. Their sub-case-studies say what is known and what is not yet.
One lane per surface. It starts the year it shipped and runs to today.
Reflection
The arc of my role on this product runs alongside the arc of the product.
I came in implementing other people’s decisions. I leave 2026 having taken two features from problem statement through research to implementation, and leading the design of the product.