My first AI ordering prototype took roughly an hour to build. I could talk to it, browse mocked menu data, and put an order together. It felt like I had made an enormous amount of progress.
Then I started using it like a customer.
- Build a reference
- Try real interactions
- Refine the experience
- Sharpen requirements
Why I built a reference experience
We were evaluating vendors for a conversational ordering proof of concept. At that stage, their work would use mocked data because live integration was outside the immediate constraints.
That opened up a useful experiment. I could build a small benchmark myself, understand the interaction from the inside, and use it to ask better questions about the vendor work.
I used AI tools to move from a short requirements discussion to a working prototype. It did not include a live payment integration, and it was not a production ordering service.
The awkward part was the conversation
A user could say, “Actually, change that to iced,” and the bot would start the order again. It asked too many follow-up questions. Suggestions sometimes felt disconnected from what the user wanted.
Those interactions made the gap visible. The bot could produce a response, but the experience needed to preserve context, understand a correction, and avoid making the user do unnecessary work.
Getting that part into better shape took roughly another two weeks. Conversation flow, tone, prompts, and UI decisions all affected whether the experience felt useful.
The prototype changed my questions
Before building, I could describe a natural ordering experience in broad terms. Afterwards, I could point to specific situations: changing an item, deciding when to ask another question, and knowing when a suggestion was helpful.
That made the prototype valuable as a requirements tool. It gave me a reference to compare against and made gaps in my own thinking easier to spot.
It also made me more cautious about comparing development timelines. A quick mocked-data demo and a reliable production service carry different responsibilities. My build exposed experience problems; it did not resolve every integration or reliability question.
What I would repeat
I would build a bounded reference experience early when the uncertainty sits in how an interaction should feel. I would make the limits explicit and test the awkward moments as deliberately as the happy path.
- Try corrections and changes of mind.
- Watch for unnecessary questions and lost context.
- Use what you learn to improve the requirements.
- Keep production readiness separate from prototype quality.
The most useful result was a sharper understanding of the problem. That stayed useful well beyond the first working demo.
Adapted from my public reflection on an early ordering prototype. The subsequent POC completion and handover are covered in the related case study.
Have you worked through something similar?
Let’s compare notes on LinkedIn (opens in a new tab)