Forwarder mobile: the after-hours app
The desk closes at 16:00 and the freight doesn’t. A deliberately small Android app covering the three things a forwarder actually gets called about after hours — and leaving the other forty on the desk.
Android
Mobile
Logistics
Role
Sole Product Designer
Primary user
Forwarders and dispatchers, away from the desk
Timeline
2025
Status
Live
Methods
Discovery · Scope Definition · Interaction Design
One order, its live state, and the document the client is waiting for.
Overview
The web app is built for a desk with two monitors. This one is built for 20:00 on a Sunday, when the desk is closed and a client wants a proof of delivery.
The forwarder web app is the densest surface in the TMS — dozens of fields per row, three time horizons, hundreds of trucks. It’s built for people sitting in front of it all day. That density is the point, and it’s what the Forwarder app case study is about.
None of it survives a phone. Not the screen size — the assumption. The web app assumes you have both hands, a full screen, and time to scan. After hours you have one hand, a notification, and a client waiting on the other end of a mail thread.
So this app is a mirror, not a port. Three jobs, sized to the one moment they happen in. Everything else stays where it works.
Problem
The desk closes at 16:00. The clients don’t, the trucks don’t, and the forwarder they want is a specific person, not a hotline.
Here is the scene the whole app was scoped around, straight out of the discovery note:
A mail arrives at 16:00, after hours. I open the app. I can see which lane it’s about, I find it fast, I see the stop was unloaded at 16:20, I tell the client. The client asks for the POD. I send it.
Every requirement in this app is downstream of that paragraph, so it’s worth pulling apart what it assumes. It assumes I can find one order from a mail that names a lane and a plate, not an order number. It assumes the stop status and its timestamp are already accurate on my phone, because I’m about to repeat them to a client. And it assumes the document is one tap from the order, because that’s what the client actually asked for.
The obvious counter-argument is that this is what a hotline is for, and there is one. Two things break it. Clients contract for a named forwarder and want that person, not whoever is on shift. And not every forwarder hands their lanes over to the hotline at the end of the day — some just keep answering. So the after-hours gap isn’t a rota problem you can staff your way out of. It’s structural, and the tooling had to meet it.
What filled the gap in the meantime was WhatsApp. Chat in the TMS is web-only, so once the browser closed, the conversation moved to personal phones — including contact with the fleet manager, which forwarders simply lost after hours if they stayed inside the system. Every message that leaves the TMS is a decision the system can’t show you later.
The coverage gap the app was scoped to close.
Constraints
Five constraints did most of the design work before any screen existed.
Android only. Same as the driver app. It’s what the fleet and the desk actually carry, and it halved the surface to maintain.
The web TMS stays the source of truth. The mobile app reads and writes into the same system; it never becomes a second place where the state of an order lives. The desk app is where the record is settled, and every mobile decision had to survive that.
Forwarders and carriers get separate apps, not one app with a role switch. They need different maps and diverge further with every release, so a shared shell would have meant two roadmaps fighting over one screen.
Documents already arrive through two doors. Drivers upload the same scan in two places out of habit — a known problem in the existing system. Mobile could not add a third.
The context of use is hostile. One hand, a glance, a client already waiting, and a connection that may be a train tunnel. Anything that needs precision belongs on the desk.
Empty and error states were on the scope list from day one, not retrofitted.
Key decisions
Four decisions, and three of them are about what the app refuses to do.
Decision 01 · Scope
Three jobs on the phone, everything else stays on the desk
The app does three things: it gets you to an order, route or document on a lane you’re running; it lets you find that lane by vehicle registration; and it gives you a stripped mobile version of the forwarder panel.
That list is short because it was written against a single moment rather than against the web app’s feature inventory. The pressure ran the other way — a mobile app that already exists is an obvious place to put the next module, and each one arrives with a reasonable argument. The answer was that the same user in a different context of use is a different user. At the desk, density is the feature. On a Sunday call, it’s the tax.
Why
Same person, different context of use. A screen designed for a two-monitor desk is lying about where it will be read.
Trade-off
Power users hit the wall of a missing module and have to open a laptop. Accepted deliberately: every module added to mobile taxes the three that earn the app its place.
Decision 02 · Entry point
The app opens on orders, with route context second — and finds them by plate
The web app is organised around the truck. Its main screen is one row per vehicle, because planning and dispatch are fleet-shaped problems: who is free, where, when.
The after-hours question is not fleet-shaped. It arrives from a client and it is order-shaped — where is my freight, when was it unloaded, where is the paperwork. So the mobile app enters through orders, and route context sits one level below, available when the answer needs it.
This also matched what the dispatchers had already said about their own desk panel: it leans hard on routes, and routes matter less to them than orders do. The mobile scope note settled it in one line — orders first, route context later if needed.
Search is by vehicle registration. That looks like an odd primary key until you look at what the forwarder is holding: a mail from a client that names a lane and a plate, often no order number at all. The search field has to accept what’s in the mail.
Why
The after-hours question comes from a client, so the object it names is an order, not a truck. Search by the identifier that’s actually in the mail (Nielsen: match between the system and the real world).
Trade-off
Fleet-wide awareness doesn’t fit on the phone. A forwarder who wants to see the whole board still opens the laptop, and the two apps now organise the same data around different objects — a real inconsistency, paid for on purpose.
Decision 03 · Permissions
You can change statuses on your own orders. Everything else is read-only.
The most consequential thing a forwarder does on this app is move a status, because the desk, the driver, the carrier and the settlement chain all read it. Mobile is the worst place in the ecosystem to do that: small target, one hand, half attention.
The rule is ownership. Your orders are editable; everyone else’s you can see but not touch. That protects the case the scoping note flagged as the real risk, which is not the mistap — it’s the collision. Somebody edits an order in the web TMS while I’m looking at the next leg of it on my phone. If I can quietly change their order too, we now have two people editing one lane from two surfaces with no shared context.
Read-only on its own is only half an answer, though, because it leaves you looking at something wrong that you can’t fix. So the read-only state has to carry the ownership: whose order this is, and a route to tell them. The scoping note calls this out from the other side — I see the next order belongs to someone else and I need to let them know. Handing it over is the job, not editing it.
Why
After-hours, one-handed, on someone else’s order is the highest-consequence, lowest-attention combination in the ecosystem. Constrain the action, then make the alternative obvious (Nielsen: error prevention over error messages).
Trade-off
The person holding the phone at 20:00 can sometimes see exactly what’s wrong and can’t fix it. That’s a real cost, and it only stays acceptable if handing over is fast — which makes the handover flow load-bearing rather than a nice-to-have.
Decision 04 · Chat
Chat on mobile, because the record was already leaving the building
Chat is the first line of the scoping note, and it’s the item that argues hardest against the app’s own minimalism. It is the most expensive thing on the list.
The case for it isn’t that forwarders want to chat on their phones. They already do. It’s that with chat living only on the web, everything agreed after 16:00 happens on WhatsApp — on a personal phone, outside the audit trail, invisible to whoever picks the lane up tomorrow morning. Contact with the fleet manager goes the same way, because for forwarders inside the system it simply stops existing at the end of the day.
The reason to carry the cost is that the alternative isn’t “no chat”. It’s chat somewhere you can’t see.
Why
A conversation that shapes an order belongs to the order. Shadow tooling isn’t a usage problem, it’s a record-keeping one.
Trade-off
Chat is the heaviest module in an app whose whole argument is being light, and it competes for the same budget as the three jobs. Matching WhatsApp on messaging quality was never the goal, and if the app were judged on that it would lose.
Outcome
In production. The app was not instrumented, so what I can show is the scope, the reasoning, and the questions to measure.
The app is in production and was not instrumented, so I have no usage numbers. What I can show is the scope: three jobs, an entry point, a permission rule, and a set of constraints that killed the obvious version of this app, the one that ports the web product onto a smaller screen.
The questions worth measuring were obvious from the scope note and are still open. What share of after-hours client mails get answered from the phone instead of the next morning. Whether WhatsApp traffic between forwarders and the fleet manager dropped, the cleanest available proxy for the record coming back inside the system. How often someone hits a read-only order and what they do next. And whether the three jobs held, or a fourth module arrived within two releases, which would tell me the scope argument lost.
The reasoning is what transfers to the next scope decision.
The 16:00 mail, answered from a phone.
Reflection
The scope came from one vivid scene. I would keep the scene and check it against a week of logs.
Check the scene. The 16:00 mail, the unloaded stop, the POD request: one scene produced a scope in an afternoon, and the three jobs held. What I would add next time is a week of after-hours mail and call logs before writing scope, to see how many contacts are POD requests, how many are status questions, and how many the phone cannot solve.
Write down the rule for saying no. “Three things, not forty-seven” is easy to say once and hard to hold for two years, because every proposed addition arrives alone and sounds reasonable. The rule I would write is what a module has to prove about the after-hours moment before it earns space.
Ask the narrower chat question. WhatsApp told me people had already routed around the system and chosen the lowest-friction tool. Chat on mobile brings the record back inside. The question I would ask next is what the smallest thing is that has to come back for the record to survive, and whether it can be less than a full messenger.