Owning the dashboard, not renting it.

The challenge

Brambles' customer-facing dashboards were built two ways, and neither one belonged to us. Some lived in Power BI, functional but never quite fitting how SCI customers actually worked. The rest ran on Brix, an internal dashboard system built on a third-party supplier's backend, and that supplier's fee had grown to the point the business was no longer willing to pay it.

That's a familiar shape of problem: a capability the business depends on, sitting on a vendor relationship that's stopped making commercial sense. The genuine opportunity wasn't just "build it cheaper." It was to use the vendor contract's renewal window as the moment to build a dashboard experience customers could actually shape themselves, our data, our frontend, tiered by subscription, rather than one fixed product handed down from a supplier.

Before that rebuild could start, there was a shorter, narrower job to do first: white-labelling the existing Brix dashboards into SCI's own look and feel, so customers experienced one consistent product while the real system was being built behind the scenes. I steered that transition, keeping it fast and visually consistent with SCI, precisely so it wouldn't need to be a story of its own. It bought the time the real build needed.

The opportunity wasn't a cheaper dashboard. It was a dashboard our customers could actually build themselves.

My role

I led product design on the customisable dashboard system for SCI, working across UX, research, implementation and customer-facing teams, and directly with engineering, to take it from building blocks to a shipped, tiered product.

That covered the design-system foundation the whole build sits on: the chart, table and metric components dashboards are assembled from, the flows for creating, editing and customising a dashboard, and the functionality that decides what a given customer is actually allowed to build, based on their subscription tier. With the deadline tight, I brought Dmytro, one of the strongest designers I've worked with, onto the data-visualisation components as a close collaborator rather than a hand-off; we co-created that piece together, and worked closely with implementation and customer-facing teams to validate what users on the ground, in the office and on the factory floor, actually needed a dashboard to tell them at a glance.

Every SCI dashboard, whichever tier or audience it's built for, is assembled from the same underlying set of components: chart blocks, table blocks and metric blocks, each with its own set of variations for the type of data and the level of urgency behind it. A supply chain lead scanning for a problem needs a different read than someone building a monthly performance summary for a customer meeting, so the block library had to support both without becoming two separate systems.

This is where I leaned hardest on AI-assisted tooling, not to replace the design thinking, but to accelerate the sheer volume of variation a real component library needs. Given the deadline, I brought Dmytro in to co-create the data-visualisation components with me, and together we used AI-assisted tooling to build out the chart, table and metric blocks in Figma, so a small team could produce a genuinely wide set of building blocks, and their states, in the time a contract deadline actually allowed.

Table and metric blocks followed the same logic: one component, several densities and states, rather than a bespoke table built per screen. A metric tile that shows a single number needs to behave the same whether it's reporting on-time delivery for one location or an entire flow, so the states, good, at-risk, breached, were designed once and reused everywhere a number needed to carry a verdict, not just a value.

None of this was building components for their own sake. Every block existed because implementation and customer-facing teams had validated a real user need behind it, working directly with the people actually building dashboards for Walmart, Costco and Tesco day to day, and with the archetypes on the other end of them: an office-based analyst with time to dig into a table, and someone on a factory floor who needs a single number to tell them, at a glance, whether to act.

Here's the library in full, every metric, table and chart variation, their sizes and their states, exactly as documented in Figma. Click it and use scroll or pinch to zoom in, drag to pan around.

Customers weren't meant to start from nothing. Depending on their subscription tier, a customer could be handed a pre-built starting dashboard, then customise it, add a tile, remove one, swap a chart for a table, or build a new one entirely from the same block library. Internally, account managers had the same building capability, so a dashboard a customer needed urgently didn't have to wait on an engineering ticket.

Tiering wasn't bolted on afterwards. What a given customer could build, start from a template versus build from scratch, a limited block set versus the full library, was a first-class part of the flow design from the beginning, because it's what let the business offer a genuinely differentiated product at each subscription level rather than one dashboard experience gated behind a paywall.

Editing an existing dashboard followed the same building-block logic in reverse: select a tile, swap what it shows, resize it, or remove it, without ever leaving the dashboard itself for a separate configuration screen. That mattered more than it sounds. A customer mid-conversation with their own stakeholders needed to be able to reshape what they were looking at in the moment, not raise a request and wait.

Everything above is the summary. Below are the two full Figma flows behind it, every state, edge case and annotation, exactly as they were designed. Click either one and use scroll or pinch to zoom in, drag to pan around.

Once the Figma building blocks existed, product, UX and engineering worked from them directly, building the frontend in React, using Claude in VS Code to turn a documented component into working code fast: build me a page, add this tile, wire this flow. That workflow is what let the block library become an actual product in weeks rather than months, without the usual gap between what got designed and what got shipped.

Brambles was testing AI-accelerated development more broadly at the time, and one strand of that testing produced a second version of the dashboard build, built quickly with AI tooling, but built outside the design system and without the UX patterns already validated and in production. It's an easy mistake to make precisely because AI removes the friction that used to force a check-in: building a parallel system from scratch used to take long enough that someone would ask whether it should exist. With AI, it doesn't, so the divergence can ship before anyone catches it.

The result reached implementation teams as something that looked finished but wasn't usable. It's the clearest, most direct evidence I have that a system, however fast it lets you move, only earns its speed if what it produces is still coherent.

I pushed back on it directly, not to defend a design file for its own sake, but because a working, validated version already existed, and rebuilding around it from scratch was costing the business real time against a customer-facing deadline. I made the call to pull the parallel build back under the same system rather than let it keep drifting, brought the product owner, lead engineer and Dmytro back round the same table, and got the support signed off to close the gap fast without slipping the deadline it had put at risk. The fix wasn't to slow AI-assisted development down. It was to point it at the system that already worked.

I led that realignment personally, getting involved directly in the AI-accelerated build itself rather than reviewing it after the fact, working alongside the product owner and lead engineer, and with Dmytro back on the data-visualisation components, to make sure it was working from the same component library, the same Figma blocks and the same validated UX patterns as everything else on SCI. That's the actual difference between AI as a shortcut around good process and AI as an accelerant for it: the same tooling, pointed at a system instead of around one, with someone accountable for making that call.

Once that realignment happened, the numbers the implementation team had been living with reversed. Dashboards that had taken up to six hours to build, and still weren't right, came down to minutes, because assembling a page from validated, documented components is a fundamentally faster job than reverse-engineering a UX pattern from scratch every time, AI-assisted or not.

The component library didn't stay inside this one project either. Three more Brambles products have since adopted the same dashboard components and the same customisation UX to build their own dashboards, and the library itself has been folded into Brambles' official design system, not as a handful of atomic components like buttons and inputs, but as full patterns: the chart, table and metric blocks, and the flows for assembling, editing and customising a dashboard, that other teams can now build features from directly rather than design from scratch.