Second Look

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 fleet, customer, drivers, loads and outcome records are invented; the towns are real.

The hard part is knowing what needs a second look

A dispatcher at a fleet of 450 trucks 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.

The design question Can the interface help someone check the right things without rebuilding the whole decision themselves?

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. They set the size of the card and the number of factors on it, and the first session with a dispatcher is as likely to move them as to confirm them. The hypothesis is not less checking but better-aimed checking, and the research on explanations is unsettled enough that an interface can only pose the question well. One more, about time: the ranking here is instant because it is arithmetic on the page. A model would take a moment, and the row would have to show that it is still thinking rather than that it has nothing to say.

Try the 90-second prototype

Seven trucks can take load L‑4821. The system recommends, then reveals uncertainty, then keeps the dispatcher’s judgment in charge, then enforces a rule it cannot bend. The interface changes shape each time, because these are different kinds of decisions. 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.

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, where it came from and where it stands against the fleet, and the same five columns in the data table. A score is the one number that cannot be checked against anything; five figures can be argued with. Above them, one derived line: when this truck would reach the pickup, and how much room that leaves.

    Why I designed it this way
    • 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 needed to answer the dispatcher’s real question was already on the page, and the screen was leaving the sum to the person.
    • A derived figure says it is derived. The arrival time is the miles the ranking already weighs, at a stated speed, against the clock printed on the load, and it is marked as such wherever it appears.
    • Ahead of the fleet is not the same as decisive. A factor can lead the fleet without having decided the call, and the note under the list says so.

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

    A close ranking is a judgment. A driver without the hours is the law: the hours-of-service limit is a federal regulation, the system enforces it before any score is figured, and nothing on the screen can argue it out of that. The two never share a channel: the close call names the tradeoff and declines to pick; the rule removes the truck, keeps its row and its reason, and takes the one caution color on the screen. A truck that would arrive after the window is a third thing, a reading the dispatcher can act on by calling the dock.

    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, what it left, and what to check. T‑131’s hours reading is 45 minutes old and left 30 minutes to spare. The two numbers next to each other say the rest.
    • 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 under a truck ranked first alone 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. Assign sits at the end of every row the rule allows, not only the recommended one, with no dialog in the way. The question about why comes after, is optional, and Skip weighs the same as Save; Undo takes Assign’s place on the row.

    Why I designed it this way
    • A confirmation dialog taxes the judgment that is the point. That holds here, where Assign stages a choice Undo reverses; where Assign sends a driver, a confirmation earns its place at that boundary. The same boundary is where a system allowed to act on its own would stop and ask.
    • The way back sits where the action was. Undo takes Assign’s place on the row, and it is inert for half a second after the press, so a double-click assigns once rather than assigning and undoing.
    • 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. Review triggers at three matching reasons on one customer in a month, and lands with the dispatch manager, the one person who can change what the ranking weighs. A floor answering one override in five clears that without noticing: a few answers a month, not one from every override.
    • The record is half built. The reason is saved with the load, for anyone to read. What the system recommended, on which figures, at what time, is not written down yet, and a version anyone audits has to write both, so that a decision can be reconstructed by someone who was not there.

  4. Show the exceptions, not just the record

    38 of 40 on time is context, and the record is invented here like the rest of the data. The two that were late are the useful part, and what to watch for on this load because of them sits on the card, not behind a click; what differed on each is behind the disclosure for anyone who wants the evidence. One of the two was a stale hours figure, which is why the close call checks for one.

    Why I designed it this way
    • A record is a claim about loads. “On time on 38 of the last 40 loads like this one” is something a dispatcher can set beside the load in front of them. “87% confident” is a claim about the system, and there is nothing to set it 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 sentence with two numbers in it is read where a badge is glanced at, and in a four-second decision that difference is real. A dispatcher who has read “38 of 40” on this lane a dozen times stops reading it, and what is left on the card is the two lines saying what to check. A badge never gets that far, because a badge has nothing under it.

  5. Keep the whole fleet in reach

    The recommendation is assistance, not the only route through the task. Every column sorts, every eligible row assigns, every row opens on the reasoning behind its place, the rows run comfortable or compact, and the one truck a rule removes keeps its row, its numbers and the reason. Nothing is collapsed behind the suggestion. If the recommendation vanished tomorrow, this would still be a dispatch screen.

    Why I designed it this way
    • 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 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 it.

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 matched scenarios: a straightforward call, a plausible wrong one, and a load where a figure on screen is stale. The same three are the test the ranking would be held to before it shipped, and again after every change to it. The question is whether dispatchers decide well with less unnecessary checking, and without more missed constraints or more bad recommendations accepted.

  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 being read, and they sit on the card so that reading them costs no click. If they are skipped there too, they move up again, into the recommendation line itself; if that is skipped, the card is asking for attention the floor does not have, and the lines belong on the row of the truck they are about.

  3. Does a close call help, or annoy?

    Declining to lead is right for a system that knows its own shape, and may be the thing dispatchers hate most at four on a Friday. If the tradeoff sentence is not enough to decide from, the tie should show what the dispatcher did last time for this customer.

Nothing on this screen acts without a press. The version after this one would assign the clear picks itself, hold the close calls and the rule blocks for a person, and write down every assignment it made with the figures it made it on. That is the line between a recommendation and an agent, and the interface for it is this screen with one more column: who decided, and whether anyone checked.

The hard part of AI product design is not getting the system to produce an answer. It is designing what sits between that answer and an action someone may regret: the evidence, the uncertainty, the rule that cannot bend, the override, the way back, the record of who decided and on what, and knowing when the system should stop.