SmartD POS
01 PROJECT SUMMARY
A two-sided food-ordering product that began in IT parks and food courts, then evolved toward restaurant POS and reservation workflows.
The product started with a queue problem, but the real design challenge sat on both sides of the counter.
SmartD was conceived as a connected food-ordering ecosystem: employees could browse nearby food courts, place an order before lunch and collect it from an express counter, while merchants received and managed those orders through a dedicated POS experience.
As the proposition matured, the product direction narrowed from IT-park and food-court pre-ordering into a more focused restaurant and hotel POS environment, including table management, checkout and reservation-oriented flows.
02 PROBLEM
A faster lunch queue is only useful if the kitchen can absorb the speed.
The customer problem looked simple: reduce waiting during peak lunch periods. But digitising ordering created a second, operational problem for restaurants. Incoming mobile orders had to coexist with walk-ins, phone orders, table service, billing and settlement without overwhelming staff.
The design therefore had to connect two very different contexts: a lightweight consumer journey built for speed and confidence, and a high-frequency merchant interface built for clarity under pressure.
03 MY ROLE
I was designing a product pair, not two isolated screens.
As Principal Designer, I shaped the customer-facing mobile ordering experience and the merchant-side POS workflows, working across information architecture, interaction patterns, screen flows and visual design.
• Mapped the end-to-end relationship between customer ordering and merchant fulfilment.
• Designed mobile flows for venue discovery, menu browsing, ordering and order tracking.
• Designed tablet/POS workflows for walk-in, phone and online orders, billing, settlement and status handling.
• Helped adapt the product direction as the business shifted from IT-park pre-ordering toward restaurant and hotel operations.
04 OUTCOMES
The strongest outcome was coherence: the order stayed understandable as it crossed from customer intent into restaurant action.
CONNECTED | SIMPLIFIED | EXTENSIBLE |
05 INTENT
The design intent was not 'digital ordering'. It was controlled handoff.
The experience needed to make every transition legible: discover → order → accept → prepare → complete → pay. Customers needed reassurance that their order had moved forward. Staff needed to know what required attention now, what was already accepted and what was complete.
So the real question became: how do we make a single order understandable to two audiences who see it at different moments, on different devices, with different priorities?
06 CHALLENGES
The product had to stay simple while the business model itself was still moving.
• Two-sided complexity: customer convenience could not create merchant-side chaos.
• Peak-time use: restaurant staff needed low-friction actions with minimal interpretation.
• Mixed order channels: online, walk-in and phone orders had to coexist in the same operational space.
• Changing product direction: the original IT-park use case expanded and later narrowed into restaurant and hotel POS workflows.
• Device context: customer journeys were mobile-first, while staff experiences relied on larger tablet/POS interfaces.
07 APPROACH
Rather than optimise isolated screens, I followed the order as the core object moving through the system.
01 Map the service loop | Trace how an order is created, received, accepted, prepared, billed and completed across both customer and merchant touchpoints. |
02 Separate decision from operation | Keep consumer choices visual and lightweight, while making merchant actions explicit, status-led and fast. |
03 Design for operational states | Use clear labels, tabs, counts and status treatments so staff can scan the queue and act without opening every order. |
04 Adapt the model | Reuse the ordering logic for table service, billing and reservation-oriented scenarios as the product direction changed. |
08 KEY WORK / SOLUTIONS
The work came alive at the handoff points, where ambiguity costs time.
A. Customer ordering: make lunch feel pre-decided
Insight: office workers were not trying to explore endlessly; they wanted a quick route from nearby venue to food to collection.
Intervention: designed venue discovery, menu browsing, item selection and active-order views around fast scanning, familiar imagery and simple status communication.
Why it mattered: the experience reduced the mental distance between 'I want lunch' and 'my food is being handled'.
Consumer flow examples: food-court discovery, menu selection and active-order communication.
B. Merchant operations: turn incoming orders into a manageable queue
Insight: restaurant staff needed to distinguish channels and order states at a glance.
Intervention: used dedicated navigation for walk-in, phone and online orders, combined with strong status labels such as new, accepted, ready, complete and reject.
Why it mattered: the interface focused attention on the next operational action instead of burying staff in order detail.
Merchant tablet flows: channel selection, order entry and online-order status handling.
C. Table service and checkout: extend the same logic into the dining room
Insight: once the platform moved beyond food-court pre-ordering, staff needed a visual way to understand tables, active bills and payment readiness.
Intervention: designed a table-state view with in-progress and bill-raised states, a focused bill summary and a direct payment action.
Why it mattered: it translated the same status-driven model into a restaurant floor context without reinventing the interaction language.
Table and bill-state overview: a visual operational layer for service and payment.
D. POS menu entry: optimise for repeat, high-frequency actions
Insight: POS use is repetitive. Staff need stable locations, fast quantity edits and immediate visibility of the running order.
Intervention: paired a persistent order panel with category-led menu navigation, favourites, search, quantity controls and explicit checkout.
Why it mattered: the UI prioritised rhythm and muscle memory over decorative complexity.
Restaurant POS: persistent cart, category browsing, favourites and checkout in one working surface.
09 TRANSFORMATION
The product shifted from 'skip the lunch queue' into a broader operational tool for hospitality.
At the start, SmartD was framed around employees pre-ordering from food courts inside IT parks. The service promise was simple: order from your desk, collect at an express counter, get back to work.
As the product evolved, that narrow proposition gave way to a more focused hospitality toolset. The same core design ideas, clear states, channel awareness, order continuity and quick handoffs, were reused for table service, restaurant billing and POS workflows.
EARLY PRODUCT SHAPE | LATER PRODUCT SHAPE |
Customer discovery → order ahead → express collection | Tables → orders → kitchen/merchant states → billing → payment |
10 LEARNINGS
The project taught me that two-sided products are won or lost in the seam between interfaces.
Design the handoff, not just the screen. | The most important UX lived where a customer action became a merchant responsibility. |
Operational products need state clarity. | In restaurant contexts, clear status and next actions matter more than visual novelty. |
Product direction can change; interaction logic should survive it. | The shift from office food courts to restaurant POS reinforced the value of reusable service states and consistent order models. |
Customer-side mobile experience: discover venues, choose food and manage active orders.
Merchant-side tablet experience: receive, process and complete orders from one operational interface.
