Skip to the content
PA

PA Logistic

Design concepts · September 2026

For review

Three ways to rebuild the dispatch and finance platform.

All three cover the whole application — dispatch, invoicing, banking, the ledger, the profit sheets and administration — and all three run on the same realistic data pulled from the live schema. They are not the same interface in three colour schemes. Each starts from a different assumption about who is using the software and how hard they are working it, and everything else follows from that.

Open Approach 1 — Console Open Approach 2 — Workbench Open Approach 3 — Control Room Compare them side by side

Everything is clickable. No sign-in is needed and nothing is connected to the live system — the data is a static copy, so nothing you do here can affect production.

The two concepts

Approach 1

Console

A dense, fast operations console for people who use it all day.

The thinking

Assumes an experienced dispatcher who already knows the business and wants to see as much as possible at once. Small type, tight spacing, one accent colour, borders instead of shadows. The interface tries to disappear behind the data: forty loads should look like forty loads, not forty cards. A command palette on ⌘K reaches any screen or record in two keystrokes.

What changed

  • · Navigation regrouped from five mixed headings into Operations, Directory, Finance, Banking and Administration — things you work on, things you look up, things you configure.
  • · The loads table gains eight saved views with live counts, replacing five toggle chips and six dropdowns crammed into one toolbar row.
  • · The load record becomes five tabs instead of one very long form, with a paperwork checklist that says what is blocking the invoice.
  • · Every sort, filter and page lives in the URL, so a filtered view is a link you can paste into a message.
  • · The dashboard leads with a work queue, and uses a rolling 30-day window so the numbers still mean something on the 2nd of a month.

Strengths

  • · Most information per screen
  • · Fastest for a trained user
  • · Scales to hundreds of loads
  • · Feels like modern business software

Trade-offs

  • · Needs a short introduction
  • · 13px type is small for some readers
  • · Assumes the vocabulary is known
  • · Less comfortable on a phone
Open it Jump to the loads board Design system

Approach 2

Workbench

A guided, task-first interface anyone can pick up without training.

The thinking

Assumes the person is new, or does this occasionally, or is doing it on a phone in a yard. The navigation is organised by job, not by database table: Today, Move freight, Get paid, Track money, Set up. 16px type, 44px controls, thick focus rings, and plain words instead of field names — “Money you are owed”, not “Outstanding receivable”.

What changed

  • · The home screen is a to-do list, not a dashboard. Five jobs, each with a count and a button that opens a screen built for that job.
  • · Covering loads and reviewing the bank become one-at-a-time queues with a progress bar, rather than tables with row menus.
  • · Booking a load becomes a four-step wizard with a live margin calculation and a review step; what you type survives moving between steps.
  • · Browse screens are record cards by default, with a table view one click away for anyone who wants density back.
  • · Every screen opens with a sentence saying what it is for, and a collapsible explanation of the business rule behind it.

Strengths

  • · Usable on day one, without training
  • · Strongest accessibility (16:1 text contrast)
  • · Works properly on a phone
  • · Teaches the business while you work

Trade-offs

  • · Fewer rows visible at once
  • · More scrolling for a power user
  • · Guided queues can feel slow once learned
  • · More screens to build and maintain
Open it Jump to the covering queue Design system

Approach 3

Control Room

Minimum clicks, maximum visibility, for people running the desk all day.

The thinking

Assumes the software is someone's whole working day, and that the cost that actually hurts is navigation. So there are no detail pages at all — six workspaces, each the same three panes: a rail of views with live counts, a dense grid, and a context panel that fills in as you move the selection. Arrow keys walk the rows. Status and carrier edit in the cell. Nothing loads a page, so nothing loses your place.

What changed

  • · 29 screens became 9. Customers, carriers, places and factors are one Directory; users, roles, permissions, reference lists and the audit log are one Admin.
  • · Detail pages are gone. Selecting a row fills the right-hand panel — including the carrier's phone number, which in production means leaving the load entirely.
  • · Every row says what it is waiting on, in words, so "why can't I bill this?" is a glance rather than an investigation.
  • · Bank coding happens in the row. Category and division are inline selects; a recognised merchant offers "same again" as one click.
  • · Reports are already rendered, with last month beside every figure. There is nothing to generate.

Strengths

  • · 77% fewer clicks on everyday tasks
  • · No page loads at all
  • · Fastest possible for a trained user
  • · A third of the screens to maintain

Trade-offs

  • · The densest of the three by far
  • · Needs a real introduction
  • · Wants a wide screen to shine
  • · Inline editing means fewer "are you sure?" moments
Open it Jump to the loads workspace How editing works The measurements

Where they genuinely differ

The same job, done two ways. Open both links in a row and the difference is immediate.

Comparison of the two approaches
The job Approach 1 · Console Approach 2 · Workbench Approach 3 · Control Room
How you get around A sidebar of 18 entity links in five groups, plus ⌘K to jump anywhere. See it A top bar of five jobs, each with its own task list down the left. See it Six workspaces in one flat bar, plus / to search everything at once. No nesting at all. See it
Opening the app A dashboard: work queue, then money, then charts. See it A to-do list. The numbers are below the work, not above it. See it A command centre: five exception lanes with the money attached, today’s movements, then the numbers. See it
Finding a truck for a load Filter the loads table to “Needs a carrier”, open each one, pick a carrier. See it A dedicated queue: one load at a time, ranked carrier suggestions, target rate and margin on screen. See it Rail → Needs a truck; the carrier and its rate change in the row, and the panel ranks who runs that lane. See it
Booking a load One dense form with a sticky live-pricing rail. See it Four steps with a progress bar and a review page before anything is saved. See it One dialog over the grid, so the board never leaves the screen. See it
Coding the bank feed A workbench table with tabs, bulk selection and row actions. See it A triage queue: one transaction, one decision, with “remember this next time” built in. See it Category and division are selects in the row; a known merchant offers “same again” as one click. See it
Looking at a load Five tabs — overview, route, money, documents, activity. See it One page, in stages, with “what happens next” always on screen. See it No page. The context panel fills as you arrow down the grid — money, contacts, paperwork, tracking. See it
Getting invoices out Filter to “Ready to invoice” and work the list. See it A dedicated screen, grouped by customer, one invoice per customer. See it A billing workspace where every row names its blocker and the panel shows that customer’s whole ageing. See it
Reading a list Dense table, six composite columns, sortable, ~25 rows per screen. See it Record cards with the facts spelled out, table view one click away. See it Dense grid, ~35 rows per screen, expandable in place, editable in the cell. See it
Base type · controls 13–14px · 34px tall 16px · 44px tall 13px · 28px tall
Screens to maintain 30379 — six workspaces plus three reference pages
Page loads on a normal day DozensDozensNone. The workspace never reloads.
Text contrast About 12:1 About 16:1 About 14:1

Our recommendation

Approach 2's structure, Approach 3's workspaces underneath it.

The three concepts answer three different questions, and the honest answer is that PA needs two of them at once. Approach 2 solves the problem that the current app assumes you already know the business: it organises everything by what you are trying to achieve and says what things mean in plain words. Approach 3 solves a different problem — that someone running the desk all day pays a navigation tax on every single lookup, and that tax is measurable: 65 clicks and 22 page loads across ten everyday tasks, against 15 clicks and no page loads.

Approach 1 sits between them. Everything good in it — the composite load row, the ⌘K palette, the URL-addressable filters — appears in one of the other two, so it is the one to learn from rather than build.

In practice that means

  • 1. Take Approach 2's information architecture and language as the default — new and occasional users get the guided version, and nobody has to be trained to be useful.
  • 2. Build Approach 3's three-pane workspace as the "pro mode" for Loads, Billing and Money, where the same three or four people spend their whole day. Selecting a row must never load a page.
  • 3. Adopt Approach 3's two structural cuts regardless of which look wins: fold the four directory pages into one, and put the carrier's phone number on the load. Those alone remove the worst back-and-forth in the product.
  • 4. Keep Approach 2's 16px type and 44px controls for anything a phone will touch, and Approach 3's density only where a desk monitor is guaranteed.

If you only do one thing: open the measurements page. It lists ten tasks with the click count before and after, each traced to a specific line in the current code.

What we found in the current application

Both concepts were drawn from the real code — 19 API modules, 90 database tables and 29 existing screens — not from screenshots. These are the problems they set out to fix.

Navigation

Three navigation systems at once

A sidebar, a switchable top bar, and separate sub-navigation bars inside Dispatch, Finance and Banking. Reference data sat under Dispatch while Categories sat under Finance, though both are configuration.

Filtering

Fourteen controls in one toolbar row

The loads screen put a search box, two date fields, six dropdowns and five toggle chips on a single line. On a laptop it wrapped into an unreadable block, and nothing summarised what was actually filtered.

Forms

One very long booking form

Booking a load meant one screen carrying parties, stops, rates, charges and references at once, with no sense of how far through you were and no review before saving.

Language

Database wording on screen

“Outstanding balance”, “uncovered”, “dispatchType”, “POD”, “deactivate”. Each is precise and each costs a new person a question. Status was often a coloured badge with no explanation of what to do about it.

Dashboard

Twelve KPI tiles, no work queue

The dashboard mixed operational counts with user-administration statistics, and used a calendar-month window — so on the 2nd of a month it reported a collapse in volume that had not happened.

Empty & error states

Not distinguishing "none" from "no match"

“No loads found” appeared whether nothing had ever been booked or a filter simply matched nothing — and an empty inbox, which is good news, looked identical to a failure.

Worth keeping

The composite load row

The existing table already stacks related facts into six cells rather than fourteen thin columns, and colours customer money green and carrier money red. Both concepts keep it.

Worth keeping

The paperwork strip

Five slots showing at a glance what is missing on a load. Approach 1 keeps it compact; Approach 2 spells it out in words.

Worth keeping

Carrier restrictions and factoring

Blocking a carrier per customer, and paying a factor rather than the carrier, are real business rules handled correctly today. Both concepts surface them more prominently rather than changing them.

Every screen

76 screens across the three concepts, covering every page in the existing application. Each one has been drawn with its empty, loading, error and confirmation states. Approach 3 has far fewer files on purpose — collapsing twenty-nine screens into nine is the point of it.

Approach 1 · Console

Approach 2 · Workbench

Approach 3 · Control Room

Ten files, because collapsing the screens is the design.

How to read this prototype

The data is real in shape, invented in content

96 loads, 17 customers, 14 carriers, 140 bank transactions, 222 ledger entries, 120 activity records — all generated to match the exact shapes the API returns today. Names, rates and lanes are invented; nothing here came from the production database, and no real bank or tax numbers appear anywhere.

Everything is clickable, nothing is connected

Filters, sorting, tabs, dialogs and forms all work. Saving shows you what would have happened rather than doing it. The prototype never talks to the live API, so exploring it is completely safe.

Worth clicking specifically