NADIA WESTON
Overview
Helping small and mid-market clients process multiple payments with different payment method simultaneously
Tools Used
Stage 1
PROJECT DETAILS
Problem Statement
Many large corporations find corporate banking software inefficient and complex.
The banking industry is increasingly adopting digital currency, which requires transactions and money transfers between accounts to be processed quickly and efficiently.
Many large corporations that own multiple businesses are known as multi-legal entities (MLEs). These corporations carry out foreign currency and large transactions on a daily basis across international borders. However, these activities have become a hindrance to the Canadian banking industry, as MLE clients have to use third-party accounting software or multiple banking platforms to complete these tasks.
Business banking also gets complex when it comes to tracking multiple payments or transactions for internal approvals, and bank payment processing times.
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 automated processes and file-based payments.
We decided to focus on the mid-market and large corporations because we didn't want to remove the single payments functionality our current users were using.
Mid-market clients have similar needs as our small business and large corporate clients. They process single payments and transfers daily but use file-based payments for payroll and paying multiple businesses.
Large corporations are new clients the bank wants to attract. They're known for using foreign currencies, making wires, Interac e-transfers, and ACH payments in large quantities daily. They also have many payees accepting various payment types that might involve longer processing times or increased 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 become a Senior Product Designer.
As a Product Designer, my goal is to create a user-centric solution that's data-driven and feasible based on project requirements and constraints. To do this, I'll need to dig deeper into the problem space, understand my users' pain points and needs, then map out the initial happy path.
Once that's complete, we'll need to circulate this happy path with research, content, our product partners, and business to ensure we're designing an MVP that solves our target user's needs and can be scaled in future.
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 analyzed the current single payment and transfer experience to see which capabilities were missing and what features would provide the most value as an MVP.
Technical Constraints
-
Developer capabilities
-
Load time for large data sets (payee and account information)
-
Payment Security (processing large amounts and payment approvals)
-
Should it be for desktop or mobile? Both?
-
Creating responsive tables for mobile and desktop
-
Cloud service (microservices) to limit service disruptions
-
Risk of 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
Week 4-6
Week 7
COLLECT RESEARCH
.png)
-
Look at primary and secondary research
-
Conduct interviews with target users
-
Competitor Analysis
SYNTHESIZE RESEARCH
USERFLOWS
-
Create personas
-
Feature mapping
-
Create happy path
-
Sketch out low-fi wireframes
-
Stress test the design on mobile and desktop
Week 8-10
DESIGN + PROTOTYPE
-
Mid and Hi-Fi Prototype
-
Conduct 3 Rounds of Usability Testing
-
Presentations with stakeholders
-
Handoff to developement and QA front-end progress during sprint demos
Stage 2
RESEARCH
Market Competitor Analysis
Since I established most Corporate clients use multiple banks to make payments, I did a quick analysis of the top banks in Canada to see where ABC Financial Institution was lacking.
Research Plan
To understand the problem space and users, we analyzed primary and secondary research and interviewed 3 target users.
Our primary research was a combination of client feedback from our business banking platform and customer service calls we received daily. We used iSky Research for our secondary research to study our competitor's bulk payment functionality.
All our customer feedback and calls were from small and medium business clients who used 2 business banking platforms to complete their business banking tasks. Although we were targeting medium to large business clients, it was useful to see what current functionality small business clients were missing to improve their experience.
Our secondary research was a compilation of business banking trends and competitor functionality to see where our product was lacking and what features would be valuable.
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
After synthesizing our primary and secondary research, we categorized them into motivations, pain points and behaviours.
While analyzing our primary research findings, we grouped them into motivations, pain points and behaviours. This allowed us to see which themes were common among our target users compared to the secondary research I gathered.
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 to help me stay focused on the existing banking user permissions and what features would be available to each usertype.
Each persona had 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 would.
Stage 3
IDEATION
Task Flow
My task flow was focused on improving how we display large sets of data throughout the payment experience. I considered how we could efficiently display various statuses, currencies, and payment details for multiple payments methods.
After creating the personas and synthesizing the user feedback on our single payment experience, we needed to create a streamlined bulk payment experience that would display large data sets on screen. Once I started sketching possible ideas and solutions, I realized my first task flow lacked multiple payment statuses, quoted foreign currency rates, and different payment methods.
Many bulk payments or payment orders include various payment methods and foreign currencies. This introduces the complexity of fetching live foreign currency market rates for foreign exchange and payment approval timeframes (if approval is required). For example, if a user creates a payment and it requires approval, there might be a 2-day waiting period between the indicative rate on the payment creation date vs. the current rate on the day of approval.
I decided to step back and pivot my strategy of prioritizing information displayed directly to clients vs. consolidating it in a separate detailed payment summary.
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 started creating my first mid-fidelity version based on my chosen low-fidelity wireframe sketches. Once those screens were complete, we created a prototype to demo the experience to VPs, Product Owners and Technical Team Leads. This helped them understand how much build time would be required what features we were building based on client feedback we received daily through our feedback tab.
During the stakeholder demos, they were impressed with the scalability of surfacing payment details that were more important, but also making additional details available in a full page view. We were also able to include features that scaled for foreign currency payments that were a pain point of international clients. Being able to see the live market rate for foreign currencies was a big selling point for large clients.
As for user testing, our user researcher focused on user behaviour, navigation, pain points, and task completion. Once all testing sessions were complete, they synthesized the feedback and look at which changes were most feasible and impactful to implement based on timeline, resources and product team buy-in.
Mid Fidelity Screens: V2
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.
