Background
Client: Medium size tech bank catering to startup and early stage founders.
Project: Simplify multiple payment flows into one way to move money.
Problem
Currently, there are many access points to move money, they lead to multiple platforms and third parties, each with their own unique payment system and requirements.
Goal
Create a dynamic form that is inclusive of all payment rails and makes it easier for users to move money.
Requirements
After gathering all of the information, subject matter expert knowledge, current pain points, opportunities for education, requirements for integrating third parties, payment rails, platforms, APIs, and other potential technical constraints, I worked to identify the complex dependencies within all of the systems.
Understanding the problem
Then I moved on to understand the problem space. I found out that when a user is moving money, they’ll normally have an invoice in their hands or a spreadsheet open in another window with payment instructions.
I went onto understand what are the other ways people have solved the same or similar problems? Focusing on forms, current trends, as well as a competitive analysis, helped me find examples in the wild that are implementing similar systems. Looking for what works well or what might cross over to this project, then mapping those to test for a fit with our clients and systems.
Ideation / Concepting
Ideation included laying out the different ways we could present the data.
Either, one at a time, similar to pay-pal. Or a more staged approach with chunks at a time, or show all the fields so that clients know what’s necessary and where they’re at.
Testing the Concepts
I used paper prototypes and key stakeholders to test out our concepts, and organize the field interdependencies. And together we co-created a dynamic form that utilizes progressive disclosure as well as transparency to set clear expectations.
Dynamic Implementation
At the very top of the form is the option to select a template, or a saved payment, so users have the option to circumvent the following fields for regular payments.
When a user logs into online banking, they first view their accounts, I took advantage of this priming to build our client’s confidence by beginning the form with the “From” field. The next open field is often a well-known payee, the “To” field, as well as the option to enter in a new payee information.
From there the focus moves to payment currency or an amount based on the payee bank data previously entered. For example, if a payee had entered a sort code, then payee would only be eligible for UK domestic payments and the payment currency would default to GBP and the focus would proceed to the amount field.
We then continue to dynamically the fields to help limit the cognitive load and necessary decision making. Based on the payee bank information, and which account has been selected, we will know what kind of payments are possible to make. For instance, if a payee’s IBAN provided was SEPA eligible then our user could send a SEPA Credit Transfer to the payee.
The send on date is closely tied to the time of initiation and when the processing time for the payment rail type. Across the many different payment rails, there are a bunch of use cases to cover within the form.
Take Aways
The toughest part of the process was remembering all of the details of each use case and the requirements for sending money on each of the payment rails, then accounting for room to scale to the US. There was a lot of logic but creating maps helped guide me and group the fields. From this process, I take away that the index cards helped for thinking of creative groups and the stickies helped to better visualize the downstream processes.
Jess Moore 