AI is very good at understanding what people mean. It’s less good at deciding how software should behave. In ordering systems, that distinction matters. This piece explores a way of using AI to interpret intent, while keeping the user-interface UI deterministic, predictable, and firmly under control.
That matters because ordering flows in pub and fast-food apps are often far more complicated than they need to be.
There’s a lot of talk about using AI to “reinvent” interfaces, but most real-world problems are more basic than that. In a pub, people are not looking for a clever user interface. They’re trying to get an order in, without thinking too hard.
You know the drill. You open the app, there’s five of you squeezed around table 197, phone in one hand, mumbled orders come from every direction. And instead of helping, the app immediately asks you to make a load of decisions you shouldn’t need to make.
Focus. Ok Guinness. Is it under pints, stouts, or offers category? Oh what are the offers? No wait. Focus. Crisps. Oh there's a £5.99 meal deal. No, no, not a meal. Snacks? Oh wait. There are the nuts...
You end up bouncing between multi-tabs, dropdowns and search boxes, slowly reverse-engineering the marketers' thought process behind the internal menu structure - when all you really want to do is have a drink and eat a snack.
As both a customer and a software engineer, there’s always a tipping point where it’s worth asking the obvious question: should a good user experience make you think at all?
What people actually want
Imagine a touch-to-order app where AI is there, not showing off, just ready to understand. You don’t begin by choosing categories or hunting through menus. You just tell the app what you want - however what’s easiest in the moment.
What people actually want is to be able to say something like:
A Guinness and a bag of ready salted crisps for table 19 please
A human understands that instantly. The AI’s job is simply to translate that intent into something the system can work with, without making up its own rules along the way.
Where AI fits in
The AI is not designing screens or inventing flows. It’s doing a much narrower, more useful job.
- Pulls quantities out of natural language
- Recognises known products from a menu
- Keeps related phrases together
- Hands off a clean intent to the UI layer
And, and, well that’s it. Once that intent is understood, the AI steps back. From this point on, we are no longer dealing with language, we’re dealing with structure.
The ordering flow
Behind the scenes, the UI still needs to be predictable. That’s where a structured response comes in.
By this point, the AI has already done its bit. The sentence has been broken down into recognised items, quantities, and attributes. Not as prose, but as tokens the system understands.
From there, the job is no longer interpretation. It’s assembly.
Those tokenised pieces are mapped onto known UI components, combined in a consistent way, and rendered into a flow that always looks and behaves the same, regardless of how the order was phrased.
Even for something as simple as an order summary and confirmation, we need output that hangs off a single, known root.
{
"root": "customer order",
"key": "key",
"nodes": {
"order-card": {
"key": "order-card",
"type": "Card",
"props": {
"title": "Your order"
},
"children": ["order-stack"]
},
"order-stack": {
"key": "order-stack",
"type": "Stack",
"props": {
"direction": "vertical"
},
"children": ["order-summary", "table-prompt", "confirm"]
},
"order-summary": {
"key": "order-summary",
"type": "Text",
"props": {
"content": "orderItems",
"variant": "body"
}
},
"table-prompt": {
"key": "table-prompt",
"type": "Input",
"props": {
"label": "Table number",
"name": "table",
"type": "number",
"placeholder": "e.g. 19"
}
},
"confirm": {
"key": "confirm",
"type": "Button",
"props": {
"label": "Place order",
"variant": "primary",
"actionText": "Sending order..."
}
}
}
}
The AI didn’t invent this structure. It translates user intent into a user experience by assembling components from a predefined catalog.
What is the catalog?
The catalog is a constrained set of approved UI components that the AI is allowed to use. Examples include:
- Inputs
- Order lines
- Cards
- Summaries
- Confirmation cards
Each component has a fixed shape, a defined purpose, and known constraints.
We have put together a simple proof-of-concept (PoC) prototype ↗ to look at.
How the AI uses it
The AI does not design new UI patterns or generate novel layouts. Instead, it selects components from the catalog and composes them based on:
- What the user asked for
- What information is required to complete the task
- The valid flows supported by the system
The result is assembly, not invention.
Why this matters
This constraint keeps the system deterministic and predictable.
- The AI cannot render unsupported screens
- The AI cannot introduce unapproved interactions
- Anything outside the catalog simply does not exist at render time
This may seem limiting, but it is intentional. The system stays grounded, auditable, and safe.
In simple terms
- These are the screens we allow
- These are the interactions we support
- Anything else is ignored
That set of constraints is the catalog.
Why this works in practice
AI is very good at understanding intent. It is not something you want making structural decisions.
By letting AI interpret what the user means, and letting the catalog control what the UI can be, you get the best of both worlds.
The interface feels flexible. The system stays predictable.
Why this scales without becoming a headache
This model scales across menus, venues, and brands without multiplying UI logic.
AI helps adapt to how people speak. The catalog makes sure the output stays in the same shape.
That means you can roll this out widely without worrying that every new venue introduces a new flavour of UI.
The real takeaway
Used this way, AI is not the author of the UI. It translates intent into a constrained format, and the application decides what happens next.
Now where's those Pork Scratchings.
