All work

Opsdeck

A concept operations platform for a logistics team, with one dispatch board and one live picture of every run, so the morning stops being a phone call.

ConceptFictional project. No real client, and nothing here is a measured result.

Sector
Logistics and freight
Service
Custom software development
Year
2026
Concept design: Opsdeck

In this concept

  • Dispatch board
  • Live status
  • Driver app
  • Exceptions

Opsdeck is a concept project. It is not a real company or product, and nothing here describes a client. We made it up to show how we would approach custom software for a logistics team. Every outcome below is a design goal, not a measured result.

The problem

Picture a regional freight team running a few dozen trucks out of one depot. The plan for the day lives on a whiteboard and in a spreadsheet that only one person fully understands. Live status lives in the dispatcher’s head, topped up by phone calls and a group chat.

It works until it doesn’t. A truck gets held at a dock, and nobody knows until the customer rings to ask where their delivery is. Moving a job means checking three places, calling two drivers, and hoping the spreadsheet gets updated afterwards. When the one person who knows it all is off sick, the morning falls apart.

No off-the-shelf tool fits, because every depot has its own rules: which drivers hold which tickets, which customers can only take a delivery before ten, which trucks have a tail lift.

The approach

Start at the whiteboard, not the database. We would spend the first days in the dispatch office, at the hour it is busiest, and write down what people actually do and the rules they carry around in their heads.

Then build the board they already trust, with the live data it never had. Runs are blocks on a timeline, one lane per driver. Drag a job to a new lane and the system checks the time windows, driver hours, and truck fit before it lets go. Status comes from the drivers’ phones, so nobody has to ask for it.

The screen should stay quiet when things are going to plan. Dispatchers should only be pulled in when something needs a decision.

What we would build

  • A dispatch board. One lane per driver, one block per run, drag to reassign, with conflicts shown before the drop rather than after.
  • A live map. Every truck, every stop, and the plan beside the reality, on one shared screen for the whole office.
  • An exceptions feed. Late runs, held docks, and failed drops, ranked by what needs a person first.
  • A driver app. Today’s stops, one-tap status, and proof of delivery by photo or signature, working through patchy signal.
  • A rules engine the team can edit. Delivery windows, licences, and vehicle limits, kept in settings rather than in code or in somebody’s memory.
  • Connections to what is already there. Orders in from the existing system and proof of delivery out to billing, so nothing gets typed twice.

Key screens

The board

The home screen. Timeline across, drivers down, a line marking the current time, and an unassigned queue to pull from.

The live view

The map as the ground, with the selected run lit and the others held back. Each truck shows its next stop and how far it has drifted from the plan.

The run

Stop by stop, planned time against estimated time, with the actions a dispatcher needs most: call the driver or move a stop.

The driver’s phone

One stop at a time, large targets for gloved hands, and a clear way to say something went wrong.

Design goals

These are the targets we would design and test against. They are goals, not results.

  • A dispatcher can see the state of every run in one look, without making a call.
  • Moving a job takes one drag, and the system refuses anything that would break a delivery window.
  • A customer’s “where is it?” can be answered by anyone in the office, in seconds.
  • A new dispatcher can run a normal morning without the rules living in their head.
  • The team changes its own rules, without asking a developer.