Adam Woollacott · Conversation Designer
← All case studies Case Study

Building a Generative AI Shopping Assistant

An LLM-driven shopping assistant that gives online shoppers a natural, conversational way to discover and get recommendations on retail products.

Conversation Design Prompt Engineering Behaviour Design Ontology Development Data Analysis UI Design
ONTOLOGY-DRIVEN CONVERSATION MODEL
My Role

Conversation Designer

I owned conversational flows, LLM behavior, ontology development, and UI design across the product's core surfaces, working closely with product, engineering, and leadership.

01

Conversational Flows

Designed the end-to-end dialogue structure shoppers move through.

02

LLM Behavior

Defined how the assistant should reason, respond, and handle uncertainty.

03

Ontology Development

Built the structured product/attribute model the assistant reasons over.

04

UI Design

Designed the interface surfaces the conversation lives inside.

Where I focused

Two areas of greatest impact

This case study covers the two problems that shaped the assistant most: what it does when it isn't sure, and how it decides what to ask.

Focus Area 01

Behaviour Design: Uncertainty

The ChallengeFraming the problem

The hardest design problem wasn't the happy path. It was deciding what the assistant should do when it wasn't sure.

What happens when a shopper mentions several things in one message, each mapping to a different ontology element, each with its own confidence score?
My AnalysisDiagnosing why

Using conversation design strategies, I designed a confidence-tiered behavior model in which the LLM responded differently per confidence level. This worked initially, but broke down when a single user utterance triggered conflicting confidence levels across multiple ontology elements at once; a single tier per element wasn't enough to handle overlapping cases consistently.

WORKED EXAMPLE: TWO VALUES IN ONE MESSAGE VALUE A VALUE B BEHAVIOUR EXAMPLE BOT RESPONSE High High Both confirmed implicitly "Sure, I can help with both [valueA] and [valueB]." High Mid A implicit, B explicit "Nice pick on [valueA]. Would [valueB] work too?" High Low A implicit, B ignored "Sure, I can help you with [valueA]." Mid Mid A explicit, B ignored "Just to confirm, is it [valueA] you're after?" Low Low Clarifying question (CTA) "Okay, tell me a bit more about what you need?" Each row is one slice of the full requirements matrix, with every confidence pairing mapped to a specific bot behaviour.
Adapted from the original behaviour-requirements documentation, showing how the matrix resolves two values mentioned in a single message.
The DecisionWhat I changed

I created a decision matrix to give the system one consistent rule for when to answer, when to verify, and when to stop, instead of reacting case by case inconsistently.

WhyThe reasoning

Case-by-case handling meant every new combination of confidence levels risked a different, unpredictable response. A single decision matrix meant the rule scaled with the complexity, rather than requiring a new rule each time.

OutcomeWhat shipped

This matrix became the basis for a multi-bot architecture. Partnering closely with engineering, we built a multi-agent system led by an orchestrator agent that routed each request to a specialized bot and system message, so the system only ever activated the logic relevant to that specific case.

This improved the user experience, reduced latency by a few seconds, and kept each agent's context narrower, faster, and more consistent. The same principle later shaped how I restructured the assistant's global system prompt as business rules and use cases grew, keeping it modular and in-scope.

Latency
↓s
Reduced by a few seconds
MULTI-AGENT ORCHESTRATOR ARCHITECTURE Shopper message Orchestrator routes by confidence outcome Answer Bot narrow, high-confidence system message Verify Bot disambiguates competing matches Clarify Bot asks a targeted follow-up question
The orchestrator routes each request to a specialized bot, giving narrower context and faster, more consistent responses.
Focus Area 02

Designing a Data-Driven Conversation

The ChallengeFraming the problem

Building an engaging conversation while collecting enough key shopper information to allow the recommendation engine to provide accurate product recommendations.

My AnalysisDiagnosing why

To ground the questions in real evidence rather than assumption, I combined two sources: usability testing and analysis of real conversation transcripts between online shoppers and sales reps. Together, these gave me both sides of the interaction: what shoppers naturally asked or expected, and what reps needed to ask to build an accurate recommendation. Understanding both perspectives was critical to designing questions that felt natural to shoppers while still serving the business's need for accurate data.

QUESTION TOPICS WEIGHTED BY REAL CONVERSATION DATA Budget range high Use case / occasion Style preference Brand affinity Prior purchases Sizing / fit details low LLM guidance weighting, not a script
Topics were weighted by how often they came up in real shopper-rep conversations, then handed to the LLM as guidance. This chart is illustrative, not the exact data used in production.
The DecisionWhat I changed

Early testing showed the LLM defaulting to the same fixed sequence of questions every time, producing conversations that felt repetitive and scripted. After aligning with leadership, it was clear the assistant needed a way to improve over time based on real data, rather than a static, one-time design decision. I analyzed real-world conversation data to weigh each question topic by how often it came up, then gave this weighting to the LLM as guidance rather than a fixed script, letting the model decide which questions mattered most for a given shopper.

WhyThe reasoning

Weighing questions based on live data meant the assistant's questioning adapted to context, closer to how a real sales associate would prioritize what to ask.

Closer to how a real sales associate decides what to ask.
OutcomeWhat shipped

A data-informed conversation that adapted to each shopper rather than following a rigid script, improving the conversational UX, providing a more interesting and varied conversation, and, as a result, helping deliver more accurate recommendations.

Conversation UX
More engaging, varied conversations
Recommendations
More accurate product matches
Get in touch

Want to know more about this project?