Cross-functional product team including Product Owner, Business Analyst, UX Designer, Solution Architect, Front-end Developer, Back-end Developer and QA Tester.
Timeline
9 weeks
Overview
I led product design for Brambles’ entry into data-driven asset tracking, designing a customer-facing web portal powered by Bluetooth Low Energy-enabled pallets and contributing to a programme-wide design system for future supply-chain products.
Brambles wanted to move beyond traditional pallet pooling and create digital services that gave customers better visibility into how their assets were moving and behaving across the supply chain.
The product needed to translate complex tracking data into something useful: helping customers understand where assets were, what condition they were in, and where attention may be needed.
Alongside the portal, I also worked on the design system foundations. Existing component libraries and production code had started to diverge, creating inconsistencies and slowing delivery. Part of my role was to audit that fragmentation, define a clearer system direction, and support a more scalable way of designing and building future products.
The problem
Brambles was exploring how to turn asset-tracking technology into a valuable digital service for customers.
The opportunity was clear: BLE-enabled pallets could generate data about asset location, movement and condition. But raw telemetry alone would not be useful to customers. The product needed to turn that data into clear, actionable information that supported supply-chain decision-making.
There was also a second challenge inside the organisation. Design assets, component libraries and production code were not fully aligned, creating UI inconsistency and making it harder to scale new digital products efficiently.
The challenge was therefore twofold:
design a credible customer-facing asset tracking experience
create stronger design system foundations to support scalable delivery
My role
I led the product design work across both the asset tracking portal and the design system foundations.
My work included:
shaping the product experience for customer-facing asset tracking
translating BLE data and supply-chain requirements into clear workflows
designing portal screens, flows and high-fidelity prototypes
facilitating workshops with product owners, stakeholders and team members
extracting user needs from interviews and usability testing
auditing discrepancies between design libraries and production code
defining a migration direction toward a more unified design system
mentoring an in-house product designer
collaborating closely with engineering and architecture to support implementation
The project required me to balance immediate MVP needs with longer-term product and system scalability.
From transformation goal to product direction
A key part of the work was helping the team move from “we have tracking data” to “customers can make better decisions.”
Customers did not need a dashboard full of raw sensor information. They needed to understand what was happening in their supply chain and where they should pay attention.
That meant the experience needed to answer practical questions such as:
Where are my assets?
Are they moving as expected?
Are there signs of delay, loss or damage?
Which assets need attention?
What patterns can I understand across locations, journeys or customers?
This shifted the design focus from simply presenting data to creating a clearer decision-support experience.
Key design decisions
Prioritise actionable insight over raw telemetry
BLE-enabled pallets could provide a lot of data, but more data did not automatically mean more value. I focused the portal experience around clear asset states, alerts, summaries and drill-downs. The goal was to help customers understand what mattered quickly, then give them enough detail to investigate further where needed. This helped avoid creating a noisy dashboard and kept the experience focused on decision-making.
Design for exception handling
In supply-chain workflows, users often care most when something is not behaving as expected. The portal therefore needed to make exceptions easy to identify: assets that appeared delayed, misplaced, damaged or in need of intervention. This meant designing clear hierarchy around status, risk and next action, rather than treating every data point with equal importance.
Create scalable design system foundations
The product was not a one-off interface. It needed to sit within a broader ecosystem of future digital supply-chain services. I helped define an atomic design system structure covering components, tokens, states, layouts and data-visualisation patterns. This gave product and engineering teams a clearer shared foundation for building consistently. The design system work also helped reduce the risk of future products becoming fragmented or expensive to maintain.
Audit before migrating
Before defining a future design system direction, I audited the gap between existing design libraries and production code. This was important because introducing a new system without understanding the existing implementation would have created more drift, not less. The audit helped identify where components were misaligned, where duplication existed, and where a phased migration would be more realistic than a full reset.
Build internal design capability
Part of the value of the project was not only the product output, but the capability left behind. I mentored an in-house product designer, ran design critiques and shared ways of working that could support Brambles beyond the engagement. This helped strengthen internal design maturity and gave the team more confidence to continue evolving the product and design system.
Designing with technical and system constraints
The portal needed to align with emerging BLE hardware capabilities, available data, customer expectations and Brambles’ broader product strategy.
That meant the experience had to be credible as an MVP while still creating a foundation for future digital services.
I worked closely with engineering and architecture to understand what data could be surfaced, how reliably it could be interpreted, and how the interface could support future growth without overcomplicating the first release.
The design system work followed the same principle: create enough structure to improve consistency and velocity, without slowing the team down with unnecessary governance too early.
Research, testing and iteration
The design direction was shaped through stakeholder workshops, user interviews, usability testing and cross-team reviews.
Research and feedback helped clarify that customers valued interpretation more than raw data. They wanted to understand asset behaviour, identify issues and act with more confidence.
Feedback also helped refine:
how asset status should be presented
how users moved from overview to detail
how alerts and exceptions should be prioritised
how much data to expose at different levels
how the design system could support future workflows
The work was iterative, with portal design and system foundations evolving together.
Outcome
The project delivered a validated MVP direction for a customer-facing asset tracking portal and a stronger design system foundation for Brambles’ digital supply-chain services.
The portal helped translate BLE-enabled pallet data into clearer asset visibility, giving customers a more useful way to understand condition, movement and behaviour across the supply chain.
The design system work created a more consistent foundation for future products, reduced the risk of design and engineering divergence, and gave teams a clearer path for scaling digital services beyond the first portal.
The project also strengthened internal design capability through mentoring, critique and closer collaboration between design, product and engineering.
I do not have clean post-launch metrics for this work, so I am careful not to overstate the results. The clearest impact I can point to is that Brambles had a more credible product direction for asset tracking, a validated portal experience, and a clearer design system foundation to support future digital services.
What I learned
This project reinforced the importance of turning data into decisions.
In operational products, users rarely need more information for its own sake. They need the right level of context, confidence and prioritisation to decide what to do next.
It also showed how closely product design and design systems need to evolve together. When a company is building new digital services, the quality of the product experience depends not only on individual screens, but on the foundations that allow teams to keep building consistently.
For me, the most interesting part of the project was balancing short-term MVP delivery with longer-term scalability: designing something useful enough to validate the product direction, while creating patterns and system foundations that could support what came next.
Reflection
I chose this project because it shows how I approach complex B2B product design: understanding the operational context, turning technical data into usable workflows, and creating scalable design foundations that help teams move faster with more confidence.
It required product judgement, systems thinking, visual and interaction design, close collaboration with engineering, and the ability to make pragmatic decisions within a short delivery timeline.
