Role: Product Design role. Establishing the need for the feature, early stage ideation through to feature shipping on iOS, Android and the Webapp.
We noticed that accounts were being used for many smaller day to day spending but not for larger periodic payments. This was due to inability to schedule a periodic payment and therefore users weren’t using the product as their sole account. Investigating this further, we realised that our users, frequently requested Direct Debit and Standing Orders to help take the pressure off remembering to make payments on a regular basis and generally have better control on their disposable income. This offered us the opportunity to relook how payments were made in the first place and also apply some resource to a section of the product that was being neglected.
Solution
We decided to give the payments journey an overhaul, integrating Direct Debit and Standing Order functionality. Understanding how our users were currently using the feature, we saw an opportunity to make the product more sociable with peer to peer payments, thereby increasing engagement and overall MOM transactions.
We also realised that there wasn’t always clarity about the differences between Direct Debit, Standing Orders and Recurring Payments. Creating clear distinction between these and providing controls to update them meant our users would be in a better place to manage their finances
Outcome
Two variations were tested and the outcome was a hybrid version of the two. We tested ease of use, and understanding of payment functions.
I started this process by breaking down the functions on a granular level. Understanding the mechanisms involved allowed us to be more deliberate in our ideation and determining feature requirements. Some key understandings were things like:
What is a Direct Debit, Standing Order and Recurring Payment?
• A Direct Debit is a payment instruction made by you to the financial institution with which you hold an account, authorising the merchant to collect payment from your account.
• A Standing Order is an instruction to your bank to make payments to a person or organisation, whereas a Direct Debit is an authorisation for a person or organisation to take payments from your account when they are due.
• A recurring card payment – often referred to as a “Continuous Payment Authority” (CPA), is an authorisation provided by the customer that permits you, as the merchant, to take payments from them by either debit or credit card. These payments can vary in frequency and amount and will remain in force until the customer cancels the arrangement.
What are they used for?
• Standing orders are used for regular, fixed payments such as rent or regular payments into a savings account for example
• Direct Debits on the other hand are regular payments of variable or fixed amounts such as mortgage payments, utility bills or your phone bill
• Recurring Card Payments, used more for subscription and membership services – Spotify, Amazon Prime, Audible etc.
Why set one up? What are the benefits over traditional payments?
• Spread the cost of a purchase over a period of time you agree with the merchant
• Have peace of mind as Direct Debits are guaranteed against payment errors
• Save time because once set, a Direct Debits runs automatically until the end of the contract
• Potentially save money, incentivised schemes
• Peace of mind
How does a user set up a Direct Debit?
1️⃣ Contact the organisation you wish to pay. They’ll arrange for you to complete a Direct Debit Instruction by post, over the phone or online.
2️⃣ Complete the Direct Debit Instruction providing personal details. The organisation will update its payment records and forward the instruction onto your bank or building society. They’ll then collect the agreed amounts on the agreed dates.
3️⃣ Check the advance notice details, the organisation will give you advance notice of collection dates and amounts.
4️⃣ Relax. Apart from making sure you’ve enough money in your account when payment is due, there’s nothing more you have to do. Just keep an eye on your bank statement to check that the Direct Debits are being made as agreed.
How does a user cancel a Direct Debit?
1️⃣ Simply contact your bank or building society. If this is by phone or internet, written confirmation may be required. Recommended to notify the organisation concerned as well.
What opportunities are there that could benefit our users?
1️⃣ There is less control with recurring card payments, usually a trial sign up with no reminder of the follow on. Providing calendar reminders or notifications of continued recurring card payments would be very beneficial.
2️⃣ Student discount offers.
Mockups & Future Features
Creating a list of user stories and challenging assumptions, helped form a hypothesis for the feature requirements, and determined what to validate during usability and testing studies. It was important to also consider the business objectives and this continually evolved throughout the design phase and through to possible future feature iterations.
Mockups
Future features
Revamp of payment category icons
Webapp
Case study - Declined payments
Informing customers of declined transactions
Role: Identify the extent of the problem, and create user journeys to assist with self help. Touching on each process through the product design cycle.
Problem
Our users were often in a position where they’d have transactions declined. This could be for any number of reasons but we didn’t have the functionality to inform the user, letting them know why the transaction was declined and secondly, a means on how best to correct this. The result was Customer Ops getting inundated with decline related queries so the key metric with this feature was reducing the amount of queries reaching Customer Ops.
Solution
The simple solution was too indicate a declined transaction, providing the user with clear reasoning. This would be in the form of a push notification and indicated in the transaction list.
Outcome
By understanding all the possible decline reasons and create groupings where possible, we were able to be more specific and direct with our messaging as well as offer tailored journeys to allow the user to resolve the issue themselves with preventative actions.
While operating with limited access to users and user data, the following approach was carried out to define the problem, starting with some key questions:
Who does the problem affect, who id driving this requirement? (i.e specific groups, organisations, customers)
• Customers and Customer Operations
• Every user is potentially a primary user, those with less financial control might be impacted more, therefore more in need of this improvement.
• Users that are left confused by declined/refunded payments. Users not being able to identify these payments and Customer Ops having to handle these user requests.
What are the boundaries of the problem? (i.e organisational, work flow, geographic, customer, segments)
• When a transaction is declined – users don’t know when a transaction is declined, as we don’t show it as a push or in the transaction list
• We don’t indicate why a transaction was declined – as we don’t show declines in the transaction list, there’s no way for the user to know why it was declined
• Difficult conversations – customer ops receive difficult conversations on Intercom about declined transactions from perplexed and confused users
• A user has either lost or had their card, wallet stolen
What is the ultimate goal/impact?
• Improve Trust – improve user trust by showing granular detail about all of their transaction states
• Decrease conversations on Intercom
• How can we enhance the experience, can we offer solutions that provide better UX
• Can we implement prompts to avoid the issue in the first place?
Understanding this allowed me to identify which persona would most likely benefit from these improvements. Knowing this was important to understand if the other ideas around self help would in fact be beneficial and what would be the best way communicate these messages.
Nathan was the primary persona for this feature, outlined by the following user scenario.
Nathan lacks forward planning and keeping track finances. He’s often over-spending due to getting carried away with contactless payments. Nathan is young, studying, on tighter budget and more of a socialite and therefore tends to be more likely to have a transactions declined.
To help form the feature requirements, we created a list of user stories based on current knowledge that we know to be correct and derived some assumptions to validate during early ideation, user flow development and testing sessions. This looked something like:
Customer user stories: As a user…
• I want to see declined transactions in real time.
• I want to know why the transaction was declined.
Customer Operations user stories: As a Customer Support agent…
• I want to easily see the transaction’s decline reason
• I want to spend less time talking to users on why their transaction was declined
Business Analyst user stories: As a Business Analyst…
• We want to be empowered to understand declined transaction numbers
• We want to understand the reasons why transactions are being declined
• We want to inform further decisions based on the above
Userflows and Mockups
Userflow illustrating the various declined scenarios
Key decline scenarios
