Tringg: ordering from the table, without losing the waiter.

For diners: eating out means lots of small delays, like waiting for menus, repeating your order, and waiting too long for the bill.

For restaurants: waitstaff make up 12–22% of running costs, staff keep leaving, and every wrong order loses money.

I designed Tringg for both. Diners scan a QR code at their table, send their order straight to the kitchen, and pay from their phone. Waiters stay, but no longer need to take orders.

This case study focuses on one design decision: the one that taught me the most about product design.

Restaurants wanted a fix too: in our market study, 70% of the restaurants, cafés, bars and lounges we spoke to were interested in the diner app.

The problem statement I wrote for the team:

The last part mattered. Other QR-menu apps had cut waiters out completely. Our restaurant partners told us their service was what set them apart, and an app that replaced the waiter would hurt their brand.

So the rule became: move ordering and payment into the app, keep the service human.

What I hadn't worked out was how diners would reach a waiter once they no longer needed one to order. Testing showed me.

What I'd already built

By the first usability test, the first version worked well. Diners could scan a QR code at their table, browse the menu, order and pay, all from their phone. Early reviews went smoothly, and we were polishing for launch.

The usability test

I ran a moderated test at a partner café in Mumbai with five first-time users. I expected to find small issues in ordering and payment, like button sizes, unclear wording or layout.

It was a Saturday, and the café was busy.

What I expected to find

Small visual fixes, maybe to a dish card or the checkout wording. I'd written a list of likely findings before the session.

What I actually found

Three of the five participants tried to wave down a waiter during their tasks. The app hadn't failed: they had already ordered. They needed something the app didn't cover. When I asked why, they said things like:

Changing the problem statement

My original problem statement treated “calling the waiter” as an old habit to remove. Testing showed it needed to be redesigned, not removed.

This was harder to accept than the design fix. I'd written the problem statement and defended it to stakeholders. Now I had to tell them: the thing we were trying to remove is the thing we need to build.

The design: the scan button becomes Call Waiter

Once a diner scanned the QR code and was “checked in” at a table, the scan button in the bottom navigation turned into a “Call Waiter” button. Same place, same size, still easy to reach with a thumb.

My rule: no new tab or screen. The bottom navigation already had four buttons, and a fifth would crowd the most-used part of the app. Swapping one button was the simplest fix.

Next step: telling the waiter what you need

For the next version, I sketched a way to say why you're calling. The diner taps Call Waiter and picks a reason (water, cutlery, a question, or their own note). The waiter's tablet shows the table number and the reason, so they arrive knowing what's needed.

This cuts two trips (asking what's needed, then bringing it) down to one. For a restaurant serving 80–120 diners on a busy night, that adds up to hours of staff time.

Why it mattered for the business

This is my clearest example of one design decision helping both diners and restaurants:

• Diners could easily reach a person again. The app stopped feeling like a vending machine.
• Restaurants got faster service and a record of the most common requests, useful for staff training and menu wording (if “is this spicy?” is the top question, the menu needs clearer descriptions).

In pilot demos, restaurant partners reacted most strongly to Call Waiter. It showed we'd designed with restaurants, not around them.