An end-to-end product design case study on menu discovery, ordering, and table service in Indonesian hospitality.
Restaurant guests make several decisions before a meal reaches their table. They need to understand the menu, choose dishes, check the cost, decide how to pay, and know what happens after the order is placed. Each decision can be straightforward on its own. Friction appears when the sequence is unclear or when guests must make those decisions while waiting for someone else.
I explored how a tablet ordering experience for Plataran could make that sequence easier to navigate while reflecting the character of Indonesian dining. I worked individually across the full design process, from problem framing and persona exploration to information architecture, wireframes, and high-fidelity screens.
This case study follows the journey from problem framing and research themes to persona exploration, journey mapping, information architecture, wireframes, and high-fidelity screens. It closes with the product considerations and validation needed for a dependable dining experience.
The visual direction brings Plataran’s dining identity into the ordering interface.
🧭 Project Context and Problem Framing
The project followed a progression from understanding the ordering problem to defining a proposed interaction model. Research themes informed the goals; the persona made those goals concrete; information architecture and sketches organized the journey; visual design translated it into a tablet experience.
Each stage connects the ordering problem to a design decision. The research themes set priorities; the flow, sketches, and screens show how those priorities shaped the guest journey.
Overview and Project Context
Plataran provided a useful setting for exploring self-ordering because the experience involves more than selecting products from a catalog. Its Indonesian dining identity, food presentation, and restaurant atmosphere shape what guests expect from the service. A transaction interface therefore needed to feel connected to the meal and the venue.
The brief focused on busy service periods, especially lunch and dinner, when ordering, payment, and seating questions could compete for attention. Its proposed response was a touch-screen or tablet application through which guests could browse the menu, assemble an order, choose a service path, and pay.
My scope covered research analysis, persona development, information architecture, user flow, paper wireframes, visual design, and prototype exploration. The design deliverable covered the guest-facing journey from welcome through order confirmation.
The product challenge was to give guests enough control to complete routine ordering decisions without making the restaurant experience feel impersonal. That meant considering the tone of the welcome screen, how unfamiliar dishes were introduced, how order details remained visible, and how the interface connected an order to its intended service location.
Problem Statement and the Ordering Friction
The problem framing centered on four issues: queues at the cashier, uncertainty around seating, hurried ordering decisions, and limited payment options. I treated these as connected parts of one journey rather than unrelated requests for new screens.
Waiting at the point of order
A cashier-led process can concentrate several activities at one station. A guest may still be reading the menu when their turn arrives, then asking questions, confirming the order, and paying before the next guest can proceed. The design question was whether some of that preparation could happen through the interface, with assistance available when needed.
The goal was to reduce dependence on a single transactional handoff. It was not enough to create an attractive menu if the guest still needed to repeat the entire order at the counter.
Uncertainty about the dining location
The brief also described confusion about available seating and where the guest should receive the meal. These are related questions, but they require different answers. Seating concerns whether there is an appropriate place to dine. Delivery identification concerns where a particular order should go.
The design explored a table-service code as part of the ordering journey. It gave the interface a way to associate an order with a physical marker, while leaving a larger operational question about how seats and markers would be managed. I return to that distinction in the product considerations section.
Choosing while feeling rushed
A menu needs to support comparison, especially when dish names or ingredients are unfamiliar. If guests only begin that comparison when they reach a cashier, the pressure to finish may compete with the information they need to choose.
The design response was to make categories, food imagery, descriptions, and prices available before checkout. Guests could explore the menu and review their choices in the same interface, rather than compressing discovery and commitment into one interaction.
Matching payment preferences
The brief included debit and credit cards, QRIS, and cash among the payment preferences to consider. A useful self-ordering concept needed to explain how payment fits into the journey and how guests who prefer a counter interaction could still complete an order.
The information architecture retained both in-app and counter payment paths. The high-fidelity payment screen illustrated card and QRIS selection. That distinction between the wider flow and the screens actually shown is important when assessing the completeness of the concept.
🔎 Research and Experience Definition
Research and Analysis
The research input centered on four themes: demand during busy service periods, difficulty choosing from a broad menu, limited awareness of table availability, and preference for multiple payment methods. Those themes formed the input to the design exercise.
These themes directed the work toward menu comprehension, order visibility, table-service coordination, and payment choice. They also shaped the questions I would later test with guests and staff.
Turning themes into design questions
The useful step was to translate each theme into a question that the design could address. For peak demand, the question was where the guest could prepare an order without relying on the cashier for every choice. For menu complexity, it was how the interface could support discovery before asking for commitment.
For seating uncertainty, the question was how the order could carry enough service information to reach the guest. For payment preference, it was how the experience could offer recognizable choices without forcing every guest into the same method.
These questions connect the problem to a proposed mechanism. For example, a visible order summary is useful because it lets the guest check quantities and cost before payment. A table-code field is useful because it can capture a delivery association. Neither feature, by itself, demonstrates a shorter queue or a correctly delivered meal.
Synthesis into a coherent product direction
The themes led toward a guided sequence: introduce the experience, help the guest browse, let them inspect and edit the order, establish the service context, and make the next step after payment clear.
The interaction should ask for information when it becomes relevant. Menu discovery benefits from a lightweight starting point. Order review needs detail. Payment needs a clear commitment and response. Trying to present all of that at once would make the welcome screen carry decisions that belong later in the journey.
The resulting product direction was a tablet ordering concept with visible navigation and a persistent connection to the cart. That direction gave the later wireframes a concrete job: make the sequence understandable rather than simply distribute the same content across more pages.
Design Goals
I used the design goals to define what the interface needed to support. Reducing waiting meant making routine order preparation possible through the app. Simplifying the menu meant grouping dishes clearly and placing enough information near each item for a guest to compare options.
The table-service goal meant establishing a link between an order and where it should be delivered. Payment flexibility meant acknowledging different ways guests might complete the transaction, including a counter-assisted path in the broader flow.
Those goals introduced trade-offs. More product information can help a guest choose, but too much at once can slow scanning. An additional review step lengthens the interaction, but gives the guest a chance to correct an order before committing. More payment and service branches increase choice while adding complexity to the flow.
My design response was to keep the early interaction focused and expose detail progressively. The welcome screen offered a single starting action. Browsing surfaced categories and recommendations. Item details opened when requested. The order review collected the information needed for commitment.
Persona Exploration
Alex Walker represented the target situation for the concept: a 32-year-old project manager in South Jakarta, balancing a busy workday with a limited lunch window. He wanted a good meal and a convenient process, without spending most of the break waiting or making rushed decisions.
Alex kept a consistent set of needs in view while I designed the flow. Personality labels and demographics supplied context; the consequential constraints were limited time, desire for meal quality, and preference for clear digital interactions.
Alex’s persona keeps the lunch-time ordering situation visible throughout the design process.
Goals and motivations
The persona brought together efficiency, meal quality, and minimal unnecessary waiting. Those goals helped prevent the concept from optimizing speed at the expense of choice. Alex still needed to understand what he was ordering and feel comfortable with the cost.
Goals and motivations.
That is why the design retained food photography and ingredient descriptions instead of reducing the menu to a dense list of names. It is also why an editable review step remained part of the journey. A fast path that leads to an incorrect order would fail the same user need it was meant to serve.
Pain points and expectations
The persona artifacts described limited lunch time, rushed decisions, inconvenient payments, and frustration with queues or seating uncertainty. The expected experience was quick to learn, clear to navigate, and compatible with familiar payment options.
Pain Points.
Behaviors.
User needs.
Frustations.
These expectations translated into visible design choices: category navigation, a running order panel, quantity controls, a table-service code, and payment selection. They did not justify assuming that every guest would prefer a kiosk or arrive alone. Families, larger groups, and guests who want staff guidance would still need consideration before a real rollout.
Customer Journey and Experience Sequence
The supporting customer journey map organized the experience into arrival, menu browsing, order review, table code and payment, and dining. It helped connect on-screen choices with the guest’s physical movement through the venue.
At arrival, the guest needs orientation. During browsing, the need shifts to understanding the menu. At review, accuracy and cost become central. At payment, the guest needs confidence that the transaction and order have progressed. During dining, the service must deliver the meal and make assistance available.
The CJM brings actions, touchpoints, thoughts, pain points, emotions, and opportunities into one five-phase dining sequence.
The map also made handoffs visible. The interface could capture a table identifier, but staff still needed to interpret it consistently. It could confirm that the guest submitted an order, but fulfillment depended on what happened beyond the screen.
The CJM includes imagined thoughts and an improving emotional curve to explore the intended experience. These elements do not establish customer satisfaction. The map contributes a sequence of guest needs and questions about each service handoff.
✍️ From Journey to Interface
Information Architecture and User Flow
The architecture began with a welcome screen and separated dine-in from takeaway. Both paths then moved through menu browsing, product selection, order details, checkout, and payment preference. The structure covered a wider service scope than the final screen walkthrough alone might suggest.
For dine-in, the flow considered payment within the app or at the counter, followed by table service or counter pickup. The table-service route included entering a table number. Takeaway led toward pickup, again with payment alternatives.
The lower part of the flow showed payment-method selection, payment execution, payment status, printing the order, and finishing the journey. It represented the intended completion path; it did not document all failure and recovery states.
The information architecture connects dine-in and takeaway with payment and fulfillment choices. Payment-method selection and confirmation are shown as a shared completion sequence.
The user flow shows browsing, item selection, order review, table-code entry, payment, and service branches. Its before-and-after timings, queue reduction, heatmap validation, and staff-free routing statements illustrate intended scenarios; they are not verified findings or implemented results.
Why separate service modes
Dine-in and takeaway can share the same menu but require different fulfillment information. A dine-in order may need an association with a table or service marker. A takeaway order needs a clear pickup expectation. Separating those modes gives later screens a way to ask only for relevant information.
The trade-off is that an early mode choice adds another decision before browsing. In the architecture, that decision established the service route. The high-fidelity sequence concentrated on the dine-in/table-service experience, so the full handling of takeaway should not be inferred from those screens.
Where the architecture remained unresolved
The flow includes payment choices at more than one point. It also combines counter and in-app paths with a later shared payment sequence. That is a useful design gap to acknowledge because the meaning of each choice affects what the guest should see next.
The diagram establishes intended coverage, but a production specification would need a consistent distinction between payment location, payment method, fulfillment type, and transaction status. The product considerations below explain how those decisions could be simplified.
Paper Wireframing
The paper sketches show nine proposed screens: welcome, dine-in or takeaway selection, menu browsing, My Order, payment preference, service choice, table-code entry, payment options, and confirmation. They captured the broad interaction sequence before the high-fidelity treatment.
Paper wireframes. The sketches expose mode and service choices that are not all shown as separate screens in the final high-fidelity walkthrough.
What the sketches helped explain
The menu sketch established a relationship between category navigation and the main content area. The order sketch brought selected items and quantities together for review. The service and table-code sketches considered how a digital order could carry a physical delivery context.
Separating payment preference from payment options also reveals the questions the architecture was trying to answer. One question is where a guest pays. Another is which method they use. The sketches made both visible, even though the later flow still needed clarification around their order and branching.
This stage matters because it lets the reasoning be inspected without relying on visual polish. A screen can look convincing while asking the wrong question at the wrong time. The sketches offer a record of how the concept allocated those questions across the journey.
The sketches explain the interaction structure and its relationship to the high-fidelity screens. Participant-led usability testing would be needed to assess whether guests can follow the sequence and recover when a decision is unclear.
Visual Design Direction
The high-fidelity concept used Plataran’s visual references to connect the ordering interface with the dining environment. Warm tones, dark brown action buttons, food photography, and the restaurant logotype gave the screens a consistent identity.
The tablet format allowed a clear division between navigation and menu content. Categories occupied a persistent left panel, while the main area presented dishes or the active task. This layout supported switching categories without hiding the order state behind a separate navigation menu.
Photography had a specific role: helping guests recognize and compare dishes. Names and descriptions still mattered, especially for local ingredients that a first-time visitor might not recognize. Visual appeal could invite exploration, but information needed to support the decision once an item attracted attention.
The welcome, service-code, and payment screens used restaurant imagery as context. Menu and review screens gave more space to structured content. That distinction reflects the different jobs of those moments: orientation, choice, verification, and commitment.
Touch targets, text contrast over photography, readability at the installed viewing angle, and use with different levels of digital familiarity would all matter when developing this visual direction. I return to those decisions in the product considerations section.
📱 High Fidelity Screens and Interaction Reasoning
The final walkthrough contains eight screens. Each screen addresses a particular decision while connecting to the next step. The important question is how that decision helps the guest progress with enough information and control.
Screen One Welcome
The welcome screen uses a dining-room image, a short introduction to the restaurant experience, and a Start Order action. Its purpose is to establish where the guest is and make the first step apparent.
The welcome screen connects the ordering interface to the venue and gives the guest one starting action.
A single primary action keeps this moment from carrying the entire service configuration. The guest can understand how to begin before encountering dishes, quantity controls, or payment details. The brand treatment helps the screen feel appropriate to the venue, but should never make the action difficult to find.
The screen’s photograph and copy convey atmosphere. They do not establish the reliability of the transaction that follows. In a live setting, this is also where clear orientation or an assistance option could help a guest who has not used the ordering system before.
Screen Two Order Now
Order Now brings categories and recommendations into the same view. The left panel includes Recommendation, the prototype promotion, Appetizer, Main Course, Beverage, and Dessert. The main area presents category cards and a recommendation grid, while an order panel gives access to selected items.
Menu navigation and a visible route to My Order remain available while the guest explores dishes.
Menu Main Course
The grid lets guests scan within one category and inspect the items that interest them. Consistent information placement makes comparison easier because the guest does not need to relearn where each dish’s name or price appears.
For an Indonesian menu, dish names and ingredient references can carry cultural meaning while still being unfamiliar to some diners. The image introduces the dish; the accompanying text needs to support understanding. A photograph alone cannot answer questions about ingredients, preparation, or suitability.
Screen Four Item Detail
Selecting a dish opens a modal over the menu. The Sapi Kecombrang example includes a photograph, a description, a price, quantity controls, and Cancel or Add to Order actions.
The detail modal keeps the guest within the browsing context while making an item-level decision.
The modal narrows the task. The guest can inspect one item, choose a quantity, and either add it or return to the menu. Keeping the menu in the background preserves orientation and avoids turning every product inspection into a separate full-page journey.
That choice also creates a design constraint: the modal must remain readable and easy to dismiss on a shared touch device. The concept provides the pattern, while focus handling, touch behavior, and detailed customization would need further specification before implementation.
Screen Five My Order
My Order collects the chosen dishes in an itemized view with price, quantity, and line total. The summary shows subtotal, the prototype tax line, and the total, with quantity editing and a checkout action. A discount or gift field is also included.
The review screen exposes item quantities and the order total before checkout.
This step provides a correction opportunity before the guest commits. It is valuable even though it adds another screen. A change made here can be simpler than trying to revise an order after payment or after the kitchen has begun preparation.
The summary also makes cost part of the review. The same item data and total would need to stay consistent through payment and fulfillment; otherwise the clarity established here would disappear at commitment.
Screen Six Table Code Entry
The table-code screen asks the guest to take a table-service marker and enter its code. The example shows 27, with a numeric keypad and routes back or home.
The service-code screen asks the guest to connect the order to a physical service marker.
The code connects a digital order with a physical point of service. It gives the guest an explicit way to supply delivery context instead of leaving that information outside the interaction.
The service model would need to decide whether the identifier belongs to a fixed table or a portable marker. It would also need to explain who supplies it, how a location change is handled, and whether seat assignment happens elsewhere. Those decisions determine what the field can reliably tell the kitchen and floor team.
Screen Seven Payment Options
The payment screen presents card and QRIS options in a focused selection panel, with QRIS selected in the illustrated state. The Pay action follows the method choice.
The payment screen makes card and QRIS choices visible before the Pay action.
The design uses recognizable labels and payment marks to help guests understand the choices. Showing the selected option also makes the impending commitment visible rather than asking the guest to infer it from the next screen.
The broader IA includes counter payment, while this screen illustrates the in-app method-selection step. A complete service would need to explain how guests reach the assisted path and when an order becomes accepted. Those are process decisions beyond what a payment-method modal can resolve.
Screen Eight Confirmation
The confirmation screen uses a checkmark, a thank-you message, an instruction to wait at the table, and a Home action. It closes the immediate interaction and tells the guest what the system expects next.
The final screen communicates the intended completion state and next guest action.
That clarity matters because the guest should not need to guess whether to remain near the kiosk, collect a receipt, or return to the table. The confirmation is the interface’s promise that the order has moved forward.
The concept does not document the technical acceptance signal behind that promise. In the product considerations section, I distinguish a successful payment from a kitchen-accepted order so that the message can be tied to a dependable event.
🧪 Prototype Exploration and Design Outcome
Prototype Exploration and Conceptual Heatmap
The prototype exploration includes a heatmap over the menu view. It places activity around category cards, recommendation content, and food imagery. You can use it to understand the attention pattern the design was exploring.
I used this illustrative heatmap to question whether the prominent cards and food imagery might draw attention away from category labels and the order panel. That made it a prompt for later observation, rather than a reason to stop refining the layout.
Illustrative heatmap over the menu view, highlighting cards and food imagery for later attention testing.
Within that boundary, it still offers useful questions. Are category cards visually distinguishable from dishes? Is the route to My Order clear after adding an item? Does a guest understand that the recommendation grid is a starting point rather than the entire menu?
Those questions move the discussion from whether an image attracts attention to whether the interface supports the intended task. The distinction becomes important when deciding what to test next and which design decisions can be defended with evidence.
Design Outcome and Intended Impact
The design output was a tablet experience supported by a persona, a branching flow, paper wireframes, and eight high-fidelity screens. Together, they make the ordering sequence visible from welcome through confirmation.
The design aimed to reduce cashier pressure, make menu selection easier, clarify table-service coordination, and offer convenient payment. It pursued those aims by distributing menu discovery through the app, keeping order details visible, capturing a service identifier, and presenting recognizable payment choices.
The contribution of these artifacts is an inspectable sequence of decisions. The product considerations below show how I would test whether the same sequence works with guests, staff, and restaurant operations.
🚀 Product Considerations and Next Steps
Moving from the interface design to a working service would require resolving the decisions between screens and operations. I would address the following questions in development and validation.
Define seating and device placement before refining the flow
I would first define how guests are seated, where they browse, and what the service code means. A shared kiosk can support self-ordering, but may develop its own queue and require guests to leave their table. An at-table tablet supports seated browsing while introducing hardware, cleaning, maintenance, and support costs.
A mobile alternative would have different assumptions about connectivity and guest devices. It should be evaluated against the same journey rather than being introduced solely because it reduces restaurant hardware. The relevant question is which model helps the intended guests choose and complete an order with acceptable staff effort.
For this concept, I would preserve host-led seating and explicitly define either a fixed table identifier or a portable service marker. The floor team would need one consistent procedure for assignment, invalid codes, moves, and exceptions. A table-code input should not be responsible for determining whether a seat is available.
Simplify the decisions that describe the order
The IA mixes where payment happens, which method is used, and how the meal is delivered. I would separate those decisions and ask each only where it changes the route.
For the initial dine-in path, that could mean establishing seating, browsing and reviewing an order, confirming the service identifier, choosing a supported payment or assisted route, and then receiving an accepted-order confirmation. Takeaway would be a separate fulfillment path rather than another sequence duplicated inside the same diagram.
The improvement is a more consistent model that design, engineering, and operations can all interpret. It should be possible to describe what happens after each choice without discovering an extra payment question later in the journey.
Proposed service flow. Payment reconciliation, order acceptance, and recovery requirements would need to be specified and validated before implementation.
Design recovery alongside the successful path
I would specify the situations that can interrupt the meal journey before treating the screens as ready for development. An item can become unavailable, the guest can enter an invalid code, connectivity can fail, or payment can remain unresolved.
Each situation needs a clear explanation and a route forward. An unavailable item should return the guest to an editable order. A mistyped code should be correctable without rebuilding the cart. An unresolved payment should avoid encouraging repeated charges and should give staff enough information to help.
The order record and its payment attempts would need consistent identifiers so that recovery does not create duplicate kitchen tickets. The interface should distinguish a pending payment, a confirmed transaction, a failed attempt, and a case that needs reconciliation. The exact behavior would be specified with the payment and fulfillment providers chosen for delivery.
Kitchen acceptance is another separate event. A guest should only be told that preparation is underway when the service can support that statement. If an estimated wait is shown, it needs a source and a way to change as conditions change.
Preserve assisted service and improve inclusive use
Hospitality includes helping guests whose needs cannot be reduced to the standard ordering path. I would make assistance discoverable at the points where uncertainty is likely: choosing a dish, understanding ingredients, resolving a code, and completing payment.
For the local setting, I would evaluate whether Indonesian and English menu language is useful for the intended guest mix. Clear language switching should preserve the cart. Ingredient explanations should come from maintained restaurant information, with staff help for dietary questions rather than assumptions drawn from food imagery.
I would also examine text contrast over photography, touch-target size, keyboard use where relevant, focus behavior in the item modal, and how the installed device can be reached and read. The visual identity can stay warm and recognizable while the interaction becomes easier to use.
Keep the first delivery scope narrow
I would begin with one reliable dine-in journey: current menu and availability, editable order review, a defined service identifier, supported payment and assistance paths, and an accepted-order record that the floor and kitchen teams can use.
Takeaway expansion, personalized recommendations, loyalty, advanced seating tools, and mid-meal reordering would follow only when the core journey was understood. They introduce different data, service, or fulfillment requirements. Adding them together would make it harder to identify why a pilot was helping or failing.
The business case would consider device and operating costs alongside any reduction in repetitive cashier work or incorrect orders. Staff time might move into assistance and exception handling rather than disappear. Kitchen capacity would still constrain how quickly meals could be fulfilled.
Establish a measurement and pilot plan
I would measure time from a guest being ready to order to a correctly accepted order, including kiosk waiting and recovery. Median and slower-end experiences would help reveal whether typical guests benefit while some groups struggle. Arrival-to-food delivery would give a broader check on the service.
Completion would mean a correctly accepted order, with all ordering attempts started as the denominator. Supporting measures would include abandoned attempts, assistance requests, order corrections, duplicate charges or tickets, payment exceptions, and meals delivered to the wrong location.
Guardrails would include staff workload, kitchen delay, and the guest’s perception of hospitality. A faster interface would not justify more fulfillment errors or a worse experience for people who need assistance. Definitions and acceptable limits should be agreed before evaluating the pilot.
I would then compare a contained pilot with a baseline from similar service periods, accounting for demand, staffing, party size, and menu availability. Guest and staff feedback would help explain changes rather than leaving the team with a dashboard alone. Persistent reconciliation issues, incorrect fulfillment, or staff overload would be reasons to pause and correct the service before expanding it.
📝 Reflection and Takeaways
Reflection and Product Learning
This project gave me an end-to-end view of how interface choices shape an ordering journey. The persona translated a broad brief into a consistent user situation. The architecture exposed service and payment branches. The sketches made those decisions visible before the final screens gave them a visual identity.
A consequential learning is how much a persuasive screen can leave unresolved. A table-code field looks simple until the floor team has to define what the code identifies. A confirmation message looks complete until payment and kitchen acceptance disagree. A self-ordering station looks efficient until guests queue to use it.
The operating questions should shape the interface from the start. The menu, detail, and review patterns provide a useful foundation; their value depends on the service around them reliably fulfilling the guest’s choice.
For a future iteration, the next step would be validating that full journey with guests and staff, then deciding whether the concept deserves investment. The aim would remain a clearer ordering experience that supports the meal and leaves room for personal hospitality.
📌 Disclaimer: This case study reflects my digital product process and perspective through an independent concept created for educational purposes. It was not an official engagement or a released product change. Illustrative elements, research limitations, and the absence of verified product or business impact are identified based on the available project evidence. Brand names and imagery belong to their respective owners. All views expressed are my own.
💬 Let’s Connect: Have feedback or thoughts on this case study? I’d love to hear from you. Feel free to leave a comment below or explore more of my product and experience work at cahyadiaditya.site. For a discussion, reach me via Telegram or connect with me on LinkedIn. Thank you for reading.
