Tracking the world's supply chain, one trip at a time.

The challenge

A marker on this map is never just a pin. It is a pallet of vaccines, a container of fresh produce with a clock running against it, or a part that stops a production line if it does not arrive on time.

Brambles moves physical assets through more supply chains than almost any other company on earth. Supply Chain Illumination (SCI), the platform I design for, exists to answer a genuinely hard question at that scale: where is a given asset right now, is it on schedule, and is it still in acceptable condition, across 300,000+ supply chains and 352 million physical units in more than 60 countries.

It was always going to be right to show the entire network at a glance. Hiding that scale would have been dishonest about what the product actually does. The harder problem, the one I actually had to design for, was speed: how fast someone could go from "here is the whole network" to "here are the handful of assets, locations and trips that need me right now." That is the same tension I designed for on the Discovery case study, what a screen shows and what a user actually needs to know are rarely the same thing, and the gap between them is where the real design work happens.

Showing the whole network was the easy part. Making it fast to filter down to what mattered was the actual design problem.

My role

I own the UX for the Network Map, Trips, Asset Visibility and Locations surfaces on SCI, as Principal Product Designer at Brambles.

That covers the interaction design for individual screens, trip summaries, condition charts, timelines, asset and location detail drawers, and the underlying rules that make the system hold together at scale: what a cluster is, when it breaks apart as a user zooms in, what colour communicates about asset condition, and how those rules stay consistent whether someone is looking at a single trip or the whole network.

The map system itself outgrew SCI. It's now the shared map language behind five Brambles products, maintained by 21 UX team members rather than by one person's design file, the clearest evidence I have that a pattern was actually solving a real problem, rather than just meeting one team's spec.

SCI's maps are built on Mapbox as the core map engine, chosen for a stable base map, strong performance at scale and flexible styling that supports light and dark themes. Mapbox handles pan, zoom and the default viewport. Everything a user actually recognises as "the SCI map", the markers, the clusters, the trip lines, the side panels, is a component I design and specify on top of that foundation, built to stay consistent with the Brambles Design System rather than inheriting Mapbox's own visual defaults.

I also built these components in code, using AI-assisted tooling, not just in Figma, so that when a new screen or feature was being explored, in SCI or on another product entirely, the team pulling from the system was working from something they could actually drop in and test, not a static reference. The gospel Figma file and the codebase are kept in sync deliberately, updating one without the other defeats the point of having a design system at all.

The three rules below, what a cluster is, what a marker is, and what colour means, are the foundation everything else on the map is built from, so they're the ones worth walking through here. The wider system goes considerably further: viewport behaviour, search, the mini filters and full filters panel, a dynamic key that only ever shows what's actually visible on screen, and the asset detail, location detail and timeline components those markers and clusters open into, are all documented and componentised the same way.

What is a cluster?

On the Network Map, a cluster groups multiple assets or locations that sit near each other, so the map reads at a glance instead of drowning in individual pins. Clusters use iconography for what's actually inside them, a store, a manufacturing site, a mix of asset types, rather than a single generic dot, and that iconography gets more specific as a user zooms in. As a user zooms further, clusters break down into individual asset and location markers, or into smaller, more specific clusters within the original one.

What does colour mean on the Network Map?

Colour tells a user what state a cluster or marker is in before they click anything. Blue means moving assets. Purple means assets dwelling at a known, expected location. Red means an unidentified dwell, an asset sitting somewhere it has no reason to be, which is often the first signal of something lost or stolen. This is deliberately a different colour language to the one used on Trips, because the Network Map is answering "where is everything and what state is it in," not "is this specific shipment on track."

What is a marker?

An individual moving asset gets its own halo or pulse marker, a visual cue that something is live and in transit. Once an asset stops moving, whether at a known location or an unidentified one, it groups into a cluster with the relevant location marker rather than sitting on the map as a lone dot. We're also exploring sizing dwelling markers by how long an asset has been sitting still, so the map itself could eventually start answering "which of these has been here too long," but that isn't shipped yet, it's a direction we're actively testing, not a live rule.

What changes when a trip is shown individually?

Displaying a single trip on its own surfaces a level of detail the cluster-and-marker language above deliberately leaves out: the poly line itself, directional arrows along it, a departure location, stopped location pins, a last-seen location pin or a moving circle, information bubbles and waypoint markers. None of it replaces the rules above, it's the same visual language with the volume turned up, because reading one shipment is a different task to reading three hundred thousand of them, and it needs the extra detail to match.

These are not incidental UI decisions. They are the rules that let the same map component work whether it is showing 12 assets or 12,000, and they are documented once, as design-system reference, precisely so a designer joining another SCI surface, or another Brambles product entirely, inherits the same logic rather than reinventing it.

Layers, and building for the next feature before it exists

The Layers panel controls what the map shows. By default, both asset and location layers are enabled. Turning a layer off removes everything tied to it in one action: markers, clusters, filters, search results and legend entries, so the map never displays or filters data a user has deliberately hidden. I've since prototyped a dedicated Unidentified Dwells layer in code, so a user can isolate exactly the assets that most need investigating without filtering through everything else first, and Trips is the logical next layer type to design once that ships.

The most recent release of Layers shipped a globe and flat map projection toggle: a genuine accessibility feature, not a visual flourish. Some users experience motion sensitivity from a rotating globe view, and some logistics tasks, planning a route, scanning distances, are simply easier on a flat projection, while others, understanding long-haul network coverage, read better on a globe. Both states are clearly labelled, keyboard accessible and screen-reader friendly, and the projection choice persists across every map in the product until a user changes it again. The same is true of map style: whichever base style a user picks, Light, Dark, Outdoors or Satellite Streets, is remembered as their preference and carried across every other map surface in SCI, so they're not resetting it screen by screen.

Designing for that toggle meant writing the acceptance criteria before the feature existed: what "globe view" and "flat view" needed to mean to a screen reader, how focus should move, what should and should not reset when a user switches. That is the same discipline behind the cluster and marker rules above, decide the system's behaviour once, in writing, so every team building on top of it inherits the same standard.

A trip follows a single asset's most recent journey: its start location, every dwell in between, and its end or current location. This is a different job to the Network Map, so it uses a different visual language. Trip lines between dwells are blue by default, and switch to show breached versus optimal duration segments the moment a user turns condition on, so a customer can see exactly where along the route a problem happened, not just that one did. Location markers on a trip follow the same logic: black by default, turning red the moment a breach is recorded at that specific dwell, whether the asset was sitting still or moving between two points.

The trip summary page was designed so the two questions that matter most, where is this shipment, and is it still in acceptable condition, are both answerable without a click. Route, dispatch point, last-seen location, duration, and live temperature and shock condition sit on the same screen. The same components then scales down to a compact summary for a table row, and up to the full trip detail view, one pattern, several densities, rather than a second design built from scratch for each context.

When something has actually gone wrong, the same temperature and shock data drives the condition chart below: the full trip plotted against optimal, low-risk and high-risk threshold bands, with a date-range slider and zoom controls to jump straight to the moment it crossed the line rather than scanning a whole journey by eye. A shock spike can mean a hard brake or collision, a slow temperature climb can mean a failed refrigeration unit or a door left open across a long route, and the same smart devices can flag an unexpected change in light or weight on a stationary pallet, a signal something was opened or removed while parked. Insights on Arrival, a separate SCI module, answers the related but distinct question of what condition a shipment was in when it reached its final destination, using this same underlying data.

Trip timeline

The timeline view answers "what actually happened on this trip" with a route map, numbered stops, dwell time at each one, and incident markers dropped directly onto the map rather than buried in a log. A separate log view exists for when someone genuinely needs the raw sequence of events, but the map stays the primary way to understand a journey, because a route with a red marker on it tells a faster story than a table ever will.

The vertical timeline on the map has a horizontal counterpart too, a compact road strip that sits directly under the condition chart on the trip summary screen. Same dwell and location logic, laid out left to right instead of top to bottom: a purple bar marks dwell duration at each stop, and a truck icon marks the asset's current position, blue while moving, purple while dwelling, green once delivered, headlights on only when it's genuinely in transit. It's a small component, but it's what lets someone reading a temperature spike on the chart above see, in the same glance, whether the asset was parked at a stop or actually moving when it happened.

A trip is also made of legs, the pathway between any two locations on it, and exploring legs breaks the route into those individual segments, Leg 1, Leg 2, Leg 3 and on, each carrying its own breached-or-clear status rather than one verdict for the whole trip. A trip with a single bad leg out of six shouldn't read the same as a trip that failed start to finish. On the map, a leg is marked by its own square pin, sitting centrally over that leg's poly line rather than at a location, so a user can identify which segment they're looking at at a glance. Selecting a leg keeps the map and the timeline list in sync, so a user can jump between a leg on the route and its detail in the list without losing their place.

A flow is a regular journey a customer's product takes on our pallets, a factory to a store, a warehouse to a distribution centre. A route is one way of actually running that flow, factory straight to store is a route, factory via a warehouse and a distribution centre is a different route for the same flow, and most flows have several. A trip is a single completed instance of one of those routes, on one date, with one asset. Same shipment lane, three different lenses: a flow tells you whether the lane as a whole is healthy, a route tells you which path through it is fastest or slowest, and a trip tells you what actually happened on one journey.

Opening a flow breaks it down into its routes, each one the same lane run a different way, with its own relevant locations and its own fastest, slowest and average cycle and dwell times. This is where the useful comparison sits: two routes serving the same flow, one consistently faster, and now that difference is visible and attributable rather than buried inside a single blended average.

Neither screen has a map yet, and that's deliberate rather than an oversight, everything above is still list-and-table work, not spatial work. It's the next map design challenge on this product: the same cluster, marker and trip-line language from earlier in this case study, applied one level up, so a route's dwells and an underperforming leg are as visually obvious on a map as a single trip's breach already is.

Assets and Locations exist as standalone modules too, searchable lists of exactly what's already plotted on the Network Map, for the operations users who think in a list first and a map second. Neither module invents a new pattern to get there: the same search, sort and filter language carries over from Trips and Flows, so a user who has already learned to work one list already knows how to work these.

A row in either list isn't a dead end. Clicking a location opens the same location screen a marker on the Network Map opens, boundary, address and movement metrics over a live map. Clicking an asset opens straight into that asset's journey timeline, the same journey a user would reach by clicking its marker on the map. List and map are two doors into the same rooms, not two separate features to build and maintain.

Illuminate switches the Network Map into a dark, high-contrast mode built for looking at many trips at once rather than one. Every trip on screen renders by condition, breached in red, optimal in green, so a supply chain lead scanning the whole network can see where problems are concentrated without opening a single trip to check. It's the same red-versus-green language this case study has used from a single trip line onward, just pointed at a few hundred shipments simultaneously instead of one.

Zooming into a specific area keeps the same colour language but adds a way to narrow it: a condition filter switches the map between optimal, breached or all trips, and a trip list on the right groups everything currently in view by status, not dispatched, dwelling, moving, delivered, so a supply chain lead can go from "where are the problems" to a filtered, countable list without leaving the map.

Showing that many trips at once changes what the next useful view actually is. The obvious next step is heat mapping, clustering breach density by geography so a region with a disproportionate number of red trips stands out at a glance, the same "spot it before it's a ticket" principle behind the cluster and marker language earlier in this case study, applied at portfolio scale instead of a single shipment. This is early, a toggle and a colour language proven at trip level, not yet a finished heat-map product, but it's the direction the map naturally wants to go once condition data exists for every trip in a supply chain, not just the one someone happened to open.