Running the practice, not just the product.

Supply Chain Illumination (SCI) sits inside Digital Customer Solutions and follows the wider DCS Jira model: intake and triage, product shaping, delivery, and artefact linking from product discovery through epics to releases. I didn’t change that model. I added the execution layer UX was missing inside it, using Jira capability the team already had, multiple boards on a shared backlog, rather than asking engineering to change how they work.

Read the board in the hero from the top left. Bugs and enhancement requests from customers, support and internal teams arrive through a central intake before anyone has made a prioritisation or delivery decision. They land in the shared backlog: visible, unprioritised, not yet assessed for risk. Being there doesn’t mean it will be built. In Triage is where delivery risk is assessed and routing decided, by the Product Owner, the UX designer, the UX researcher and, when needed, engineering. The questions are the same every time: do we understand the problem space, is discovery needed, is design needed, is feasibility already known, is this low-risk and well-specified enough to go straight to Dev. That maps directly onto the value, usability, feasibility and viability risks a product trio is there to manage.

Shared triage is about choosing the right path, not committing to delivery.

Once requirements are gathered, work enters the SCI UX board and moves through six states: UX Triage decides how, or whether, UX should approach it; UX Discovery reduces uncertainty with research, exploration, concepts and early validation; UX Design defines a delivery-ready solution with high-fidelity designs, interaction detail and feasibility alignment; UX Review checks quality, alignment and risk; UX Acceptance completes the final work, including the delivery-ready file, with design intent and risks made explicit; and UX Complete is the handover point. Between each stage the word on the board is reiterate, because the model expects loops, not a straight line.

The ceremonies hang off the board rather than living in people’s calendars. A monthly UX Discovery Share reaches the product trio, feedback welcome. A weekly UX Design Share reaches the trio and the content team. Dev refinement runs weekly, with engineering in the room, and it is where feasibility gets argued while the design can still change, not after. Engineering also sits in shared triage when the risk calls for it, so by the time a ticket reaches handover the engineers have usually seen it three times. Not all UX work starts in the shared backlog, and I made that explicit rather than leaving it to be argued each time: research-driven initiatives, holistic experience reviews, foundational discovery, usability-lab outcomes and exploratory concept work begin directly on the UX board, may never enter the delivery backlog, and are valuable even if nothing follows. Protecting discovery from being forced into delivery prematurely is the single most important thing the model does.

UX readiness does not equal Dev commitment. Triage is the discussion.

The loop at the bottom of the hero diagram is the part I’d defend hardest. Done and released is not the end of the line. User feedback and usability findings after release feed back into discovery, and may generate new discovery or enhancement tickets. That is what makes the model research-driven rather than request-driven: customer calls, usability labs, analytics and support patterns are inputs with a place to go, not opinions competing with the backlog.

A word on method, because it matters for how the model is built. Engineering at Brambles runs closer to waterfall than agile, led from engineering leadership. In my first year, in the Digital Scoping Squad, I acted as scrum master and delivery lead as well as designer: sprints, stand-ups, reviews, retros, the full set. When I moved into DCS we carried some of that on under Karen’s leadership, and the delivery side has since settled back into a sequential rhythm. The board is designed for that reality rather than the textbook. UX runs dual-track and iterative inside its own board, the way the Playbook I wrote in Chapter 05 describes it; engineering gets one clean gate and a weekly refinement where feasibility is argued early. Both sides keep the way of working that suits them, and the handshake is where they meet.

I brought this from smaller ecommerce teams, where a designer who couldn’t report a bug clearly simply didn’t get it fixed. Without a structured way to report UX and design bugs, critical inconsistencies get missed or deprioritised and the shipped product drifts from the experience that was tested. So I wrote the approach down, with a template, a prioritisation scale and worked examples. It started on Trips, SCI’s most-used feature, and the framework is now used across other SCI features and by other product teams in DCS.

Three lenses, and the first one is the one people forget. Does it behave? Interaction and UX functionality: touch as well as mouse, keyboard as well as pointer, every state the design specified, every filter doing what its label says. Does it look right? Spacing, sizing, type, colour and component use against the design system. Does it read like a human wrote it? Labels, formats, units and empty states. A pixel bug is easy to see. A control that ignores touch on an iPad is the one that loses a customer.

Priority is normally decided at triage by QA and the PM. I argued UX should have a say too, and wrote the scale we use so that a design bug has a place on it rather than being waved through as cosmetic.

The examples matter as much as the template, because they show the range of what “design bug” means. Three from the Trips feature, anonymised only as far as the product needs:

Functional QA asks “can I get to the next page?” Design QA asks whether the page is the one we tested.

This is the practical half of what “UX Governance and Design QA” means on my CV. The other half is the review and acceptance stages on the board in Chapter 01, where design quality is checked before it ever reaches a developer, and the QA channel I set up so UX is represented in QA conversations rather than finding out afterwards.

The hierarchy is deliberately plain. A workspace is a product: SCI. A project is a workstream inside it: the home page, Retail Promotions, Trips, end-to-end quality assurance. A file is a feature within a workstream, holding everything from exploration to production. And each file has the same pages: a cover that shows the feature name, Jira reference and status when you look at it in the project folder, then details, exploration, interaction design, prototype, production and handover, and a sandbox. Only one page is mandatory, Interaction Design, because that is where the final designs and their documentation live.

Two production habits ride on top of the structure. Use Figma’s annotations for interaction behaviour, content guidance and user-story context, on the frames themselves. And always embed the Jira epic or ticket reference, so developers, QA and content can find the design without asking. Small rules, but they are the ones that make handover independent of who did the work.

The standard’s test came when we needed a single source of truth for SCI: a “gospel” Figma file mirroring the staging and customer environments exactly, UX, functionality, styling and content including wording and casing, with every screen a liftable component with interaction variants. It is built on the design system’s components, which is what makes it useful twice over: designers lift screens into feature files for quick layouts and reviews, and the same components are what the AI builds are composed from. I wrote the brief and handed the build to Dmytro Ivanchenko, a designer I mentor, with the scope, checklists and governance rules spelled out.

That is what mentoring looks like at Principal level most of the time: not sitting beside someone, but writing a brief clear enough that they can own the work and come back with something I can review rather than redo.

Where Figma stops and the AI workflow starts

Some of the file standard above is now less important than it was, and I’d rather say so than pretend the page is frozen. Over the last year I set up the AI Playground: a working product built from the design system’s React components by directing Claude and OpenAI Codex in VS Code, with GitHub Copilot inline. I tested the workflow on my own features first, then opened the repo to the team. It is now a shared repo other designers build on, with Dmytro’s agent composed from the same components and rules, and it changes every week, which is the point.

A prototype you can click through tells you what people think. One that behaves on real data tells you what they’ll do.

In 2025 I moved from Senior UX Designer to Principal. The title caught up with scope I’d been carrying for a couple of years, but the process was still worth doing properly, because it made me write down what a Principal actually does differently. My transition plan had four objectives, each with a goal, a set of tasks, and an honest impact rating: impact on others, impact on me, done, doing, to do. My manager and I reviewed it monthly.

The promotion landed, and none of it stopped. Most of what a Principal does is invisible on a screen and continuous, which is why it belongs in a case study rather than a job title.

The vehicle for all of it is the product trio. I work in one with the Product Owner and the engineering lead, in the key product and vision meetings with leadership, and in roadmap planning, where design has a seat because the evidence comes with it. That is the part that makes the process data- and research-driven rather than opinion-driven: customer calls and site visits, the usability labs, the analytics and the support patterns all arrive through UX, and they arrive with a place on the board to go.

The biggest piece of writing-it-down came early. In 2023 the UX Chapter Lead needed the wider business to understand what UX at Brambles was for, and I wrote the UX Playbook for him: 65 pages, eight sections, from what UX is and the two principles we work to, through who we work with and why the product trio matters, who the team are and where they sit, the craft (Double Diamond, dual-track discovery and delivery, the competencies), our value proposition against the company’s strategic priorities, how the value of UX gets measured, and what was coming next: accessibility, design systems and working closer with customer experience. Much of what is on this page was seeded there before it was built.

Mentoring, formal and otherwise

In 2023 I joined the company’s cross-functional mentoring programme on both sides at once. As a mentor, I worked with a senior finance analyst who could do the analysis but struggled to tell the story of it to country leadership: a monthly hour on Teams, an objective statement each of us signed up to, SMART goals on a shared board, techniques from my own trade (executive summaries, hypothesis-led structure, narrative arcs, storyboarding a presentation before building it), a role-play where he presented to me as a hostile audience, and written feedback afterwards on what worked and what to change on which page. As a mentee, I was paired with a senior delivery leader on leadership and influence, because the honest version of a development plan has you learning as well as teaching.

The everyday version is less structured and just as deliberate. Mentoring designers in the UK, Spain, the USA, Canada and Australia on craft and systems thinking. Mentoring outside design too, which at Principal level is most of it: researchers on interviewing and evidence gathering, QA on what a design bug is and why it matters, technical writers on how the UX principles apply to content, the finance analyst above on storytelling. The principles are the same; the job is adapting them to someone else’s craft. Internal conference talks on UX and AI, and regular slots at Digital All Hands in front of 200+ people, which is how the AI Playground became something other designers adopted rather than a personal tool. Interview panels alongside the Head of UX, with several of those hires performing strongly since. The first live-streamed usability lab at Brambles, which put customer evidence in front of people who had never watched a session. And a small tips space I set up off the back of the weekly team meeting, where the Design QA guide was the first entry and other designers’ tips followed.

The best mentors don’t create followers. They create people who no longer need to be led.

My own output has limits; influence doesn’t. Helping ten people get slightly better is worth more than ten more pieces of my own work, and the measure of any of it is what still works when I’m not in the room.