[ Case Study ]
AFI: one restaurant platform, four people it has to work for
01[ Context ]
African Food Incorporated ran food ordering and restaurant table reservations on manual, fragmented processes. This project is an end-to-end UX design engagement: a four-component digital platform designed from first principles, covering every actor in the system from the end customer to the delivery agent, and carried through research, ideation, wireframes, high-fidelity design, and interactive Figma prototypes.
User Webpage
Customer-facing interface for browsing menus, placing orders, and booking tables
Restaurant Admin Web App
Staff operations panel for managing simultaneous orders and reservation conflicts in real time
Manager Admin System
Performance analytics dashboard with real-time sales insights and data visualisation
Delivery Personnel App
Mobile app with GPS-enabled route optimisation and live order tracking
02[ Business Problem ]
The manual process failed each actor differently: customers dropped off, staff drowned in conflicts, managers flew blind, and delivery agents improvised routes. Any solution that fixed one role while ignoring the others would simply move the failure around the system.
- CustomersOverwhelmed by excessive options and frustrated by slow, broken checkout flows
- Restaurant StaffManaging simultaneous orders and reservation conflicts with no unified system
- ManagersNo real-time visibility into sales performance or operational bottlenecks
- Delivery PersonnelInefficient route planning with no live order status or GPS integration
03[ Constraints ]
- Four actors, one coherent systemCustomer, staff, manager, and delivery agent needs pull in different directions, but the four surfaces share one operational reality: an order or reservation flows through all of them. The designs had to stay consistent across that flow.
- Real-time coordinationSimultaneous orders and reservation conflicts are the core operational problem, so every surface had to be designed around live state: order status, table availability, and delivery location.
- Accessibility as a baselineWCAG compliance was a design requirement across all four components, not a retrofit, which constrained colour, contrast, and interaction choices from the first wireframe.
04[ Stakeholder Landscape ]
The stakeholder map covered the four system actors, customers, restaurant staff, managers, and delivery personnel, alongside the restaurateur as business owner. Each actor received their own empathy map, journey map, and prioritisation matrix, so no single voice, and in food delivery it is usually the customer's, drowned out the operational roles that make the service actually run.
05[ Research ]
Research ran actor by actor: empathy mapping to surface what each role thinks, feels, and struggles with; journey maps for the five key journeys, including reservation and ordering from the customer side and the parallel admin, restaurateur, and delivery journeys; and a use case diagram tying the whole system together.
Empathy Mapping
Key Stakeholders Map
Use Case Diagram
Customer Journey: Reservation
Customer Journey: Order
AFI Admin Journey Map
Restaurateur Journey Map
Delivery Agent Journey Map
06[ Strategy ]
Design the system, not a screen. The strategy was to treat the four components as one platform with four windows onto the same live state: an order placed on the customer surface appears as work on the staff surface, as data on the manager dashboard, and as a route on the delivery app. First-principles design per actor, unified by the shared order and reservation lifecycle underneath.
07[ Options Considered ]
Ideation generated options from two directions, pain points and opportunities, then grouped them by actor. Every candidate idea was placed on an impact-complexity matrix for its actor, and the build scope was drawn from the high-impact quadrants first. The matrices below are the actual decision record: what made the cut, what was deferred, and why.
Ideas from Pain Points
Ideas Grouped by Actor
Ideas from Opportunities
Restauranteur Impact-Complexity Matrix
User Impact-Complexity Matrix
AFI Admin Impact-Complexity
Delivery Agent Impact-Complexity
08[ Trade-offs ]
- Breadth across actors over depth on oneDesigning four surfaces in one engagement meant each surface got less polish time than a single-app project would allow. The system-level coherence was worth it: the operational surfaces are where the customer experience is actually manufactured.
- Impact-complexity discipline over feature ambitionThe matrices killed attractive ideas that sat in the high-complexity, low-impact quadrant. The features that shipped into the prototypes, payments, notifications, GPS routing, live dashboards, all earned their place on impact.
- Accessible defaults over visual maximalismHolding WCAG compliance across every component constrained the visual language, and produced designs that work for more users in more conditions, which for a food platform is the commercially correct choice.
09[ Design Process ]
- 01. Empathy mappingDocumented what each of the four actors experiences in the manual process, grounding the pain points in observed frustration rather than assumption.
- 02. Journey mappingMapped the five key journeys end to end, exposing the handoff points between actors where the manual process breaks down.
- 03. IdeationGenerated candidate solutions from pain points and from opportunities, then grouped ideas by the actor they serve.
- 04. PrioritisationPlaced every idea on a per-actor impact-complexity matrix and scoped the platform from the high-impact quadrants.
- 05. WireframingTranslated the prioritised scope into low-fidelity wireframes across the four components.
- 06. High-fidelity design and prototypingProduced high-fidelity screens in Figma and wired them into three interactive prototypes covering ordering and reservation, the admin panel, and the delivery agent app.
10[ Proposed Architecture ]
The designs were specified against a buildable stack: React and Angular frontends over a Node.js and Express backend, MongoDB for data, AWS hosting, and RESTful integrations for payment gateways and GPS. The feature set the prototypes carry:
Frontend
React.js, Angular
Backend
Node.js, Express
Database
MongoDB
Infrastructure
AWS hosting
Integration
RESTful APIs, payment gateways, GPS
Design
Figma (wireframes + high-fidelity)
11[ Outcomes ]
The engagement delivered a complete, WCAG-compliant design system for the four-component platform: research artefacts, wireframes, high-fidelity screens, and three interactive Figma prototypes that walk the core flows for ordering and reservation, restaurant administration, and delivery.
Wireframe: Screen 1
Wireframe: Screen 2
Wireframe: Frame 1
Wireframe: Frame 2
Wireframe: Frame 6
High Fidelity: Frame 3
High Fidelity: Frame 5
High Fidelity: Frame 5b
High Fidelity: Frame 8
12[ Metrics ]
As a design engagement, the measurable output is the scope covered and the fidelity reached rather than production KPIs.
13[ Lessons Learned ]
- Multi-actor systems fail at the handoffs. The journey maps showed the manual process breaking where one role passes work to another, which is exactly where the platform design concentrated its real-time state.
- Per-actor prioritisation keeps the loudest voice honest. Running a separate impact-complexity matrix for each role stopped customer-facing polish from crowding out the operational tooling the service depends on.
- Accessibility constraints sharpen design rather than dulling it. Designing to WCAG from the first wireframe produced clearer hierarchies and more legible flows for every user, not just those who needed it.