--- title: "UI/UX design for logistics" description: "UI/UX design for logistics dashboards: live tracking, dispatch and alerts arranged so the one late vehicle is obvious, as in our Fleet Console concept." canonical: "https://goodtogrid.com/services/ui-ux-design/logistics" updated: "2026-10-02" --- # UI/UX design for logistics > UI/UX design for logistics dashboards: live tracking, dispatch and alerts arranged so the one late vehicle is obvious, as in our Fleet Console concept. URL: https://goodtogrid.com/services/ui-ux-design/logistics · Industry · Updated: 2026-10-02 A dispatcher watches dozens of moving vehicles and needs to spot the one that's in trouble. We design logistics interfaces where normal stays quiet and problems are impossible to miss. - **Service:** [UI/UX Design](https://goodtogrid.com/services/ui-ux-design) - **Industry:** Logistics - **Backed by:** 1 case study · 1 concept - **Updated:** 2026-10-02 ## What logistics teams run into - **Everything moves, nothing stands out.** A map full of moving dots treats the late van like the nine that are fine. The design has to rank vehicles by how much attention they need. - **List, map and detail out of step.** Dispatchers lose time matching a row to a dot. One selection should drive the list, the map and the detail panel together. - **Phone calls as the status system.** When the screen can't say why a driver stopped, dispatch calls. Clear idle, late and off-route states cut the calls down. - **Customers asking where their parcel is.** Dispatch is often the one answering. The console should make it quick to see an arrival time and send an update. ## Constraints we design for - **Drivers' location data.** A driver's position is personal data under UU PDP. Tracking should be limited to working hours and its purpose, and drivers should know when it's on. - **Drivers shouldn't look at screens.** Anything the driver side asks for has to be safe to do while stopped. Alerts for dispatch, not interactions for someone at the wheel. - **Patchy coverage on the road.** Positions arrive late or not at all in dead zones. The interface has to show how old a position is, rather than presenting stale data as live. ## Features that keep coming up - One selection driving list, map and detail - Late, idle and off-route states raised on the server - Grey for on-time vehicles, colour only for action - Quiet vector map tiles that keep markers legible - Last-seen time on every position - Stop lists and arrival times per vehicle - A shortcut from an alert to a customer message ## Typical builds - [Fleet tracking dashboard design](https://goodtogrid.com/solutions/fleet-tracking-dashboard) — Live tracking and dispatch for a delivery fleet, designed around exceptions rather than every moving dot. ## How we approach it We design dispatch tools around the question they're asked all day: where is it now? In the Fleet Console concept, one selection drives the list, the map and the detail panel, so the answer is in one place. Then we decide what deserves colour. On-time vans stay grey. Late, idle and off-route are the only states that light up, because they're the ones dispatch has to act on. A screen where everything is highlighted is a screen where nothing is. The map is kept quiet on purpose: muted vector tiles, few labels, markers that stay readable when they bunch together in the depot. The rules for raising alerts live on the server, so every dispatcher sees the same picture. ## Related work _Studio concepts: designed and built by the studio to show the approach, not client work._ - **[Fleet Console](https://goodtogrid.com/work/fleet-console)** — Live tracking and dispatch for a delivery fleet. _Studio concept · Logistics · Web app · 2025_ ## Frequently asked questions ### Is Fleet Console a real client system? No. Fleet Console is a studio concept, and a design project only. It shows how we'd design a dispatch console; we don't claim deliveries or results for it. ### Can you build the console too? Fleet Console itself is design-only. Building a live tracking web app is in scope through our web development service, and we'd scope the data side, the driver app and map tiles, with you. ### Do you design the driver app as well? It can be part of the same project. The concept assumes positions stream from a driver app; designing that app means designing for someone who is mostly driving. ## Read next - [Fleet tracking dashboard design](https://goodtogrid.com/solutions/fleet-tracking-dashboard) (Solution) — Live tracking and dispatch for a delivery fleet, designed around exceptions rather than every moving dot. - [Live map and tracking interfaces](https://goodtogrid.com/technology/live-maps) (Technology) — Maps that move in real time, or keep working with no signal, and how we design both. - [UI/UX design](https://goodtogrid.com/services/ui-ux-design) (Service) — Research, flows, prototypes and design systems, from the people who build them. - [Dark interfaces without the mud](https://goodtogrid.com/blog/dark-without-mud) (Note) — Three surface steps, one accent, and borders that do the work: the rules we follow for dark UI. [Start a project](https://goodtogrid.com/start-new-project?service=uiux#brief) · [All by industry](https://goodtogrid.com/services)