Academic project · conversational agent

Buy your bread without taking your hands off the wheel

A voice copilot that finds the product, checks that it's actually available and tells you where to park, before you even start the car.

Try the demo ↗

Timeline: [Timeline] · Master's in UX, IIM
My role: Field research, concept, system prompt, mockups, prototype
Team: [Solo or group]
Tools: Figma, Claude (API), ElevenLabs, OpenStreetMap, Vercel

The context

When driving, you don't choose a bakery for the quality of its bread. You choose it based on a simple question: will I be able to park?

The brief: design a conversational agent. I chose a specific audience, drivers who stop at a bakery on their way. Behind the wheel, you can neither read nor touch the screen: voice isn't an accessibility gimmick, it's the only possible interface. Boubou therefore had to do everything by voice, and remain reliable on information that nobody provides today: whether the product is actually available, and where to park the car.

My starting question: How can we give a driver, by voice and before setting off, the certainty that the detour is worth it?

5interviews with drivers, plus observations in front of bakeries

5anticipated agent failure modes, each with its cost and its safeguard

123products in the prototype's catalog

14 + 4iPhone screens and CarPlay screens mocked up

Boubou's home screen on CarPlay: the usual Tuesday order, 4 minutes away, 6 free spots

01Understand

Customers don't browse, they come to verify

Five interviews with drivers, observations outside bakeries, and Google reviews collected on site. One story changed everything.

“I'm going to get a tiramisu. But the tiramisu was still frozen. Since I wanted the tiramisu at that moment, I just walked back out and went to a restaurant next door.”
Rideshare driver, frequent customer

The purchase is decided before walking in. The display case isn't there to help people choose, it's there to verify. When the product is missing, the rest of the offer doesn't make up for it: customers don't look at alternatives, they switch to a completely different need. And a product that's in the display case but frozen simply doesn't exist for them.

Outside one bakery, I also watched a driver drop off his passenger, circle the block for lack of parking, then come back to pick them up.

Insight 1An unfamiliar bakery doesn't even make the list of optionsIf it's familiar, you know where to park and what you'll find. If it's not, you don't go: "I know that when I come here, I can park easily."Source: interview, rideshare driver

Insight 2Present but not servable means absentThe tiramisu was in the display case, but frozen. From the customer's side, there's no difference.Source: interview, rideshare driver

Insight 3One or two good suggestions, not ten"I don't want to have 10 choices." People will accept a few extra minutes if the product is guaranteed.Source: interview, occasional driver

Insight 4The information comes too lateParking as availability: everything is discovered at the counter, while the decision is made before starting the car.Source: interview synthesis

What I take from it

The real gap is upstream: knowing where to find what you want, and where to park, before making the detour.

Next step · 02 Design ↓

02Design

A voice that decides with you

Boubou steps in at the exact moment the driver is deciding. It cross-references two pieces of data nobody gives them: is the product actually servable, and where can they park. And it dares to give the third answer: "there's nothing," which saves a pointless detour.

Home: the usual Tuesday order at Feuillette, 4 min, 6 free spots — The main flow: you speak, Boubou rephrases, compares, then reserves. Information appears at the moment it's useful, around the mascot.

Listening: "two croissants and a baguette for 8am tomorrow," and what the agent understood — The main flow: you speak, Boubou rephrases, compares, then reserves. Information appears at the moment it's useful, around the mascot.

Decision 1

One main suggestion, not a list

1
The finding
While driving, a list read aloud isn't retained. And drivers themselves say they don't want ten choices.
2
What I chose
Out loud, Boubou names a single choice, along with the deciding argument: "Feuillette, five minutes away, free parking right in front. I have two others if that one doesn't suit you." The screen, on the other hand, can show three, sorted by ease of parking.
3
What I ruled out
Listing all three bakeries out loud, or sorting by distance alone.
4
The expected effect
A decision made in a single sentence, without taking your eyes off the road.

How I would measure it: Decision time and comprehension errors during testing.

Order summary and pickup choice, in store or at the car — Pickup, payment, confirmation, and the "on my way" flow, designed for drivers who are already headed somewhere.

Payment with Apple Pay, charged only once the bakery confirms — Pickup, payment, confirmation, and the "on my way" flow, designed for drivers who are already headed somewhere.

What I take from it

The ideal flow held up. But an agent is judged on its failures: one bad recommendation, and the driver won't trust it again.

Next step · 03 Anticipate ↓

03Anticipate

Five ways to get it wrong

Before writing the prompt, I listed what the agent could get wrong and what each error would cost the driver: a pointless detour, lost trust, or both.

Failure 1Stock listed, sold out on arrivalOther customers on the road took the last one. "3 left" is true and worthless: the driver needs a guarantee, not a status. Fix: reserve it, or say "not guaranteed."Source: failure analysis

Failure 2Bakery recommended, but closedWeekly closing day, public holiday, August. The worst failure: the closed door. Fix: an unverified opening time is never suggested.Source: failure analysis

Failure 3Butter croissant requested, plain croissant announcedThe attribute gets lost in speech. A hidden substitution contaminates every answer that follows. Fix: the requested attribute is always a blocking criterion.Source: failure analysis

Failure 4Multi-item order mismatchedThree plain croissants, four almond ones, six chouquettes: impossible to review while driving. Fix: line-by-line confirmation, validated once stopped.Source: failure analysis

Failure 5"Petit pain" declared nonexistentThe regional term isn't recognized, and the system denies reality by putting the blame on the driver. Fix: an alias dictionary, and never saying "that doesn't exist."Source: failure analysis

The baguette tradition is sold out: an alternative on the route, full basket — Product unavailable, bakery closed, request misunderstood: every exception has its own screen, and always a concrete way forward.

Feuillette will be closed tomorrow at 8am: another open bakery, on the route — Product unavailable, bakery closed, request misunderstood: every exception has its own screen, and always a concrete way forward.

Decision 1

Only promise what can be kept

1
The finding
Without the ability to reserve, saying "there are some" amounts to gambling on the driver's detour.
2
What I chose
The wording follows the level of guarantee. Reserved: "It's reserved until 2:20pm." Not guaranteed: "There were two left a minute ago. At six minutes away, it's a gamble." On screen, one word and one style: solid fill or simple outline.
3
What I ruled out
Displaying a stock quantity that was true at the time of the request and false on arrival.
4
The expected effect
A driver who knows exactly what risk they're taking.

How I would measure it: [Share of pickups where the product was actually there]

The real availability of each product on the detail screen

What I take from it

Each failure produced a rule. The next step was getting a language model to follow them.

Next step · 04 Build ↓

04Build

A system prompt as a specification

Boubou's behavior lives in a structured system prompt: role, rule hierarchy, tone, handling of uncertainty. It serves as the reference for the prototype and for any future iteration.

Rule 1Never invent field or business dataLocation, opening hours, price, stock, parking: everything comes from the data provided, or the agent says it doesn't know.Source: rule #1

Rule 2Never silently alter the requestThe request is always rephrased using the driver's own words: "Butter croissants: …"Source: rule #2

Rule 3Stay understandable behind the wheelOne idea per sentence, two options at most, travel times in minutes, never a full address.Source: rule #3

Decision 1

Silence counts as confirmation

1
The finding
When driving, saying nothing usually means the person is driving and can't answer right away, not that they're hesitating.
2
What I chose
When a concrete next step exists, four seconds of silence counts as a "yes," and it's always announced: "No answer, so I'm heading to Feuillette, five minutes away." After two silences in a row, Boubou stops and waits.
3
What I ruled out
Asking the question again, or waiting indefinitely for an answer the driver can't give.
4
The expected effect
A journey that moves forward without asking any effort from the driver.

How I would measure it: Silences handled and action errors during testing.

The agent completes the request with a closed question about the time

CarPlay, listening: the request and what Boubou understood — The CarPlay version: minimal text, large buttons, and voice remaining the primary interface.

CarPlay, voice decision: two bakeries ready for 8:00 a.m. on a map — The CarPlay version: minimal text, large buttons, and voice remaining the primary interface.

The prototype connects the mockups to the system prompt, a catalog of 123 products, real bakeries from OpenStreetMap, and an ElevenLabs synthetic voice. It listens continuously: you never tap a button to speak, which is the very point of the concept. Stock, however, is simulated, and the agent says so if asked.

What I take from it

A well-written prompt is a design system for conversation. Now it had to be put in the hands of real drivers.

Next step · 05 Test ↓

05Test

What the tests fixed

Eight planned tests, remote and in person, 15 minutes each, with the SUS questionnaire and the NASA-TLX. Each session started with a scripted journey, then veered off-script to observe how the agent adapts.

Feedback 1An introduction that's too longUsers couldn't interrupt the agent during the greeting. The text was shortened, and interruption was made possible from the very first screen.Source: user test

Feedback 2No barge-inWhen users started speaking again, the agent either kept talking or left a long gap. The voice must stop immediately, with instant visual feedback.Source: user test

Feedback 3A bakery choice that came too fastThe journey moved on before users had heard the option. We kept a single suggestion, but with more time and a visible countdown.Source: user test

Feedback 4Visual states that looked too similar"I'm thinking" and "I'm looking for a bakery" were being confused: two colors, two indicators.Source: user test

8planned tests, remote and in person

15 minper test

[score]on the SUS questionnaire (68 = threshold for a good score)

10fixes identified

[Test results to be added]

What I take from it

A voice doesn't forgive slowness: what goes unnoticed on a screen becomes an awkward silence when spoken.

Next step · 06 Takeaways ↓

06Takeaways

What Boubou taught me

Designing an agent means designing its failures as much as its ideal journey: trust is earned by how it says "I don't know."

What was tested

[SUS score and key feedback]

What I would do differently

Moving to a real-time voice conversation, where the model speaks directly and triggers actions, rather than reading a written response aloud.

What I keep

Writing a system prompt like a specification: prioritized rules, examples, and edge cases listed before writing the first line.

Next projectDoc2Wheels — at-home motorcycle repair

View project →