Overview
Helping mid-market and large corporate clients process multiple payments with different payment method simultaneously
Stage 1
PROJECT DETAILS
Problem Statement
Many large corporations find corporate banking software inefficient and complex.
The banking industry is increasingly integrating digital currencies, necessitating fast and efficient processing of transactions and money transfers across accounts.
Many large corporations, known as multi-legal entities (MLEs), manage multiple businesses and conduct high-volume foreign currency transactions daily across international borders. However, the top five banks in Canada either lack the comprehensive banking features required to meet their complex needs or provide a cumbersome user experience. As a result, many of these corporations turn to third-party banking platforms, such as QuickBooks, which offer automation for much of the process.
As we aim to expand our client base, it is crucial to enhance the efficiency of business banking processes while remaining competitive within the industry. By understanding what clients seek from banks and the value they derive from third-party banking software, we can better meet their needs.
HIGH LEVEL TIMELINE
Create an MVP within 12 weeks
KEY GOAL
Create a MVP payment solution that helps multi-legal entities (MLEs) process multiple payments with various payment methods simultaneouly.
Target Audience
Mid-market to large corporations with complex account structures and file-based payments.
We chose to focus on mid-market and large corporations to retain the single payment functionality that our existing users rely on.
Mid-market clients share similar needs with both small businesses and large corporate clients. While they handle single payments and transfers daily, they also frequently use file-based payment systems for payroll and transactions involving multiple businesses.
Large corporations represent a new client segment we aim to attract. These organizations conduct high volumes of foreign currency transactions, wire transfers, Interac e-Transfers, and ACH payments on a daily basis. With numerous payees and various payment types, their transactions often require longer processing times or higher approval limits.
TARGET AUDIENCE
-
Mid-market businesses
-
Large corporations with automated payment processes
-
Multi-legal entities with foreign currency accounts
Role and Responsibilities
The Payment Order project was a business banking project that allowed me to be a Senior Product Designer.
As a Product Designer, my objective is to develop user-centric solutions that are both data-driven and aligned with project requirements and constraints. To achieve this, I will delve deeply into the problem space, gaining a thorough understanding of users' pain points and needs, and then outline the initial "happy path."
Once this is established, we will collaborate with research, content teams, product partners, and business stakeholders to refine the solution. This ensures that we're designing a Minimum Viable Product (MVP) that effectively addresses our target users' needs and can scale as the product evolves.
RESPONSIBILITIES
-
Collaborating with Design Researchers
-
Working with Product Owners and business stakeholders
-
Interaction/Visual Design
-
Working with Content Designers
-
Prototyping and demoing to product team
Scope and Constraints
Before starting the process, we used our research and client feedback to help shape the scope of the payment order project
We conducted an in-depth analysis of the current single payment and transfer experience to identify missing capabilities and determine which features would deliver the most value in an MVP. While exploring these product gaps, we carefully considered technical, business, and user constraints that could impact our ability to build a fully optimized feature.
Technical Constraints
-
Developer capabilities
-
Load time for large data sets (payee and account information)
-
Account Security (processing large amounts and payment approvals)
-
How would it scale for mobile?
-
What existing user permissions need to be considered? (Doers, Approvers, Self-Approvers)
-
Cloud service (microservices) to limit service disruptions
-
Security risk for accepting user payment files
Business Constraints
-
Budget
-
Project timelines
-
Resources
-
Available payment methods (foreign currency, upload payment files)
-
Competition? Canadian banks, international banks
Target User Constraints
-
Users will need to relearn a new payment process
-
Users need to have access to banking on mobile
-
Informative help resources for self-serve
-
File requirements
The Process
Week 1-3
Collect Research
-
Look at primary and secondary research
-
Conduct interviews with target users on current product
-
Competitor Analysis to see trends/standards
Week 4-6
Synthesize Research
-
Create proto-personas
-
Feature mapping
-
Organize insights into common themes
-
Present findings to product partners
Week 7
Userflows
-
Create happy path
-
Sketch out low-fi wireframes
-
Identify additional usecases to design for
-
Stress test the design on mobile and desktop
Week 8-12
Design + Prototype
-
Prototype
-
Conduct user testing
-
Iterate on feedback
-
Present to stakeholders
-
Prepare design files for development
Stage 2
RESEARCH
Product Analysis: Current State
The product analysis was done on the current state to uncover user pain points and scalable MVP features.
Understanding your users is key to creating a successful product. By taking the time to analyze how people interact with your product, you can really get to know their frustrations, what they enjoy, and what they need. This insight allows you to design with empathy, making sure your product solves real problems and fits seamlessly into their lives.
Market Competitor Analysis
The market analysis found that ABC Financial was lacking many common features compared to many other banks in the industry.
Doing a market competitor analysis gives designers valuable insights into market trends, user expectations, and opportunities for differentiation, helping them design better products that meet user needs and offer a competitive edge.
The insights I was looking for in this market competitor analysis included:
-
understanding banking industry trends and standards
-
identifying the existing strengths and weaknesses in ABC's product
-
benchmarking ABC's banking user experience against competitors
-
getting inspiration from other banking platforms
-
understanding user expectations and preferences
-
avoiding addressing downfalls in the product
-
strategic differentiation in the business banking industry
Research Plan
To understand the problem space and users, we analyzed primary and secondary research and interviewed 3 target users.
Our primary research involved gathering client feedback from our business banking platform and analyzing daily customer service calls. For secondary research, we leveraged iSky Research to examine competitors' bulk payment functionalities.
While our customer feedback primarily came from small and medium-sized business clients using two business banking platforms to complete their tasks, this input was still valuable. Although our target audience includes medium to large business clients, understanding the gaps in functionality for small business users allowed us to enhance their overall experience.
Our secondary research compiled insights on business banking trends and competitor offerings, helping us identify areas where our product was falling short and highlighting features that could provide significant value.
Secondary Research Findings
Payment templates
25% of clients save ACH templates to process recurring payments (payroll, bill payments) vs. manual entry
Foreign currency offering
Large corporation use wire payments to process currencies other than USD and CAD
Uploading payment files
Clients use accounting softwares to produce bulk payment files
Approving single payments
Sometimes individual payment approvals and statuses are required for bulk payments
Manual entry vs. automation
Clients risk inputting incorrect payment details vs. pre-filling saved data
Interview Insights Themes
After synthesizing our primary and secondary research, we categorized them into motivations, pain points and behaviours.
Creating themes from research findings is a crucial step in the UX design process that helps organize insights, prioritize user needs, and guide design decisions, ultimately leading to more effective and user-centered products.
Theming helps to categorize and synthesize qualitative data, making it easier to identify patterns, trends, and insights. This organization allows designers to make sense of complex information gathered during research.
Themes are also easier to understand among team members and stakeholders. Presenting findings through themes makes it easier to communicate user insights and the rationale behind design choices, facilitating collaboration and buy-in. By doing this we look to influence the product strategy and vision by providing valuable insights that inform not only design decisions but also broader business decisions, helping to align product offerings with market demands.
Motivation: TIME
Able to process payments quickly with the use of uploading bulk payment files, adding single payments, and prefilling payee details
Behaviour: DETAIL DRIVEN
A lot of the users that would use this payment order feature work with large spreadsheets on a daily basis. They're used to viewing large data sets and reviewing transaction history on large screens
Pain Points: SCANNABILITY
When reviewing payment details before and after submitting payments, users preferred seeing everything in a table format vs. individual cards
Pain Points: SECURITY
Having specific permissions per user to limit the visibility of certain accounts, transactions, and user actions (edit, delete, add payees)
SYNTHESIZE RESEARCH:
Proto-Personas
I created 3 proto-personas that were existing in ABC's Financial experience. They included Doers, Approvers, and Self-Approvers.
Proto-personas are valuable tools for designers as they include quick insights, guide the design process, enhance communication, and promote empathy for users. While they are not a substitute for detailed personas developed from our research, proto-personas can effectively inform design decisions in the early stages of the design process.
In this project, we created proto-personas that we needed to design for in ABC's product. Each persona has their own tasks and user permissions that helps to reduce access to bank accounts or sending payments. By creating these personas, we were able to map out the happy paths for each persona, taking into the access levels each one would have. Doers aren't able to complete payments or have full access to bank accounts as a self-approver.
Stage 3
IDEATION
Task Flow
My task flow aimed to enhance the presentation of large data sets within the payment experience. I explored ways to display different payment statuses, currencies, and payment details for multiple payment methods.
Next, we needed to develop a streamlined bulk payment flow that maintains a consistent appearance across all payment methods. Our objective is to create an efficient experience that enhances human-computer interaction throughout the bulk payment process.
Bulk payments often involve various payment methods and foreign currencies, adding complexity to the process of entering payment details for each method, retrieving live or indicative foreign currency rates for international transactions, and managing approval statuses, if necessary. For instance, if a user utilizes multiple payment methods, the processing times will vary. Therefore, we must inform users about which payments have already been sent, which are still in progress, and which have failed.
Given these complexities, we decided to take a step back and gather all relevant data points that need to be entered or displayed for each payment on a summary page. Our aim is to avoid creating confusion for users while ensuring that we provide all necessary information to assist them during reporting.
Stage 4
WIREFRAMES
Mid Fidelity Screens: V1
To confirm the technical feasibility and roadmap capacity needed, we created a mid-fidelity flow to showcase the payment order concept to stakeholders. We also used this prototype for user testing.
I began developing my first mid-fidelity version based on the low-fidelity wireframe sketches I had created. Once those screens were finalized, we built a prototype to demonstrate the experience to VPs, Product Owners, and Technical Team Leads. This demonstration helped them gauge the build time required and understand the features we were implementing based on client feedback and research insights.
During the stakeholder demos, they were particularly impressed with the scalability of displaying essential payment details while also providing access to additional information in a full-page view. We were also able to incorporate features that addressed the challenges of handling foreign currency payments, which had been a significant pain point for international clients. The ability to view live market rates for foreign currencies proved to be a compelling selling point for larger clients.
For user testing, our user researcher concentrated on user behavior, navigation, pain points, and task completion. Once all testing sessions were concluded, they synthesized the feedback and assessed which changes would be most feasible and impactful to implement, considering the timeline, available resources, and buy-in from the product team.
Mid Fidelity Screens: V2
We took the feedback from our user research and stakeholders and created another iteration that addressed their pain points and concerns.
Based on the feedback from the V1 prototype, we recognized the need to enhance the UI layout, improve the summary page, and reduce the number of data points displayed in the default state.
To address this feedback, we primarily focused on integrating a responsive table and exploring multi-page flows to create a clear distinction between adding a payment and reviewing a payment before submission. This approach allowed users to concentrate on entering the correct payment details without being distracted by previously added payments. The table component displayed consistent data points across various payment methods, including the payee name, amount, destination account information, and estimated payment date. Our researcher noted that using a table instead of cards would facilitate easier scanning of large data sets for users.
We presented the table and the new multi-page flow to our product partners, and it was well received. They appreciated the use of common components, which streamlined front-end development, and recognized that the simplified payment process eliminated the need for users to scroll through a lengthy page when managing 10 or more payments in a payment order.
Next Steps
This project served as a benchmark for several other payment processes that ABC Financial aimed to enhance. The research insights, common components, and knowledge of foreign currency gained from this project were instrumental in developing the account transfers, wire templates, and summary page experience. The payment order functionality remains a work in progress as we have redirected our priorities toward the HSBC Canada acquisition effort.
KEY LEARNINGS
STAYING AGILE
Throughout the design process, I had to pivot more than once in response to additional project requirements, reduced scope, or how the design would scale for future design patterns.
There will be times where the user feedback we plan to address and design for cannot be prioritized over roadmap timelines, technical restrictions or legal requirements. Being focused on designing a product should be the goal and not satisfying personal design preferences.