Back to projects
Case Study — Restaurant Operations

Eli & Lulu

An operational platform that keeps a restaurant running smoothly, from the dining table to the kitchen: customer ordering, kitchen operations, payments and administration in one connected workflow.

TL;DR

Eli & Lulu is a restaurant management platform connecting every stage of restaurant operations into a single workflow. As sole designer, over an engagement of under two months, I designed the product experience across customer ordering, kitchen operations, payments and administration — grounded in conversations with the restaurant's owner, management and staff. The work was less about individual screens and more about operational clarity: six different roles working through one connected system.

01 The order is easy. Everything after it is hard.

A single customer request passes through several people: the waiter who takes it, the kitchen that prepares it, the cashier who settles it, and the manager who needs to know it all happened. When those handoffs run on verbal communication or disconnected systems, the failures are predictable: orders get forgotten, meals get delayed, payments become hard to reconcile, and managers lose visibility into the day.

The brief was to design a product that connects those operational moments into one continuous workflow.

02 Learning the workflow from the people running it

The workflow understanding came directly from the restaurant: conversations with the owner and management about how the operation runs, and time with the staff who actually take, prepare and settle orders. Mapping the operational lifecycle of a single meal became the first design artifact, and the foundation for the product's information architecture.

03 One shared order lifecycle, seen from six angles

The defining decision was to design the entire platform around a single order lifecycle that every role shares, rather than letting each department track its work independently.

Create order

A waiter or the customer starts the order.

Process

The kitchen receives it and works through preparation.

Ready

The kitchen marks it complete; the waiter is signalled.

Serve

The meal reaches the table.

Confirm payment

The cashier settles it — POS terminal or bank transfer.

Review

The order closes into the restaurant's operational record.

Each role sees the same state from its own perspective, so nothing depends on someone remembering to tell someone else. The status of any meal is a fact in the system rather than a conversation in a corridor.

04 Different jobs, one source of truth

Unlike a consumer product with one primary user, the platform needed interfaces for six kinds of people working toward the same outcome.

Customer

Browse meals, place orders and complete payment.

Waiter

Create and manage orders while tracking preparation status.

Kitchen

Receive incoming orders, manage preparation, update completion.

Cashier

Process payments and reconcile completed orders.

Restaurant manager

Monitor performance, oversee staff activity and review operational data.

Super administrator

Manage restaurants, staff, menus, permissions and system-wide settings.

05 Four operational areas, one menu system

The platform is organised around four core areas: ordering (the complete customer path from menu to payment), kitchen operations (incoming orders, preparation progress, completed meals), payments (POS terminals and direct bank transfer), and administration (performance, staff management and operational reporting, through to a super-admin portal with audit logs and system-wide settings).

Menu management got particular attention: categories, sections, individual meals, pricing, preparation time, availability, images and descriptions — structured so administrators can update the menu efficiently without disturbing the customer experience.

Note

Honesty note. I don't have verified launch or usage facts for this platform, so this case study claims the design work only — no adoption numbers, no operational outcomes.

06 What this project demonstrates

This project is operational software rather than a customer-facing product, and the hardest work was structural: how information moves between people with different responsibilities while the overall system stays simple to understand. The strongest design decisions were in the product architecture, the shared lifecycle and the information organisation, not in any individual screen.