Web & QR ordering
Menu access and ordering where supported.
Case Study 01 · Restaurant commerce & operations
BUKAH
Designing the operating platform behind modern restaurant businesses.
A multi-tenant platform that helps restaurant brands manage identity, menus, orders, branches, teams, payments and communication, while connecting waiter and kitchen workflows across instant and pre-order service models.
The challenge
Support different restaurant service models while keeping orders, preparation and branch oversight connected.
My contribution
As the sole Product Designer, I designed the admin, waiter and kitchen experiences across web, tablet and mobile.
Key decision
Keep order states consistent across roles while adapting actions to instant and pre-order service.
Outcome
Designs completed and handed off to engineering. Five moderated usability sessions led to changes in menu creation, sales-item scanning and branch reporting.
(01)Overview
One operation. Several people. Two ways of serving food.
The goal was not to digitize an order form. It was to create a flexible SaaS product that restaurants could adapt to their own business.
Restaurant orders do not move through one interface. A waiter may create an order, a kitchen team prepares it, another staff member completes the handover, and a manager needs visibility afterward.
- 01Web administration and tenant configuration
- 02Role-based waiter and kitchen experiences
- 03Instant and pre-order service models
- 04Single and multi-branch operations
(02)The system
Different views of the same operational state.
An update made by one role must be understood by everyone affected by it. The product therefore shares orders, status language, payments and notifications while giving each role a focused interface.
Order display
Progress and ready numbers for restaurants that use a customer-facing screen.
Orders, status, payments & notifications
Every role and screen sees the same live order, from the moment it is placed until it is served.
Waiter & kitchen
Role-specific tablet and mobile views for service, preparation and handoff. The tablet interface also runs on in-store terminals.
Administration
Menus, branches, teams, finance, brand, settings and oversight.
(03)Discovery
Mapping the operation before designing the screens.
I began with stakeholder meetings, then interviewed restaurant owners and waiters to understand current workflows, recurring pain points, branch differences and service realities.
I reviewed Chowdeck, Glovo, The Place, Mega Chicken, Uber Eats, DineSurf and Kappture, then developed journeys, sketches and wireframes through recurring stakeholder reviews.
4
Mapped service journeys across instant and pre-order restaurants, dine-in and pickup.
4
Primary perspectives: restaurant owner, customer, waiter and kitchen staff.
7
Direct, indirect and reference products reviewed.
5
Moderated usability-testing sessions completed.
(04)Role personas
Two perspectives that shaped the product priorities.
Restaurant owner / managerInterview-based
Clear oversight of every branch, from anywhere.
Core priority: Understand what is happening across branches without being physically present at each location.
Needs
Branch-level performance, staff visibility, configurable menus, clear financial records and control over the restaurant’s identity.
Key friction
Aggregate information hides branch differences, while rigid tools do not reflect how each location actually operates.
Waiter / service staffInterview-based
Speed and certainty during service.
Core priority: Find the right item quickly and know exactly what happens after an order is sent.
Needs
Fast item selection, clear table and customer context, visible order progress, reliable payments and direct kitchen handoffs.
Key friction
Dense sales interfaces, slow item scanning and unclear preparation states create delays when service is busy.
Information architecture
Mapping each role’s app before the screens.
After the interviews, I mapped the waiter and kitchen apps for both service models in FigJam. Every app shares the same entry and account pages. What changes is the work each screen has to support.
Instant restaurantsFood is already prepared
Pre-order restaurantsFood is prepared after ordering
- SalesPlace order, payment, receipt
- OrderView, accept, cancel, reject, complete
- HistoryOrder history
- InventorySwitch products on and off
- RequestRequest and monitor orders from the kitchen
- SalesPlace order, payment, receipt
- OrderView, accept, monitor and receive orders
- HistoryOrder history
- OrderView, accept, cancel, reject, complete
- HistoryOrder history
- OrderView, accept, cancel, reject, complete
- HistoryOrder history
- InventorySwitch products on and off
Shared by every appCompany sign-in → Staff login → HomeNotifications · Settings · Profile · Logout
What the map revealedWho controls item availability depends on the service model. In instant restaurants the waiter switches items on and off, because the food is already made. In pre-order restaurants the kitchen does, because it cooks to order.
Sketches
Working it out on paper first.
Before moving to Figma, I sketched the waiter app and every admin page by hand. Paper made it quick to try layouts, walk the stakeholder through them and redraw.
Waiter app
Admin dashboard
(05)Product architecture
One platform that can become a different restaurant’s system.
Platform level
BUKAH subscription plans, billing and shared product rules.
Restaurant level
Operating mode, identity, hours, tax, payments, policies and communications.
Branch & role level
Locations, tables, supervisors, staff permissions, terminals and daily views.
Store identityBusiness details, contacts, address, social links and order-ID format.
Brand presentationLogos, favicon and restaurant interface colours.
Operating setupHours, tax, tables, capacity and service charges.
Branch structureLocations, supervisors, types, tables and activation.
Staff accessEmployees, roles, permissions and branch assignment.
PaymentsBanks, gateways, POS providers and branch terminals.
Commercial accountPlans, billing cycle, payment card and history.
CommunicationsEditable predefined templates for customer and staff events.
The control layer, in the product
Brand styling
Each restaurant uploads its logos and sets its own primary and secondary colours, so the product carries its brand.
Business hours
Opening and closing times for each day, with a switch for the days a restaurant is closed.
Branch setup
Add locations, assign a supervisor and mark each branch active or inactive.
Payment terminals
Register terminals and link each one to a POS device and the branch it belongs to.
Email templates
Choose which emails customers receive, then preview or replace each template.
(06)Design system
A shared visual language across web, tablet and mobile.
I formalized recurring interface patterns into foundations and reusable components so the product could stay consistent as roles, branches and workflows expanded.
The two brand colours were specified in the product brief. Supporting neutrals, state colours, spacing and component rules were standardised from recurring interface patterns and accessibility needs.
Forest · primary#243837
Lime · accent#A8DF46
Text#1C274C
Secondary text#7984A9
Border#E2E6E9
Surface#F5F5F6
Filter fill#CDE0DF
White#FFFFFF
Urbanist
Page title · 32 RegularOverview
Metric · 24 Medium₦125.5m
Card title · 14 MediumBest Selling Food
Body · 12 RegularView performance metrics and key insights at a glance
Action · 12 SemiBoldSee more
Order status.
Order placed#0077B6
In progress#BC8A09
Completed#0D875A
Cancelled#AC0F05
Chip fillStatus colour at 10% opacity
RadiusCards & buttons 6 · chips 100
Admin components
Metric cards
Order table
Order status
Total Sales₦125.5m +11.02% vs last month
Total Orders2,500 +11.02% vs last month
Customer Satisfaction89% 1.2% vs last month
Order IDBranchStaffStatus
#789012Branch AAdekunle JohnsonOrder Placed
#890123Branch EOlamide AdebayoIn Progress
#234567Branch DChinonso EzeCompleted
Order PlacedIn ProgressCompletedCancelled
AI suggestion
AI Suggestions
Navigation
Revenue dipped by 12% this week. Do you want a quick breakdown?
View ReportDashboardMenuOrdersCustomers
Filters & actions
All BranchesThis MonthCreate Order
Waiter components
Menu categories
Service type
Tab bar
AllMain DishesRiceComboSwallow
Menu item · default, selected, unavailable
Jollof Rice₦1,500
Spaghetti Stir Fry₦2,5001
Pounded YamNot Available
BUKAH Special₦5002
Dine InPickup
Order item
BUKAH SPECIALGrilled chicken x1
₦5,000₦1,500
HomeSalesOrdersRequestsInventoryTransactions
Incoming order
Transaction row
Employee PIN
Order #123457:30 pm
johndoe@gmail.com2 itemsDine inTable 5Total₦9,400
Details✓ Accept
Order #12345 Refund23rd August, 2025
Refunded₦5,000
Order #1234523rd August, 2025
Successful₦5,000
Order #1234423rd August, 2025
Pending₦5,000
1234567890⌫
Sign In01Role-aware
Components adapt in density and priority without changing their underlying meaning.
02Status-consistent
Order and payment states retain the same language and colour meaning across surfaces.
03Responsive
Layouts reduce and reflow for tablet and mobile rather than simply shrinking desktop screens.
04Accessible
Colour is supported by labels, icons and contrast so meaning never depends on hue alone.
(07)Core workflows
Shared product language. Different fulfilment logic.
Both restaurant models use orders, customers, payments and staff, but preparation and handover work differently. The interfaces share patterns while changing the actions that matter.
Pre-order service
Acceptance, preparation time, progress and coordinated handover are explicit.
- Receive or create the order
- Send the order to the kitchen
- Accept and communicate preparation time
- Monitor progress and readiness
- Serve, hand over and complete
Instant service
Speed, availability, payment and packing or serving take priority.
- Create or receive the order
- Confirm items, quantity and service context
- Complete the appropriate payment
- Pack, serve or place for collection
- Record completion and transactions
(08)Role-based design
Focused experiences for the work each person owns.
Instead of exposing the entire product to every employee, navigation and information density reflect responsibility. Shared status patterns preserve continuity between roles.
Owners & managers
Oversight across menus, orders, branches, staff, finance, settings and restaurant performance.
Waiters
Fast sales, table context, order progress, payments, receipts, refunds and kitchen requests.
Kitchen teams
Focused incoming work, acceptance, preparation timing, completion and waiter notification.
(09)Testing & iteration
The strongest changes came from watching people use it.
5 moderated sessions
Task-based evaluation with the stakeholder and representative users across menu creation, service speed and branch oversight.
Menu creation
FindingSingle items and combo meals used the same setup, while owners needed different menus by branch.
ChangeI separated item types, added branch assignment, and introduced required or optional combo components with minimum and maximum selections.
Sales speed
FindingLarge image-led cards reduced the number of items visible at once, and alphabetical ordering slowed frequent selections.
ChangeI removed nonessential imagery, compacted the cards and prioritised commonly sold items.
Branch visibility
FindingAggregated reporting hid which locations and staff were performing well or poorly.
ChangeI added a Branches module and branch filters across Dashboard, Orders and Finance.
(10)AI, with boundaries
Assistance inside the workflow, not AI as the product.
The assistant summarises reports, suggests next steps and flags what needs attention. Every task can still be done with the normal controls, so no one has to rely on AI to get work done.
Insights and timely escalation
- Sales summaries and report prompts
- Suggestions drawn from the restaurant’s own sales, such as which dishes to promote
- Order and transaction notifications
- Preparation-delay alerts to managers or supervisors
Where AI could act on its own, once tested
- Automatic restocking decisions
- Broader operational automation only after trust, error recovery and control are tested
(11)Outcome
One restaurant platform, designed and ready to build.
01A defined architecture connecting administration, waiter and kitchen experiences.
02A tenant-level configuration model for restaurant identity, operations and communication.
03Reusable responsive patterns and detailed workflows prepared for engineering handoff.
