Payment
Flow
Overview
Redesigning the payment flow was my first project after onboarding to Banking Circle. It was a great project to learn about the complexities of the financial industry. The payment flow had a complicated history with many different opinions, so it represented a challenge in stakeholder management. Banking Circle is at its core a payments processing company, so the payment flow is the primary user flow on its platform.
Role
Senior UX
Specialist
UX Research
User flows
UX & UI Design
User Testing
Time
Jan-Mar
2022
3 Month project
Team
Andreea (PO)
Paul (Frontend dev)
Flow analysis
I started my task by mapping the flow and exploring all the possible scenarios around the payment flow. Pinpointing all the steps the users take in the flow helped me understand further our product, and start identifying some friction points.
Discovery workshop
Being a new designer in a new organization and industry, I knew I needed to gather as much feedback as possible. I was aware that my coworkers possessed a great amount of knowledge in this area, including insights into the main issues with the flow and what our user’s liked and disliked about it.
I organized a workshop to which I invited Mikkel (Head of Product), Andreea, Giuditta, Niklas (Product Owners), and Erinn (Client services).
The workshop aimed to gather as many insights as possible into the payment flow and our user’s experiences with it.
The workshop consisted of two parts, homework and an in-person session to share the homework results, an open discussion, and a team alignment on what areas of the flow we should focus on for the redesign.
For the homework, I shared a Figjam page with every participant with my diagram of the user flow and asked them to add comments to the areas of the flow where they considered our user’s had some struggles.
During the session, each participant presented their homework and we had some time for questions and comments.
After that, we had an open discussion and decided on what problems we wanted to focus on.
Findings
The workshop was very successful and helped us discover many pain points in the flow, here are the most important ones, divided into the stages of the flow:
Pre-payment:
The system does not consider the user context, making every payment experience the same, where some flows can be optimized based on context.
There is only one button and one form for all types of payments. This makes the payment flow overly complicated for some flows and it also confuses users looking for other flows, that do not expect them to be merged into one.
During payment:
Labels in the form are too technical and inconsistent.
Selecting accounts is complicated, the user only has the IBAN and currency of an account, and this information is not enough for some users.
Saving new recipients is not possible in the payment flow. Users can add all the details and make payments to new recipients, but the flow does not offer the option of saving them for future use.
Inputting amount quantities can be frustrating, the user needs to select both the amount and currency to send. This process is complicated and can lead to user errors.
Post-payment:
The system gives no receipt of an initiated payment, our users are currently taking screenshots to send to recipients of their payments.
There is no feedback at the end of a payment, the user can be confused if the payment was initiated or not.
Ideation workshop
After our discovery workshop, I brought the same group together intending now to gather their ideas on how to fix the issues we had uncovered.
To prepare for this workshop, I gathered some extra data on the most common flows our users took before and after making a payment and also what were the most common errors our users encountered when filling up the payment form.
I also broke down the user flow into its three main stages (pre-payment, during payment, and post-payment) and grouped all of our discovered problems into each of these sections.
The workshop consisted of an open brainstorming session, where we spent a few minutes on each problem and produced as many ideas as we could on how to solve them.
Refinement
The next step was to review all the generated ideas with Andreea (dedicated PO for payments), this was another great step for my learning. As with Andreea’s knowledge of payments and our engineering capabilities it was easy to discard ideas that were not feasible and just concentrate on the ones that would provide the most value to our users. After our session these were the ideas we decided to focus on:
Separate and more specific flows
Easier selection of accounts
Adding new recipients inside the payment flow
Provide better feedback to the user
Utilize the context to aid users
First iteration
The first thing I worked on was defining the new user flow, which aimed to solve three of our five user needs.
The first user need to solve was on simplifying the payment flow, we agreed that the payment form today was trying to solve for all types of payments possible in our platform, making the flow unnecessarily complex for the more common simple payments. So we divided the flow into three different forms, one for internal transfers, one for outgoing payments, and one for recurring payments.
The second was to utilize the user context to help with an easier payment flow. This consisted of making a few small assumptions, that will be validated with data tracking once the feature goes live. For example, if a user starts a payment from inside a specific bank account page, then the field for the sender's bank account should be pre-filled with that same bank account. The tracking will let us know if the users are changing this into another account, but in case the assumption is correct we would be saving our users one step in their payment flow.
The third issue we wanted to fix with the flow was adding new recipients, in the original flow it was not possible to save the new recipients, user’s needed to go through a separate flow to do this. In the new flow, we merged these two flows so that users could add a new recipient while making a new payment.
Once the new user flow was defined I started to mockup screens in Figma to all the steps in the flow. The user needs the new design needed to solve were:
First, provide an easier way to select bank accounts, to do this I designed a new component (that was added to our design system), the new component was a more robust dropdown selector that included more information on the accounts (short description, owner, and balance).
The second need we solved with the design was the need for better feedback, this area was a low-hanging fruit as the current design offered no feedback at all after a user completed the payment, so with the addition of one last step showing confirmation that the payment had been initiated successfully this was fixed.
Internal user testing
Once the screens were ready, I prepared an interactive prototype to start doing some internal testing. Because the flow is very common, most of us have made some kind of payment or transaction using our online banking. I decided we could gather good feedback without needing to reach out to our users. I drove a few feedback sessions with stakeholders and different team members, where I received some good feedback.
However, the best feedback came from the opportunity I got to test the flow in a team offsite, where I organized a guerilla usability test with around 18 different participants from our product organization.
Findings
The feedback was positive, especially around the five user needs we were focusing on fixing, but we did get a good finding for our next iteration.
Aiming at simplification, we placed the notes section of the payment behind a toggle button, assuming that not all users will need to add notes. During the testing, we learned that this was the wrong assumption, in professional (B2B) payments notes are super important, almost all users will need them, and having them behind a toggle button just added an extra step into the flow.
Second iteration
The second iteration included several fixes corresponding to the gathered feedback, including the change to the notes section.
Implementation and next steps
For the implementation, we agreed on doing it by iterations. So we divided the changes into stages and started deploying those as soon as they were ready. Making sure to keep the communication with users open to hearing their feedback on the changes coming to them.
The first change implemented was the new account selector, after talking to 5 different users we validated that it was a positive change as they all agreed that it was making their jobs easier.