Why a Teen Payments Feature?
To keep up with digital banking trends and the needs of our teenage customers, my team and I began to explore the idea of a payments feature, providing a growth opportunity for the business through the use of payment links.
Working collaboratively alongside a PM, User Researcher, 1 BE and 2 FE Developers, I led the design of the payments feature from start to present across iOS, Android and Web.
Given the nature of GoHenry's SDK (a gaming platform called 'Corona' 🤢 ), we were limited in scope, meaning we couldn't implement nice micro-interactions or A/B tests.
Our issuing banks, IDT and CFSB, also provided regulatory constraints, requiring extensive documentation to get sign off. We managed to reach an agreement for most UX; aside from one blocker, we couldn't allow money transfers via payment links.
The Kids are Alright
Following agreement of deliverables and extensive research into key players' like Revolut, Monzo, Starling, and Paypal's logic and UX journeys, we quickly mapped out and prototyped each flow in Figma.
We then organised a round of moderated usability testing with 5 teenagers as participants, using lookback to document the testing.
Our tested assumptions:
- Participant can discover and successfully set up the payments feature.
- Participant can send a payment.
- Participant can send a payment request to a GoHenry user.
- Participant can send a payment request to a non-GoHenry user.
All participants completed the tasks without problems, successfully validating our assumptions and allowing us to implement our designs.
If You Do This, I'll Cancel
While our teen tests were positive, a survey we sent out receiving 600 responses revealed parents didn't feel the same way; we found:
- 44% said they would cancel their account if we introduced the feature, primarily out of bullying concerns.
- A large percentage wanted to be able to authorise the transactions.
We chose to send push notifications to the parent whenever a payment or request is sent, allowing them to intervene by either cancelling or declining on behalf of the child.
We built and tested this solution to see if parents could perform the tasks and gauge their reactions.
Our tested assumptions:
- Participant can review a sent payment
- Participant can review and cancel a payment request their child has sent
- Participant can review and decline a payment request their child received
3 Kinds of Parents
The testing revealed a few key insights, mainly that there are three types of parent segments, these include:
- The carer parent: Their child typically has some form of learning disability. They need to control their child's spending to mitigate risk.
- The moderation parent: They're quite relaxed, but slightly concerned towards their child's safety.
- The super-chill parent: They're overly relaxed, happy to let their child go shopping with friends and spend their money however they wish.
The measures worked for the latter two segments; however, they were insufficient for the carer parent. Together, we agreed the most uncomplicated solution without increasing scope would be to allow the ability to toggle-turn off the feature. However, we hid it in the child's settings menu to prevent parents from turning it off immediately.
Make it Beta
Once we finalised the designs, we released the feature as a Beta, testing it for a total of seven months to both mitigate risk and understand its usage.
We started with 1200 beta testers, slowly working our way to 30,000 before releasing to all our users. Using Mixpanel and Metabase, we built dashboards to track feature analytics each week, seeking areas for improvement, we discovered 3 key insights:
- Only 40% of our beta group set up the payments feature due to poor discoverability
- 60% of teen selected not to sync their contacts
- 60% of requests sent to parents expired each week, as a result of poor discoverability
We looked to improve these three insights and measure their success.
Fix 1 - Improved Feature Discoverability
By switching the payments feature CTA with the sort code and account number lozenge we saw a 40% increase in feature set up and usage.
Fix 2 - Improved Contact Sync Copy
We updated the copy on the payments dashboard contact sync empty state screen, by playing more on syncing your contacts to find out which of your friends are on GoHenry rather than making it all about the practicality of contact syncing.
This change resulted in a 20% increase in contact syncs.
Fix 3 - Improved Parent Requests
By implementing payment request tiles on the homescreen, parents are able to immediately see upon login if their child has requested money from them.
The new design reduced the number of requests sent to parents from expiring by 20%.
As this case study is live, observation and incremental design changes will continue to be made, key focus areas for improvement include:
- Implementing request tiles into the teen app experience to reduce the WoW (week on week) request expiry rates, which average at 40% for siblings and 35% for peers.
- Trying to understand and further reduce the 20% WoW request decline rates from parents.