"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
My role: Lead Product Designer in collaboration with Product Manager, and Engineers.
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: Reduced average table turnaround time by 3.5 minutes using QR code split checks. 12.1% of QR code paid checks were split compared to 9.5% split checks for traditionally paid checks
More on Process More on Final DesignResearch 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.
How might we let multiple guests independently split and pay a check while minimizing coordination between guests and servers?>
"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
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:

We've reached our goal if guests prefer our experience vs existing solutions like Venmo. Main stakeholder
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 self-service splitting at all, and to learn how a shared QR payment 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
The MVP validated that guests wanted to split checks themselves. But it also taught us that a successful card charge wasn't sufficient on its own. Everyone involved needed confidence that the shared transaction was complete. Especially, staff who lost visibility into check splitting process.
To close the loop, 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.
Split Even validated demand for self-service splitting, but it didn't address situations where guests had spent very different amounts. Feedback consistently highlighted the need to choose specific items, so we expanded the experience to the ability to split by item.
The main technical challenge that we had to overcome was the lack of real-time updates, meaning two guests could potentially select the same item to claim. Multiple guests could now try to pay the same items on the same transaction.
The system needed to validate the state of the check before allowing the transaction to proceed. If another guest had already claimed an item, we needed to communicate that the check had changed and help the guest recover rather than allowing them to continue with outdated information.
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.
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.
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.