Why We Designed a 3-Tap Order-to-Payment Flow — and What We Learned About Speed During Rush Hour

The Problem We Were Trying to Solve

Picture this: it's noon, your cafe is packed, there's a line of 8 people, and your cashier has to navigate 4-5 screens to process a single order. Tap a category, scroll to find the item, tap the item, confirm, select payment, confirm again, print receipt. Each order requires 30-45 seconds of screen interaction. Multiply that by 8 people in line, and the last person is waiting 4-6 minutes.

Now imagine each order only needs 10-15 seconds of screen interaction. The same line becomes just 2 minutes. The difference of 2-4 minutes sounds small — but for a customer standing and waiting, it's the difference between "fair enough" and "why is this taking so long."

This has been our obsession from day one: how to make the flow from "customer states their order" to "receipt prints" as fast as possible, without sacrificing accuracy.

Design Principle: Every Tap Must Justify Its Existence

When we started designing the POS flow, we analyzed existing POS systems on the market. Most had a similar flow: select category, find item, tap item, open cart, review, select payment method, confirm, done. That's 6-8 steps, depending on how many items are ordered.

Our question: which steps can be eliminated without losing information the cashier actually needs?

We arrived at a simple principle: every tap should either provide new information or capture a new decision. If a tap merely confirms something that's already obvious, it doesn't need to exist.

Decision 1: A Flat Menu Grid, Not a Layered One

Many POS systems organize menus in a hierarchy: Category, Sub-category, Item. This makes sense if you have 200+ items. But for small-to-medium cafes with 15-40 items, this hierarchy only adds taps without adding value.

We chose a grid layout that shows all items in a single layer, organized through category tabs at the top. A cashier taps the "Coffee" tab and immediately sees every coffee item — no need to drill down into sub-categories. One tap to reach the desired item.

The trade-off: if you have lots of items, the grid can feel crowded. But for our target users (small-to-medium cafes and restaurants with managed menus), this trade-off is worth it because it significantly reduces navigation steps.

Decision 2: An Always-Visible Cart

In some POS systems, the cart is a separate screen you have to explicitly open. Which means: tap an item, open the cart to review, go back to the menu to add more, open the cart again. Back and forth between two screens.

We chose a split-screen: menu grid on the left, cart always visible on the right. Every time the cashier taps an item on the grid, it immediately appears in the cart — no additional navigation. The cashier can see what's been ordered while continuing to add items. Zero context switching.

This also reduces errors. Because the cart is always visible, the cashier doesn't need to remember what they've already tapped — visual feedback is right there on screen. If they tap the wrong thing, they just delete it from the cart that's already visible.

Decision 3: Minimal Payment Flow

Once all items are in the cart, the final step is payment. Here we had to balance speed with flexibility.

Our flow: tap the "Pay" button, select the method (Cash or QRIS, one tap), if cash then enter the amount received, done — receipt automatically sent to the printer. For QRIS, it's even shorter: tap "Pay," tap "QRIS," done.

We deliberately didn't add an "Are you sure?" confirmation screen before finalizing the order. Why? Because during rush hour, double confirmation just slows things down without adding value — experienced cashiers already know what they're doing, and the always-visible cart already functions as a review screen.

What about mistakes? There's a void feature that managers can access quickly. We'd rather have a fast flow for the 95% of normal cases and handle the 5% of errors through a separate mechanism, than slow everyone down to prevent mistakes that rarely happen.

What We Learned: Speed Isn't Just UX

After our POS was being used in the field, we learned that flow speed isn't just about tap count. There are other factors equally important:

• Loading time: If every tap takes 500ms to load the next screen, 3 taps feel like 6. We invested significant time in performance optimization so every transition feels instant.
• Touch target size: On a tablet used with hands that are sometimes wet or greasy (this is a kitchen, not an office), buttons that are too small = mistaps = wasted time. We made grid items and payment buttons generously sized.
• Visual hierarchy: If all buttons look equally important, the cashier's eyes need time to find the right one. We use color contrast and sizing to guide the eye to the most commonly taken action.

Trade-offs We Accepted

A design that chases speed has trade-offs. Some we're aware of and have accepted:

• Limited flexibility for complex customization. Our 3-tap flow works great for standard orders. But if your business needs complex modifiers (size, sugar level, ice level, add-ons — each with sub-options), the tap count will go up. This is an area we'll develop in future versions.
• Low learning curve, but assumptions about menu size. The flat grid layout assumes your menu isn't too large. For restaurants with 100+ items, this approach might be less optimal than hierarchy-based navigation.
• No double confirmation means you need robust void features. Because we skip the confirmation screen, we have to make sure cancellation and correction features are easily accessible and well-designed. Speed in one place demands a safety net in another.

Why This Matters for Your Business

POS speed isn't just about tech — it's about customer experience and operational capacity. A slow POS means longer lines, customers who leave before ordering, and revenue lost. During rush hour, a difference of 10-15 seconds per transaction can mean 5-10 additional orders per hour.

When you evaluate a POS for your business, don't just look at features on a list. Try it yourself: how many steps from first item to receipt? Does each step feel necessary? Do transitions between screens feel instant or is there loading? Five minutes of trying the order flow will tell you more than 50 pages of feature comparisons.