"If we're able to do it ourselves and move stuff around... it would make it easier....Then we could just do the whole thing from start to end by ourselves and have it paid and done" Guest research participant
Refresh the page if the video isn't playing
Simplifying splitting the check
My role: Solo Lead Product Designer
Problem: Splitting a check for a large group can be a frustrating and time-consuming part of the dining experience. Guests have to coordinate who ordered what, while servers spend additional time dividing the check, processing multiple payments, and making sure the full bill has been covered. It can slow down table turnover during busy times.
Solution: We designed a self-service check-splitting experience that gives guests control over how they divide and pay their check, reducing coordination with servers and streamlining checkout for both guests and restaurant staff.
Outcome:
-3.5min ave table turnaround time
+18.4% split checks vs traditional
Splitting isn't just a payment problem—it's a coordination problem.
Research showed that splitting created operational burden for restaurants and social and coordination friction for guests. Large parties were especially difficult, and for some guests, the ability to split a check even influenced which restaurant they chose.
- Guests don’t like to spend time on figuring out how to split the bill and all the back-and-forth it requires
- Guests can feel uncomfortable asking the server to split their check, and will sometimes use Venmo to avoid it
- Servers feel uncomfortable asking Guests what they ordered if they haven’t assigned items to seats
- Dealing with check mistakes creates a negative Guest dining experience
The opportunity
How might we let multiple guests independently split and pay a check while minimizing coordination between guests and servers?
Defining the risks before designing
Before exploring solutions, we brought the team together to identify the failure modes that could make self-service splitting worse than the existing experience. Three questions guided our design decisions:
- How might we make self-service splitting faster and simpler than the existing process?
- How might we prevent incorrect splits and make mistakes easy to recover from?
- How might we ensure the entire check gets paid?
We've reached our goal if guests prefer our experience vs existing solutions like Venmo. Main stakeholder
Starting simple with Split Even
The full experience could eventually support different ways of splitting a check, but creating a shared payment experience was complex on its own. We started with Split Even, the simplest shared payment model, to validate whether guests would use the ability to split the check themselves, and to learn how a QR code check splitting affected both guests and staff.
One important constraint was that once a check had been split, the split couldn't easily be reversed. That made preventing mistakes particularly important.
Refresh the page if the video isn't playing
Server handheld device notification letting them know guests initiate the split of a check
Server handheld device notification letting them know the check has been paid
Partial split payment display on server's handheld devices the same way as server initiated split partial payments
Keeping servers in the loop
During MVP launch, we've learned that eventhough servers weren't actively participating in splitting check, it was important to keep them aware of the process. We introduced a POS notification system for staff: servers are notified when guests begin splitting a check, see which portions have been paid, and are shown clearly when the full check is settled.
From Split Even to Split by Item
With the first phase, we've validated that guests wanted to split the check themselves. But the feedback we got consistently highlighted the need to split the check by item as well, so we designed and built it next.
The main technical challenge that we had to overcome was the lack of real-time updates. If an item was just claimed or paid by one person, it wouldn't automatically update for other people splittting the check at the same time. The experience needed to validate that the item was still available before proceeding. If another guest had already claimed the item, we needed to communicate that. To compensate for the limitation, I throught through all possible race conditions and error states for them.
Using POS data to make splitting easier
There was also an opportunity to reduce how much work guests needed to do. 7% of restaurants required servers to put in order by seat, while 60% had it as optional. When reliable seat item grouping existed, we wanted to surface it to the guest instead of asking them to select every individual item. We've also learned that pre-existing item grouping while helpful was not always accurate. So, we gave guests the ability to move items from one seat grouping to another if needed.
Validating the experience—and uncovering limits
Talking to 6 restaurant operators, 6 servers, and 5 guests validated the value of self-service item splitting, but surfaced that having items accidentally left unpaid was the biggest concern among guests and servers. Guests liked having control over what they paid for and servers valued reducing the work of splitting checks, but both sides needed confidence that every item would ultimately be covered.
"It would be less of a pain for the waitress and you wouldn’t have to be anxious about asking your waiter to split the bill. And make sure everybody is comfortable with what they are paying for."Main stakeholder
Outcomes and learnings
Starting with Split Even allowed us to deliver value while learning how guests behaved in a shared payment experience. Split by Item showed us that splitting a check wasn't simply a payment interaction—it was a shared transaction. Testing validated the value of giving guests more control and reducing work for servers, but it also surfaced a critical requirement: everyone needed an accurate understanding of what had been paid and what remained. The biggest concern among restaurant participants was items being left unpaid.
Rather than designing around the lack of real-time updates, we paused Split by Item development until engineering could support the real-time updates the experience required. Once that foundation was in place, we resumed development and launched Split by Item. After launch, QR-code split checks reduced average table turnaround time by 3.5 minutes, and 12.1% of QR-paid checks were split, compared with 9.5% of traditionally paid checks.
This project changed how I think about payment design: a successful transaction isn't just whether money moves—it’s whether everyone involved understands and trusts the state of that transaction.