Table needed its most repeated workflow to feel invisible. Three versions, six months,
and a fundamental shift in how we thought about who we were designing for.
Product Recording
Idea Behind the Billing Flow
For small restaurants, billing is the product.
Table is a billing product for small restaurants. The screen where owners add items, generate KOTs,
assign tables, capture customers, select payment mode, apply discounts, and print receipts.
Every order ends here. At this stage, Table was still proving product-market fit in a new category.
This meant one thing clearly: if the core billing loop felt slow or broken, users had no reason to come back.
No downstream feature could compensate for a bad first loop.
The constraint that shaped everything
Most orders in small restaurants involve only 2–3 items. The need wasn't depth of review, it was fast selection and confident completion. Speed wasn't a feature request. It was the product requirement.
RESEARCH
What billers actually do vs. what we assumed they'd need.
Before designing, I spent time observing how small restaurant owners create bills in real operations.
Not in interviews, but watching the actual workflow happen.
Field research
The ideal path was: select item → generate bill.
This research produced one clear design principle: the workflow had to be built around the most common action,
not around optional fields that only a fraction of users would use. Optional features could live in the flow,
they just couldn't tax the majority who never needed them.
VERSION 1 MVP
What billers actually do vs. what we assumed they'd need.
V1 was built on a single hypothesis, that layout density would directly drive billing speed. If users could see more
items at once, they could scan, select, and add without navigating. Since food decisions are often visual
and menu recall builds quickly, I leaned into an image-heavy grid layout where the item image came first,
name second, price third, and the add CTA was clearly accessible.
There were suggestions to follow consumer food-app patterns where each row focused on a single item.
That pattern optimizes for discovery. This workflow optimizes for repetition. Those are different problems.
What V1 got right
#3 Strong density suited to small menus
What V1 got Wrong
What I chose not to redesign yet
Table number assignment was auto-set in V1, and users were rarely changing it. The signal was ambiguous,
low interaction could mean the control was buried, or it could mean auto-assignment was already working.
Since it wasn't creating visible friction elsewhere, I held off and prioritized higher-friction behaviors first.
VERSION 2 POST-LAUNCH
The first release exposed what mattered more than expected
After 10,000 logins, behavior patterns clarified which assumptions had been wrong. I studied events
in CleverTap and watched sessions in Microsoft Clarity.
Changes made in V2
CHANGE 1
Introduced KOT after confirming the need was stronger than the MVP assumption
CHANGE 2
Brought payment mode closer to the billing workflow, reduced the detour through Add Details
CHANGE 3
Introduced screen-level settings, so each page's configuration stayed close to its own workflow
The harder call
Not every weak signal deserved an immediate UI change. KOT, payment mode, and search friction had clear enough signals to act on. Table number assignment was still ambiguous. I chose to protect billing speed and leave ambiguous signals alone until I had stronger evidence.
VERSION 3 STRUCTURAL REDESIGN
The real breakthrough came when I stopped treating
all billers as the same user.
By V3, the problem was no longer just speed. It was mismatch.
Deeper analysis of CleverTap events and Clarity session recordings revealed
that users weren't billing in the same way,
three distinct patterns had emerged, and the existing interface was optimized for only one of them.
Pattern 1
Direct from list
Users with smaller menus adding items directly from the default view. The current design already served them well.
Pattern 2
Category-first
More common in restaurants with larger menus. These users were struggling with excessive scrolling,
a friction point the design wasn't addressing.
Pattern 3
Search-first
16% of all users. Search found the
item, but couldn't add it. Users had to exit search and navigate back to complete the action. Completely avoidable friction.
Changes made in V3
IMPACT
Behavior change was the proof.
The strongest validation wasn't qualitative, it was that users started doing things
they hadn't done before. That's a different signal than satisfaction scores or NPS.
Regular customer saves
5% → 28%
Increase in MAU
from billing + FTU
Category layout adoption
32%
Users selecting into the billing
style that matched their menu complexity
MAU contribution
+10%
Combined billing and FTU improvements, retention signal, not just usability
🚀
Better billing design didn't just improve the screen, it improved how people adopted and continued using the product. For a product still finding product-market fit, that distinction matters.
Reflection
Designing for repetition, not one-time delight.
High-frequency experiences are rarely solved through one strong first version.
The real design work in a core workflow isn't the initial layout decision.
It's the discipline to keep observing, to separate real signals from noise,
& to resist adding complexity when the workflow is already working for the majority.
Summarised by sahil.ai
The 5-Second Bill
One goal, help restaurant owners create a bill in 5 seconds. Sahil owned the billing workflow across 3 versions, 6 months, and a lot of behavior data. Somewhere around 10K logins in, he realized something: not everyone bills the same way. That one insight changed everything. He redesigned around three distinct behaviors, and the numbers followed, customer saves went from 5% to 28%, a third of users adopted the new layout, and the product moved MAU by 10%.
1L+ Downloads
4.6★ Ratings
15K+ MAU