Led the design of a human-in-the-loop AI system that automated Tesco's product categorisation, cut manual effort by approximately 72% and supported Marketplace's £200M first-year opportunity.
Tesco’s Marketplace was months from launch, and the system that kept products findable couldn’t cope. Colleagues in Online Operations could categorise around a hundred products a day each, on top of their other work. Marketplace would bring in millions of third-party products. The maths simply didn’t work.
The taxonomy platform had served the business for years, powering categorisation across Grocery Home Shopping. But it ran on manual effort, and that effort was slow and error-prone. A miscategorised product didn’t just sit in the wrong folder. It disappeared from Tesco.com’s navigation and search, which meant shoppers couldn’t find it. That was a direct hit to sales.
Desktop browser and mobile app showing Tesco.com's virtual aisles navigation
The business case combined future opportunity with an existing operational problem. Marketplace represented a £200M first-year revenue opportunity, while miscategorisation was estimated to be losing £6.5M each year. Marketplace was about to multiply product volume many times over.
Hiring our way out wasn’t an option. More people would be expensive, still wouldn’t match the induction rate, and wouldn’t fix the accuracy problem. Suppliers would be left waiting to get their products live, which would damage Tesco’s standing before Marketplace had properly begun.
Early concept of the HITL process
Early concept of the HITL process
Discovery
We spent four weeks with twelve main stakeholders, tracing a product’s journey from induction all the way to the customer-facing site. That meant working across very different domains: Product Induction and Online Ops Tech upstream, Product Intelligence and Data Enrichment feeding the taxonomy, and the Ecommerce teams for the .com site downstream, who consumed the categorisation and put it in front of shoppers. Each had its own priorities and language, so aligning them was part of the job. We ran workshops with each domain, mapped the whole lifecycle, and watched colleagues work.
The pain was clear. Categorisation wasn’t just slow, it was mentally draining. Colleagues had to interpret vague product descriptions, make judgement calls on ambiguous categories, and work without any real-time feedback on their progress.
Four problems stood out:
Scale
Even the best could manage around a hundred products a day. Marketplace’s volumes would create a backlog that grew exponentially. No amount of hiring could close that gap.
Supplier risk
Third-party vendors depended on swift, accurate launches. A bottleneck would strand their products and damage Tesco’s reputation.
Revenue
Miscategorisation was already estimated to cost £6.5M a year, and Marketplace depended on removing the categorisation bottleneck before launch.
Burden
The manual process consumed more than 20,000 colleague hours a year on repetitive, mentally taxing work.
Post-its with notes from research sessions
Post-its with notes from research sessions
Post-its with notes from research sessions
Kanban board showing upcoming, ongoing and completed work
The turning point
One product captured the problem perfectly. The F&F Textured Zip Neck Short Sleeved Polo Shirt in Navy. Its attributes, gender, sleeve length, neckline, fabric, could point it at several different categories. Automated systems made it worse, latching onto one keyword and routing it from “Polo Shirts” into “T-Shirts” entirely.
Two realities made human judgement essential. Supplier data was messy, often inconsistent or simply wrong, and AI alone couldn’t compensate. And AI couldn’t handle ambiguity. Vague titles, incomplete listings, products that genuinely belonged in more than one category. These consistently outstripped what automation could resolve.
Product detail page on Tesco.com showing a Polo Shirt, a single item that could point toward several categories
Shaping the solution
I started by mapping the core interactions on my own. How would operators review AI suggestions? What would approving, rejecting, or remapping a product actually look like? I wanted to work through these flows alone before bringing others in.
Once I had the foundations sketched, I brought them to whiteboarding sessions with the product and engineering teams. It wasn’t linear. We cycled through multiple passes, pressure-testing flows, exploring edge cases, and refining concepts. I turned the validated concepts into detailed user flows and wireframes, focusing on the review, approval, rejection, and remapping interfaces.
E2E System design concept of the Automated Categorisation process, from product induction to display on Tesco.com
Miro board showing the E2E flow wireframes
Miro board showing the E2E flow wireframes
The design
The answer was a human-in-the-loop system. AI handled the high-confidence categorisations automatically. Ambiguous cases went to human reviewers. Every correction fed back into the model, so the system got better over time.
High volume product induction and AI automated categorisation with the HITL workflow
The MVP gave colleagues different ways to review products depending on the work in front of them. A queue overview grouped products into Automatically mapped, Require approval and Unmapped buckets, with counters and trends to show where attention was needed. A categorisation table supported bulk review: colleagues could select products with checkboxes, then use a floating action button to approve, remap or reject the selection.
When one product needed a closer look, the Product Inspector brought its details and metadata into three panes. Product information sat on the left, the AI suggestion and actions in the centre, and a taxonomy tree on the right. Colleagues could approve, reject or remap a suggestion, drag locations into the assigned list and sort their priority. This in-Inspector tree was part of the MVP; a separate tree browser for navigating the taxonomy and scoping queue work shipped later. We also designed and tested product-variant views, but these were not part of the MVP.
The left pane shows the product title, description, imagery and relevant attributes, such as gender, sleeve length, neckline and fabric. Reviewers can see the context beside the decision instead of searching across systems and spreadsheets.
The product details pane keeps all the context a reviewer needs in one place
The centre pane presents the AI’s suggested locations and the controls for reviewing them. It shows the full taxonomy path, with actions to approve or reject suggestions individually or in batches.
The AI suggestion pane shows the proposed category and the reasoning behind it
The right pane lets reviewers browse or search the Inspector’s taxonomy tree, then drag categories into the assigned locations list to replace or add to the AI’s suggestions and sort their priority.
The taxonomy browser keeps the reviewer in control of assigned locations
Three principles shaped how people worked with the AI:
Transparency without overwhelm
The AI produced confidence scores, but we dropped them in the MVP. Testing showed numbers made people second-guess straightforward decisions. Instead, we used simple status cues: “Good to go” or “Needs review.” Post-MVP, we brought the scores back on request, with the data points and weighting the AI used as part of its decision.
Control at every step
Every suggestion came with three clear actions: accept, reject, remap. The message was clear. You’re the final decision-maker.
Feedback loops for learning
The system captured corrections and fed them back into the model. People weren’t being replaced by AI. They were teaching it.
Building and testing
Speed mattered, and so did the right fidelity. The main prototype was built in Airtable, which let us simulate near-realistic product data at scale with thousands of real Tesco SKUs, something visual-first tools like Figma couldn’t match with data this complex. Miro handled the quick mockups and flow illustrations, Axure RP the high-fidelity interactive prototypes, and Figma came in later for the hand-over to engineering, guaranteeing adherence to the design system and detailed specifications on functionality. Where existing components weren’t up to the task, we created new ones, added them to the design system, and ran them through Storybook for visual testing and accessibility compliance.
Data modelling in Airtable
Airtable prototype of the Automated Taxonomy Dashboard
Airtable prototype of a "Low confidence" bucket
High fidelity Axure prototype screens
I ran moderated usability tests with the Online Operations colleagues who’d actually use this in production. The scepticism was real. How would the AI interpret product data? How would it decide which taxonomy locations to suggest? If experienced colleagues got it wrong sometimes, how could a machine do better?
We also designed and tested a fuller dashboard for workload prioritisation. Concepts included AI-assisted themed bundling and prioritisation of products needing review, colleague review metrics, and AI performance statistics for transparency and data quality. Those explored capabilities should not be confused with what shipped in the MVP queue overview or with the later dashboard release.
Miro board showing screens and post-its from user research sessions
The testing cycles were fast. We gathered feedback, found friction points, and iterated within days. Under that deadline, we couldn’t afford to build something and hope it worked.
Building trust in the system became as important as building the system itself. If confidence scores made the AI look authoritative, people would defer to a machine they didn’t trust. So we stripped the numbers and used simple status cues. The system had to signal trust in the human, not the machine.
I ran a scoring workshop with the PM and engineering leads to decide what to do. We scored every candidate feature on value and effort, and filtering came out clearly on top. It was the thing people had asked for most, and it was the thing that would make the biggest difference to their day. So we committed to it, publicly, with a firm delivery date.
I kept the roadmap visible so everyone could track progress, and we shipped filtering three weeks after the MVP, with the fuller dashboard eight weeks later. Other features shipped after the MVP included the separate taxonomy/location browser for scoped review, filters including proposition, taxonomy location and confidence score, and quick lists for rapid reviews. Each delivery rebuilt a little more trust. By the time the dashboard landed, the scepticism had largely gone.
The outcome
The system went live across all Tesco online propositions before Marketplace launched. AI handled the volume, routing high-confidence products straight through and flagging the ambiguous cases for human review.
The categorisation system in use, with AI handling volume and colleagues reviewing exceptions
Screen showing a table with automatically mapped products
The three-pane HITL review interface
The results:
The system removed the categorisation constraint ahead of Marketplace’s launch.
Sceptical colleagues became advocates. Batch processing made routine work faster, detailed review remained for the complex cases, and the work became less tedious without losing rigour.
“I can finally focus on the interesting cases instead of wading through the obvious ones.”
Online Operations colleague, one week after launch
What I’d carry forward
The delivery constraint changed how I think about roadmap commitments. When filtering missed the MVP, publishing a specific follow-up date gave colleagues something concrete to judge us by. Shipping it three weeks later showed that a phased release could preserve trust, provided the trade-off was explained and the commitment stayed visible.
I also learnt to choose prototyping tools around the uncertainty in the work. Airtable was more useful than a polished visual prototype when the question was whether thousands of real products and their attributes would behave as expected. Fidelity should follow the decision a team needs to make, not the stage a project appears to have reached.
