Dispatch Cockpit · Human–AI interaction · working prototype · synthetic data

An AI recommendation the dispatcher can check and overrule

The system picks a truck. The dispatcher decides whether it is right.

  • Every factor behind the pick is shown.
  • Close calls are flagged.
  • Legal limits are enforced.
  • Switching trucks takes one click.

Try the prototype How it was designed →

The cockpit showing a close call: a heading reading “T-131 and T-118 are level. The tradeoff is faster pickup against more driver hours”, under it a note raised on white saying T-131’s hours are 45 minutes old, and then a comparison table with Option A and Option B as its two columns. The two rows that separate them, distance and driver hours, are raised on white and marked “the tradeoff”; the remaining factors follow, then a derived row giving the time each would reach the pickup, then an Assign button under each option.
When the call is close, the system says so. One comparison, the two rows that separate the trucks first, the one figure it cannot vouch for marked, and no invented winner. Full size ↗
Problem
A recommendation the dispatcher has to verify every time saves almost no attention.
Hypothesis
Show the reasons, the exceptions, and the hard limits, and checking becomes selective.
My role
Product strategy, interaction design, visual design, prototyping, and the front-end build.
Artifact
A working browser prototype. No model behind it: the ranking is a weighted rule over the factors on screen.
Context
Self-directed, on synthetic data, informed by the dispatch cockpit I led at RBA for a fleet of more than 450 trucks.
Next
Put it in front of working dispatchers. Then let it assign the clear picks itself, and find out whether they catch the wrong one.

Not a reproduction of that product, and not yet tested with a dispatcher.

The hard part is knowing what needs a second look

A dispatcher has a load to place, seven trucks that could take it, and half of what matters arriving from outside the screen.

A ranking that is right 95 times in 100 still gets checked 100 times if the dispatcher cannot tell which five to worry about. Recommending the truck solves half the problem and leaves the expensive half standing.

Information is not what is scarce. Attention is.

An illustration of a dispatcher at a desk with three monitors, a desk phone, and a stack of delivery paperwork, considering a load board, a recommendation panel, and a route map.
A recommendation lands in work already under way, beside three screens, a phone, a stack of paper, and information the system will never be given.
Assumptions behind the prototype

Assumptions, not observations: about four seconds to weigh five factors against seven trucks, forty times an hour, while the phone rings. The first session with a dispatcher could move any of them.

Try the 90-second prototype

Seven trucks can take load L‑4821. Four scenarios, one load, with your hands on them.

Three things to try

  1. Read the five factors behind T‑118, then open the two late deliveries.
  2. Switch to the close call and find the stale figure.
  3. Assign a truck the system did not pick, then try the one a rule blocks.

What this is

  • Designed and built by me: plain HTML, CSS, and JavaScript, no framework, no build step.
  • Responsive and keyboard accessible, with changes announced. At 390px the fleet refolds rather than scrolling sideways.
  • Synthetic data and a transparent weighted rule, not a model. Source: dispatch-cockpit.js, the fleet as one object at the top.

Try it, it’s live

Pick a scenariothe screen below changes with it

The whole fleet

Five decisions, and what each one looks like

  1. Show the reasons, not a score

    Five factors, each with its value, its verdict, its source, and its rank in the fleet. A score cannot be checked against anything; five figures can be argued with. Above them, one derived line: when the truck would reach the pickup.

    Why: a score gives the dispatcher nothing to check it against. Five figures can each be checked on their own.

    The rest of the reasoning
    • A ranking is a summary of reasons. Hide them and the dispatcher has to rebuild them to check it, which is more work than ranking by hand.
    • The arithmetic belongs to the screen. Every number was already on the page, but the screen left the sum to the person.
    • A derived figure says it is derived. The arrival time is the miles at a stated speed, marked as derived wherever it appears.
    • Ahead of the fleet is not the same as decisive. A factor can lead without deciding the call, and the card says so.

  2. Treat a close call and a rule as different things

    A close ranking is a judgment; a driver out of hours is the law, enforced before any scoring. The close call names the tradeoff and declines to pick. The rule removes the truck but keeps its row and its reason.

    Why: a judgment and a law fail differently. The close call leaves the choice open; the rule closes it, and keeps the row and its reason in sight.

    When the figure itself cannot be trusted
    • Operational data has an age. A system that knows its evidence is thin should say so rather than pick.
    • The card says how old the figure is, what margin it left, and what to check. T‑131’s hours reading is 45 minutes old and left 30 minutes to spare.
    • The doubt does not move the ranking. The row keeps its Assign. What changes is what the dispatcher does before pressing it.
    • On a clear pick, it would hold. The same stale figure should hold the recommendation back until the next update.
    1. A caution-outlined card reading “T-114, Sam Bergstrom, can’t take this load. Needs 5.5 h, has 3.2 h left. The hours-of-service limit, not a score. Otherwise it would rank first: 9 mi to pickup, 14 of 14 on time with Northfield Foods, 4 mi of deadhead. None of that changes the rule.”

      A rule Removes the truck before scoring, and keeps its row and its reason. Full size ↗

    2. Under the close-call heading, a note raised on white with a clock glyph, its first phrase in the caution ink: “T-131’s hours are 45 minutes old. The last reading left 30 minutes to spare on this run. Check the logbook before assigning T-131.”

      A reading Says what is uncertain, shows its arithmetic, and asks for a check rather than refusing. Full size ↗

  3. Make disagreement cheap

    The dispatcher has the phone call the system cannot hear. Every row the rule allows has its own Assign, with no dialog in the way. The question about why comes after, and Skip weighs the same as Save.

    Why: the dispatcher hears the phone call the system can’t. A dialog in front of Assign would tax exactly that judgment.

    The rest of the reasoning
    • A confirmation dialog taxes the judgment that is the point. Here Assign stages a choice Undo reverses; where Assign sends a driver, a confirmation earns its place.
    • The way back sits where the action was. Undo takes Assign’s place on the row, inert for half a second so a double-click assigns once.
    • The prompt says what happens to the answer. A prompt that does not say is a prompt people learn to skip.
    • The loop is sized for skipping. Three matching reasons on one customer in a month send a review to the dispatch manager, who can change what the ranking weighs.
    • The record is half built. The reason is saved with the load; what the system recommended, and on which figures, is not written down yet.

  4. Show the exceptions, not just the record

    Of 40 similar loads, 38 were on time. The two late ones matter, and what to watch for sits on the card.

    Why: thirty-eight on-time loads teach nothing new. The two late ones show what to check, and one of them was a stale hours figure.

    The rest of the reasoning
    • A record is a claim about loads. “38 of the last 40 loads like this one” can be set beside the load; “87% confident” has nothing to set beside.
    • An outcome is not a verdict on the ranking. An on-time delivery does not prove the system picked the best truck, and a late one does not prove it picked the wrong one.
    • The shape of the misses is the part that teaches. If the misses have a shape, the dispatcher learns the shape, and that is the moment checking becomes selective.
    • It costs a read, and the cost is paid once. A dispatcher who has read “38 of 40” a dozen times stops reading it, and the two lines saying what to check are what remain.

  5. Keep the whole fleet in reach

    Every column sorts, every eligible row assigns, every row opens on its reasoning, and the rows run comfortable or compact. Nothing is collapsed behind the suggestion.

    Why: if the recommendation vanished tomorrow, this would still be a dispatch screen.

    The rest of the reasoning
    • The width is the argument. The fleet is 1,200 pixels of interface because seven trucks and five factors staying in reach at once is the whole claim.
    • A phone cannot be given the same table. At 390 pixels, it had three columns showing and eight hundred more pixels behind a sideways scroll, including every Assign button.
    • So the phone gets four columns and folds the rest. One tap down, inside the row it belongs to.
    • In reach has to mean findable. Otherwise the layout is quietly contradicting the claim.

What I need to learn from dispatchers

The prototype shows an interaction approach. It does not show that the approach improves decisions. That takes a session with a working dispatcher, and the first one would change the prototype.

The fleet data table alone

The manual path, as it is today.

compared with

The table, plus the recommendation

The same screen with the reasons, the record, and the override on it.

Over three matched scenarios (a straightforward call, a plausible wrong one, and a stale figure), the question is whether dispatchers check less without missing more.

  1. Are decisions better, not just faster?

    Decision quality first, then missed constraints, checking effort, and time. A faster wrong answer is the failure this design could plausibly cause, so it is the one to look for.

  2. Does anyone read the two lines?

    The design leans on the two watch-for lines on the card being read; if they are skipped, they move into the recommendation line itself.

  3. Does a close call help, or annoy?

    Declining to pick may be right, and may be what dispatchers hate most at four on a Friday. If the tradeoff is not enough to decide from, the tie should show what the dispatcher did last time.

Nothing here acts without a press. The next version would assign clear picks itself and hold the close calls and the rule blocks for a person. Its screen gains one column: who decided, and whether anyone checked.