Scheduled Payments

The Project

As part of an ongoing personalisation initiative, we selected Scheduled Payments as a new feature. The idea was simple and by no means original, we would combine standing orders and direct debits into one central view, making it easier for customers to find and use in app. We used this opportunity to introduce an amount total for customers to see, knowing from user studies that customers found it time-consuming to total up their outgoing ‘bills’ and keep on track of it.

For this reason we introduced the following:

• clear monthly balance
  
• timely reminders to top up account, if customers are at risk of entering their uanrranged overdraft
  
• uplifted payment lists for standing orders and direct debits
• new chronological categories, grouping outgoing payments by whether they’re due today, this month, or next month
  

Every project has them unfortunately, and this one didn’t pass through unscathed. Scheduled Payments was hindered by a handful of technical constraints, unfortunately missed in initial impact assessments:

Unable to predict the frequency of direct debit payments
This one was quite frustrating, as the chronological view of payments did test well with our users, but was reliant upon determining how often these payments would be made

Balance after bills warning logic
This had to be blacklisted shortly after going live, as this thoroughly irritated many of our customers. The ‘top up’ warning displayed whenever the customer’s balance ran low, even if they had no upcoming bills.

Days left countdown
Now we did predict this one would be unpopular, as it isn’t fair to assume everyone’s pay cycle follows the 1st of the month, but we had planned in phase 2 for an additional feature to set a payday to follow. Phase 3 would have also introduced custom categories to better help customers make the app their own. Unfortunately phases 2 and 3 are on hold indefinitely. 


Many of these issues we have devised a UI fix for, until our dependencies are resolved and the next phase of build can begin.

Another issue was largely UX-related and surfaced after the feature went live; the assumption that most of our customer’s direct debits are monthly. Though the UI accounted for this scenario, the logic for the balance after bills only accounted for a monthly forecast. All direct debits and standing orders, regardless of their frequency, would be shown and get totted up in the final total. This was deeply frustrating for customers who had quarterly or annual scheduled payments, as this new feature disrupted their budgeting and gave them an untrue outgoing figure.