Modernising Internal Operations at Scale

Overview

When I joined Next's warehouse operations division, there was no design function, no research practice, and no shared design language — independent of the existing ecomm design team elsewhere in the business. I built all of it from the ground up. Working across operational tools that support up to one million packages a day, I cover six product sets — designing complex applications while creating the infrastructure to make design sustainable and independently owned.

The challenge

Next's internal tools had grown organically alongside the business. The result was fragmented interfaces that weren't keeping pace with increasingly automated logistics. Teams were using tools that couldn't represent the complexity of modern fulfilment, and there was no shared design language across products.

Understanding the users

Before I joined, product decisions at Next were made without structured user input. I established the research practice from scratch — designing the methodology, running 150+ moderated sessions over three years, and building qualitative insight across every role and operational context. Watching how staff actually used tools in practice was especially important. Operational users are domain experts. The gap between what they describe and what they actually do is often significant.

I designed a structured participant database — capturing roles, workflows, pain points, and session history — so research could be repeatable and institutionally owned, not rebuilt from scratch each time a new question arose. That gave the team lasting knowledge, made recruiting easier, and shifted research from ad hoc conversations to something the product team now runs independently.

The design work

The six product sets I worked across covered genuinely varied ground, each with its own user base, operational context, and design challenges.

Management dashboards required translating high-volume, fast-moving operational data into interfaces that gave managers a clear picture of what was happening across the business at any given moment. The challenge was less about information architecture in the abstract and more about understanding what decisions these users actually needed to make, and designing around those rather than around the data itself.

Payment processing applications served back office teams where accuracy and auditability were critical. Supporting users who were highly experienced with their processes, while reducing the risk of error in high-stakes tasks.

I prototyped extensively throughout, using Figma and Figma Make to simulate automated states, edge cases, and handoff moments between human intent and system execution. This was essential for aligning engineers and stakeholders on behaviours that were difficult to describe in static specs, and for pressure-testing designs before any development investment was made.

Building a design system in Blazor

Fragmented components across six product sets were slowing engineering and creating inconsistent UX. I identified this as the highest-leverage structural problem and proposed building a design system directly in Blazor — not a hand-off artefact, but production-ready code aligned with Next's existing stack. Working solo in VS Code with GitHub Copilot, that meant components could be adopted directly by dev teams without any translation overhead.

Building it with Copilot was a deliberate bet on AI-assisted development. It let me move faster than would have been realistic on my own, and gave me a much deeper understanding of how components behave in code. Handover to engineering teams was significantly smoother as a result.

Once the foundation was in place, I scaled adoption by forming a dedicated design system team of 10 developers drawn from across the six product sets. Existing relationships made it work. We had internal champions in each area, shared ownership, and a system shaped by the people implementing it rather than imposed on them.

I also built a component playground. A tool that let non-technical stakeholders like Product Owners mock up ideas using real components, without needing Figma or engineering support. It reduced back-and-forth in early ideation and got design thinking into the room earlier.

Championing AI across the design team

Beyond my own practice, I actively pushed AI adoption across the team. I ran presentations on integrating AI into design workflows: practical usage, where the tools genuinely add value, and how to think critically about their outputs.

AI literacy is becoming a core design skill. Getting the team comfortable early and helping them build good instincts felt like one of the more valuable things I could do.

Impact

Across six product sets, I've taken a design function from nonexistent to embedded — including research practice, design system, and tooling the product organisation can run independently. The design system gave those products a shared language for the first time. The component playground extended that to non-technical stakeholders. The 38% to 81% satisfaction lift wasn't a single feature — it was the result of sustained investment in research, systems, and building trust with engineering.

Reflections

Building a design function from scratch inside a large retailer has taught me that the work is never just the interface. It's earning trust, creating infrastructure, and bringing technical teams with you. The E3 warehouse work is the thing I think about most. Not because of its technical complexity, but because it required new ways of thinking about humans and automation working together.

Building the design system solo before handing it to a team of ten is probably the thing that best captures how I approach problems: start scrappy, validate fast, then build the structure that makes it last.