Designing a multi-vendor ordering flow for a restaurant platform
STARTER is a foodtech platform for restaurants and restaurant groups. It combines customer-facing apps and websites, a loyalty programme, order management, and administrative tools.
In 2024, a large food hall in St Petersburg approached us to launch its own app. Customers needed to order food from several vendors at once. For STARTER, the project was an opportunity to adapt an existing restaurant platform to a new business model.
As Lead Product Designer, I was responsible for the core multi-vendor ordering flow: the shared basket, order page, and collection experience. My task was to keep the order simple for customers even though the platform split it into several sub-orders with different statuses and collection options.
One order, several operational flows
In a typical restaurant app, a customer chooses items from one menu and receives one order. A food hall is different: items belong to different vendors, each vendor has its own menu and point-of-sale integration, and one customer order becomes several sub-orders inside the platform.
For customers, the experience still needed to feel unified: choose items from different menus, pay once, and understand when and where to collect each part of the order.
The operational model worked differently. Each vendor needed to receive only its own items, while the food hall operator needed to see the full order and track each sub-order. For delivery and collection, food hall staff had to assemble the sub-orders before handover.
Product managers and designers researched the client’s processes before the design stage and mapped scenarios for customers, vendor staff, and food hall operators. The Product Director defined the MVP scope. I organised the design work within that scope and was responsible for keeping the solution coherent.
Three designers worked on the project in parallel. One designed the home page and catalogue; another worked on administrative tools; I focused on the basket, order page, and collection flows. I also art-directed the remaining parts of the product.
One basket across several vendors
The basket already existed in the product. I needed to define how it would work when items came from different vendors and became separate sub-orders after payment.
I kept a shared basket and a single payment so that the platform’s internal complexity would not become the customer’s problem. In the basket, I grouped items under compact vendor headings. We considered adding vendor logos next to the headings, but removed them: food photography already separated the groups, while additional marks created visual noise.
The vendor page kept STARTER’s familiar menu structure. We added the vendor name, logo, and a short description to preserve context. For eat-in orders, customers could also open the food hall map after choosing their items.
Collection depended on context
The order page was the most complex part of the experience. One interface had to explain several scenarios:
- one or several vendors;
- delivery or collection;
- collecting the full order or separate parts;
- eat-in orders where customers collected food themselves.
For delivery and collection, food hall staff assembled the sub-orders, so the customer experience stayed close to a standard restaurant order. Eat-in worked differently. Each vendor prepared its own part, and customers needed to understand what was ready, where to go, and what was still being prepared.
When the team began to fall behind schedule, I joined another designer to explore order-page options, discuss constraints with product managers, and consolidate the work into one flow.
For each sub-order, we showed:
- food photos to help customers recognise their order;
- the vendor name and logo to show where to collect it;
- a status to explain whether it was ready;
- directions to the vendor;
- a collection instruction that brought the next action to the top.
The resulting interface treated the purchase as one order while making each vendor’s status visible. Customers saw a clear plan: what was ready, what to wait for, and where to go next.
Six notifications instead of ten
The previous notification model sent an update for every status change in every order. For an order from three vendors, that meant ten notifications. The phone reflected the platform’s internal mechanics instead of helping the customer.
I redesigned the notification rules and copy around meaningful customer moments. The same scenario required six messages rather than ten. The messages focused on moments when customers needed to pay attention or take action, not every technical transition.
One model across customer and operational interfaces
In parallel, two designers adapted the admin panel and order-management system. Vendors needed to see only their own items, while food hall operators needed the complete order and the status of each sub-order.
I art-directed the administrative work, checked the underlying logic, and edited interface copy. This kept employee actions and order statuses aligned with what customers saw.
Outcome
Within six weeks, the team released a platform solution for food halls and restaurant groups. It supported one basket across several menus and split the order between vendors, their point-of-sale systems, and operational tools.
After release, the sales team had a finished product to present to prospective clients.
What I learned
The challenge was not a single screen. It was coordinating several systems and roles: an order had to remain unified for the customer, split for vendors, and come back together for collection or delivery.
The key design decision was to preserve a simple customer model over a complex operational structure: one basket, one payment, and a clear collection flow, even when the platform worked with several menus, sub-orders, and point-of-sale integrations.