Why a Teen Payments Feature?
GoHenry is one of the most successful kids digital banking apps in the UK, beloved by a community of 2 million parents and kids combined, their goal is to teach kids and teens money skills for life. However, whilst its target age ranges from 6-18, we noticed a dwindle in our teen segment once users turned thirteen.
Through a survey, we found that 60% of our UK teen customers were owed money by a friend on a monthly basis, and in 17% of these cases, teens admitted never getting their money back at all. This was partly down to the fact that GoHenry didn’t allow any transaction aside from parent to child. To solve this and explore ways to make GoHenry more relevant for teens, my team and I began to explore the idea of a payments feature, providing both retention and growth opportunities for the business.
My Role
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.
Scope
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%.
3 Months In
After fixing the key issues discovered in the beta, we felt confident in releasing the feature to 100% of users. 3 months post launch we recorded >100K active users; 5% (5,000) of that user base transacting at least once and 10% (10,000) transacted with their parents, siblings, relatives and grandparents.
The team and I were incredibly happy with these promising results and began to investigate where else we could further impact on the feature, these areas included:
- Implementing request tiles into the teen app experience to reduce the WoW (week on week) request expiry rates, which averaged at 40% for siblings and 35% for peers.
- Allowing parents to change request amounts to counter the 20% WoW request decline rates.
