Human–AI interaction · working prototype · synthetic data

An AI truck recommendation the dispatcher can check and overrule

A recommendation is only useful if the dispatcher can judge it. This one shows the factors behind the pick, flags the calls that deserve a second look, holds the rules it cannot bend, and lets the dispatcher choose differently in one press.

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 in the caution color that 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.
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.

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.

Four scenarios, one load

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 decision. Captured from the working prototype below, not drawn.

  1. Recommend · Clear pick The system picks a truck and shows its reasons

    A card headed “What went into the call” for truck T-118, now at Owatonna, with a line reading “At pickup by 2:26 pm, in the window, 34 min of room”, then five factors with their values: distance to pickup 38 miles, from a GPS fix 2 minutes ago, helps; hours of service left 8.4, from the ELD 6 minutes ago, helps; equipment dry van, meets; on time with Northfield Foods 11 of 12 in the last 90 days, neutral; deadhead 12 miles, helps. A key explains the bars, and an Assign T-118 button sits at the bottom.
    No score to trust: five facts, each with its value, its verdict, where it came from and a bar against the fleet. Above them, when the truck would arrive.

  2. Reveal uncertainty · Close call Two trucks are level, and one figure is stale

    A card headed “T-131 and T-118 are level. The tradeoff is faster pickup against more driver hours”, with a line saying the system is not ranking one over the other, then a note in the caution color reading “T-131’s hours are 45 minutes old” with the spare it left, and under it a comparison table: Option A is T-131, Priya Nair, and Option B is T-118, Marisol Vega, with distance and driver hours as the first two rows, each marked “the tradeoff”.
    T‑131 is closer; T‑118 has more driver hours. The two rows that separate them come first, T‑131’s hours figure is marked as 45 minutes old, and neither Assign counts as overriding.

  3. Preserve judgment · Dispatcher overrides The dispatcher picks a different truck

    A card headed “You assigned T-114, ranked 3rd. Why? Optional.” with four reasons to choose from, a free-text box reading “In your words, if you like”, a paragraph headed “What happens with this”, and two buttons: Save the reason, and Skip.
    T‑114 was ranked third. Assigning it took one press and nothing argued back. The question comes afterwards, and Skip is as easy as Save.

  4. Enforce the rule · Blocked by a rule The best truck cannot legally go

    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”, and under it the recommendation for T-118, Marisol Vega, with the top of its factor card.
    T‑114 wins on every measure, but its driver has 3.2 hours left and the run needs 5.5. A legal limit, not a low score.

Try the 90-second prototype

The same four scenarios, 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 scenario

In this scenario

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. 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 the ranking, which is more work than ranking by hand. The arrival time is figured from the miles the ranking already weighs, at a stated speed, against a clock printed on the load, and it is marked as derived wherever it appears: the screen had every number needed to answer the dispatcher’s actual question and was leaving the arithmetic to the person. Ahead of the fleet on a factor is not the same as that factor having decided the call, and the note under the list says so.

    The recommendation card for truck T-118, headed “What went into the call”. Under the truck and its location, a line reads “At pickup by 2:26 pm, in the window, 34 min of room”. Then five factors with their values and whether each helps, meets or is neutral, three of them with a small line under the name saying where the figure came from and how long ago, each over a bar showing where the truck sits against the fleet, then a key to the bars, a note about what the comparison is not, and an Assign button.
    What the system weighed, which way each cut, when each figure was last true, and the one derived line the ranking does not weigh. The same five columns are in the data table.

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

    A close ranking is a judgment. A driver without the hours is a law. The two never share a channel: the close call names the tradeoff and declines to pick; the rule removes the truck before any score is figured, keeps its row, 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. In the close call, T‑131’s hours figure is 45 minutes old and left 30 minutes to spare, and the card says so in three sentences: how old, what it left, what to check. The two numbers next to each other say the rest. The ranking does not move and the row keeps its Assign; what changes is what the dispatcher does before pressing it. The same figure on a truck ranked first alone should hold the recommendation until the next update. A system that knows its evidence is thin should say so rather than pick.

    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.

    2. Under the close-call heading, a note on the caution ground with a clock glyph: “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.

  3. Make disagreement cheap

    The dispatcher has the phone call the system cannot hear. Assign sits on every row the rule allows, with no dialog in the way. The question about why comes after, is optional, and Skip weighs the same as Save.

    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. Undo takes Assign’s place on the row, which is where the way back belongs, 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 in plain words what happens to the answer, because a prompt that does not say is a prompt people learn to skip. Most will skip anyway, and the loop is sized for that: the review trigger is three matching reasons on one customer in a month, which a floor answering one override in five clears without noticing. It needs a few answers a month, not one from every override.

    1. The top of the fleet data table: a head row of sortable columns, then the recommended truck T-118 and two others, each row ending in an Assign button that is present whether or not the system picked that truck.

      First Assign sits at the end of every row the rule allows, not only the recommended one.

    2. After an override: a status line reading that load L-4821 is assigned to T-114, the truck ranked 3rd, with its pickup time, its room against the window and the driver hours left after the run, and an optional question below it offering three reasons, a free-text box, a note about what happens with the answer, and Save the reason and Skip buttons.

      Then The assignment and what it means: pickup time, room against the window, hours left after the run. The question, afterwards and optional; Undo takes the place of Assign on the row, and sits out a double press.

  4. Show the exceptions, not just the record

    38 of 40 on time is context. 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

    “87% confident” is a claim about the system. “On time on 38 of the last 40 loads like this one” is a claim about loads, which a dispatcher can set beside the load in front of them. 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. If the misses have a shape, the dispatcher learns the shape, and that is the moment checking becomes selective.

    It costs something. A sentence with two numbers in it is read, and a badge is glanced at, and in a four-second decision that difference is real. The bet is that it is paid once: 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 under it saying what to check. A badge never gets that far, because a badge has nothing under it.

    The Outcomes on similar loads card, expanded: 38 of the last 40 on time, a note that the history is illustrative, two numbered lines headed What to watch for on this load, and under a rule the two late deliveries listed with what differed on each.
    Illustrative outcome data. The summary gives the context; the two watch-for lines say what to check, on the card; the loads they came from are behind the disclosure. One of the two misses was not a ranking error, and says so.

  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, and 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 fleet is 1,200 pixels of interface because its argument is that seven trucks and five factors stay in reach at once. 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 a phone gets four columns and the rest folds into the row, one tap down. In reach has to mean findable, or the layout is quietly contradicting the claim.

    The whole fleet data table under a heading reading “The whole fleet” and a Comfortable or Compact row-height switch. Seven trucks ranked, each with distance, the time it would reach the pickup, hours left, equipment, on-time record and deadhead, a chevron beside the truck number that opens the row, and an Assign button. T-207 shows 3:04 pm marked “too late” and T-166 shows 2:49 pm marked “tight”. The last row, T-114, is marked Over hours, shows 3.2 hours against 5.5 needed, and its button reads Can’t assign.
    Every row opens on its own reasoning, the rows run comfortable or compact, and the one truck the rule removes keeps its row, its numbers and the reason.

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 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.

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 does not bend, the disagreement, the way back, and knowing when the system should stop.