Cheque, please!
Improving the Android-based, Kody payments terminal by identifying the main issue in the payments workflow and building an intuitive and simple solution.
lead product designer
JAN-APR 2023
figma
Context, Problem & Objective
Context
We shipped an MVP of our payment app for processing payments in the UK and Europe. The app is Android-based and runs on a card-scanning and printer-equipped payment device that we just call “Terminal”. We’ve been gathering feedback in the form of data and some anecdotes from our predominantly restaurant-owner clients, we refer to them as “Merchants”.
Problem
Reportedly, since switching to our devices, there have been some cases of unnecessary refunds, increased unexplained bill-to-payment discrepancies and slower average overall payment processing time. These problems are costly and painful.
Objectives
With the goal of improving the quality of our product, we aligned on the following mandate:
Minimize refunds & discrepancies
Reduce payment processing time
Streamline customer experience
Discovery: Research & Hypotheses
Product Users
Our primary users are FOH (front-of-house) restaurant staff in the 18-30 age group, other key stakeholders include restaurant managers in the 25-60 age group.
In-depth Interviews
We started by spending time with our merchants (both staff and managers), categorizing our observations by pain point, gain point (things we like about your product) or behaviour (things we do day-to-day).
The Main Pains
Speed
Managers mentioned a general increase in their staff’s payment processing time.
Errors & refunds
Managers and staff cited a small, but unexplained, increase in refunds and end-of-shift discrepancies.
Features
Staff complained that our terminal was missing some key features that their previous devices had.
Exploring Hypotheses
Hypothesis 1
Maybe our devices were just inherently slow, i.e. compared to competitors, they just took longer to process actions.
Investigation:
Basic flow: enter amount, tap card, print receipt.
Test the current Kody Terminal app against competitors.
We actually faired quite well in this test, suggesting processing time for individual transactions likely isn’t an issue.
Hypothesis 2
Maybe our devices weren’t very usable, i.e. maybe the buttons were too small, the actions unclear, the system status invisible, etc. resulting in errors and the impression of slowness
Investigation:
Conducted a usability heuristics audit and surveyed 30 merchants.
Despite finding some areas for improvement, we found that the current implementation was relatively usable, which was validated by our merchant’s feedback.
Hypothesis 3
Maybe it wasn’t the typical payment flow that was the problem, maybe the features that our merchants kept mentioning played a role in the pains we were seeing.
Investigation:
Competitive feature audit and review of primary research.
Most of our competitors had a feature to help process split payments.
Many merchants cited our main competitor, Dojo, as having a “Bill splitting” feature they loved.
Quantitative Research
To explore this third hypothesis further, and learn more about the space of splitting payments, we analyzed our large database of payment events.
More than 1 in 10
For some merchants, at least 10% of transactions might be associated with a split payment.
10% more refunds
For these types of payments, the frequency of associated refunds was approximately 10% greater.
Costly errors
Increased refund rate suggests a higher rate of errors potentially resulting in approximately £100/night per merchant of lost revenue or over-charged customers, and end of shift discrepancies.
Slow payments
We estimated that payment processing time (adjusted for an individual payment) for this type of payment event was as high as 3 times longer than a typical individual payment.
Definition: HMW, Personas, Task Mapping
How Might We
How might we reduce user error and decrease payment processing time so that our merchants can be more efficient and accurate, saving them time and money, and helping them increase customer satisfaction.
Competitor Analysis
Easily our main competitor in the space, Dojo’s white terminals are popular and ubiquitous.
What we heard:
Good stuff: very minimal and easy to use, merchants found them enjoyable to use.
Bad stuff: we heard there were sometimes reliability issues, and they were costly to purchase and maintain.
Dojo has a well developed bill splitting feature, but some merchants weren’t aware of it, hadn’t bothered to enable it, or had enabled it but didn’t want to be interrupted every payment with a prompt to split the bill.
Many of our merchants were moving to us from old-school, clunky old card terminals like the Ingenico model.
What we heard:
Good stuff: tough machines, very reliable.
Bad stuff: limited features, physical keypads get gummed up, features are outdated or hard to understand
As far as we could tell most merchants either thought these devices didn’t have bill splitting features, and if they did many servers didn’t know how to use them
Primary User Persona
Jenny Li
Server/Waiter
About
25
Student
London
FOH Staff
Description
Jenny works at a busy restaurant in downtown London to pay for her rent and college tuition.
A day in their life
She spends much of her day studying or working on school work, until she clocks in for a long shift at the restaurant.
In her spare time she likes to paint and visit her parents, but these days there isn’t a lot of time.
Pain points
Anything that slows down service means less tips, less income.
Undercharging customers could mean she will have to pay out of pocket, overcharging means she could be fired.
Secondary User Persona
Ruth Peters
Restaurant Manager
About
45
BBA
London
Manager
Description
Ruth manages a London steakhouse, is a single mother with a mortgage and cares for her aging parents.
A day in their life
Up early getting the kids off to school, dealing with household chores and finances, caring for her parents.
She spends more time at the restaurant than she would like to admit, but holds herself responsible for the financial success of the business - so do the owners!
Late, stressful nights balancing the books and managing both her home and the restaurant.
Pain points
Refunds and reconciliation discrepancies cost her both her time and her reputation.
Customer reviews and brand value are extremely important for her professionally.
Task Mapping
Design: Prototyping, Testing, Iterating
Wireframes
Scenario 1
Option A - selecting “Split” from the terminal main menu
Scenario 1
Option B - selecting “Split” from the New Payment screen
Initial User Testing
A/B Test
Which of these two workflows is more efficient for our users?
Method:
Group of 10 Kody staff, and 11 merchant staff members
We ran 3 cohorts through the ‘Scenario 1’ task flow, total payment amount is £73.48 (didn’t want to make it too easy) fully process a split payment for 2 diners.
The first cohort used the production app (no bill splitting feature) and was given no other instructions. The other two used versions A and B above.
We observed participants and measured:
Speed - how quickly could they take the payments
Accuracy - whether or not mistakes were made, and any additional steps to ensure accuracy.
Results:
The two proposed options scored identically in accuracy, and outperformed the control cohort who recorded accuracy errors in 43% of participants.
Not surprisingly, both proposed solutions beat the control group soundly in speed, option A clocking in at an average 18 seconds faster, and option B with an average speed 6 seconds faster still.
Both solution cohorts reported enjoying the experience, with servers in each group asking “when can we actually use this?!”
An interesting feedback we received from 3 separate servers was that although they enjoyed the Option A version, they said this would limit them from entering a bill amount before approaching a table - something they often did to save time.
Rapid Iteration
Segmented button
Some test participants said they had a hard time finding the split button in the top right, others said they had to adjust their grip to select it
We heard that the button saying “Split” on the screen might suggest that regardless of selecting it, maybe this “payment type” was split
I decided to try out a segmented button, which would be “pay in full” by default, with the option to change your payment type at any point before clicking “Continue”
This also gave us an intuitive way to incorporate “custom splits”
Progress indicator
A pain that we had heard often, and one of the contributors to mistakes, was losing track of the payment
I decided to include a top section which would be present on all merchant-facing screens, that included a summary and progress bar so it was clear how many payments were remaining, and how much of the total amount had been collected
Extra Considerations
Many years in the restaurant industry myself, I picked up a couple heuristics specific to this industry
Sticky Fingers Rule
Our devices should be usable even if you’ve got dirty hands, full hands, only one hand available... you should be able to get from payment input to receipt printing without having to do anything that would require pin-point accuracy, two hands, or fine dexterity
Over the Counter Rule
During times when customers are holding the device (entering a tip, etc) it’s very important that the service staff have some visibility into the system status. This means some visual elements which might otherwise feel oversized or garishly saturated insure that the server, who might be across a counter, can still see the result of a payment - for example.
Delivery: Hi-fi Designs & Metrics
New Payment Screen
The app’s landing screen, providing a quick and easy entrance point into the payments flow
Equal Split Screen
If a payment is initiated with “Equal split” selected, the next step is to decide how many splits you need.
Custom Split Screen
If a payment is initiated with “Custom split” selected, the next step is to designate the amount of the first split.
Success/Confirmation Screen
If a payment is initiated with “Custom split” selected, the next step is to designate the amount of the first split.
Impact & Conclusions
19.8% of all payments
Since launching the feature 19.8% of all payments taken are split payments, approximately 80% of those being equal splits.
4% reduction in refunds
We can’t definitively say this is directly related, but across our network we did record a reduction in refunds by about 4% since launch.
£440,000 per day
Considering our peak processing volume, annualized, reached £800M recently - this means as much as £440,000.00 is being processed with this feature... each day!
NPS increase
During the period directly following the release of our bill splitting feature we tracked a noticeable uptick in NPS scores and anecdotal feedback related to the feature.
Recently, when working on an improvement to the “Totals” function - which is the function used by merchants to do their end of shift reconciliation - more than one merchant mentioned that the new totals function is excellent but it’s a shame that they hardly have to use it since the bill splitting function was introduced
Next steps:
As well as improving the transaction list, we got some feedback around identifying split payments on receipts for both merchants and customers.
A huge opportunity in this space is the ability to split bills by item, rather than by currency value - we’ve started an investigation into the integration space.