NADIA SHIWPRASAD
Overview
Helping mid-market and large corporations add, edit and delete business payees in their banking profile
Stage 1
PROJECT DETAILS
Problem Statement
Managing hundreds of payees on a daily basis can be tedious and time consuming.
The current version of the business banking payee management tool was designed exclusively for small businesses. These clients typically handle manual entry and generally do not need to manage more than 20 payees with complex information.
When this version was initially developed, there was limited time for user testing, market research, or journey mapping across different payment methods. After launching this design for banking users, we received negative feedback regarding the efficiency of the task flow, terminology, and overall UI design.
As the business banking strategy shifts to accommodate mid-market and corporate clients, the reliance on manual entry increases the potential for human error and user frustration. These clients depend on uploading payee Excel sheets generated by their accounting software and require the ability to review and edit complex payee details in just a few steps.
HIGH LEVEL TIMELINE
Create an MVP within 16 weeks
KEY GOAL
Create a MVP payee management solution that helps multi-legal entities (MLEs) add, edit and delete payees with various payment methods quick and easily
Target Audience
Mid-market to large corporations making payments to 50+ payees on a daily basis
We chose to focus on mid-market and large corporations due to the client types we were designing for during the bank acquisition. Mid-market clients share some similarities with small business users, particularly in their reliance on manual entry.
As we began examining the features these clients utilized at their current banks, we discovered they employed payee approval rules, permissions, international payment methods, recurring payments, and payment templates. Some of these features were entirely new to us, necessitating an in-depth analysis of the gaps between our current design and what we could feasibly deliver within the 16-week timeframe.
TARGET AUDIENCE
-
Mid-market businesses
-
Large corporations with various payees and payment methods
-
Multi-legal entities with various permissions and access requirements
Role and Responsibilities
The payee 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 our 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 researchers
-
Working with product owners and business analysts
-
Creating the interaction and visual design
-
Reviewing content with content designer
-
Prototyping and demoing to product, legal, and go-to market teams
Scope and Constraints
Before starting the process, we conducted research and gathered existing client feedback to help shape the scope of the payee management project
We analyzed the current manage / add payee experience to see which capabilities were missing and what features would provide the most value in an MVP.
Technical Constraints
-
Developer capabilities
-
Load time for large data sets (payee status and information)
-
Payee Security (Verifying payee details for risk/fraud)
-
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 third-party files
Business Constraints
-
Budget
-
Project timelines (Bank acquisition date)
-
Resources
-
Available payment methods (foreign currency, payment templates)
-
Competition? Will users choose another bank if we can't deliver?
Target User Constraints
-
Users will need to relearn a new payee management solution
-
Users need to have access to banking on mobile
-
Informative help resources for self-serve
-
Viewing large amounts of data on screen
Assumptions
I needed to consider my project assumptions and how risky it was to assume they were true, and if they could be validated.
Assumption 1 | Assumption 2 | Assumption 3 |
|---|---|---|
Users would not use this feature on mobile | Approvals would help mitigate risk of verifying incorrect payee details | Users will leave the bank if we can't provide similar or better features compared to their current functionality |
The Process
Week 1-3
Collect Research
-
Look at primary and secondary research
-
Talk to acquired bank advisors to learn about their features
-
Competitor analysis
Week 4
Research Synthesis
-
Create personas
-
Prioritizing user feedback
-
Feature mapping
Week 5-8
Userflows
-
Create happy path
-
Responsive layouts
Week 9-10
Design, Prototype, Test
-
Hi-fi prototype
-
Conduct user testing
-
Demo concept to stakeholders
Week 10-16
Development
-
Review localhost developer demos
-
Give feedback
-
Make design changes as scope changes
Stage 2
RESEARCH
Market Competitor Analysis
We established most corporate clients used multiple banks to make payments to payees.
As we started to understand corporate bank users, we realized no single bank was able to offer every feature they used to manage their payees or make payments. This causes accountants to use a variety of banking solutions to manage their payees and payments depending on a variety of factors (currency, bank location, available payment methods, cost).
The research team did a comparative analysis of the top 5 banks to see which features corporate clients were used to using and where our current design stood in the market.
Based on the analysis, we were not a market leader for corporate bank users. ABC Financial was lacking in almost all categories related to international payment methods, reporting, and payee verification. This gave us an idea of which features might be useful to include in our MVP.
Research Plan
To understand the problem, we collected primary research through interviews and client feedback and secondary research to review market trends.
Our primary research was a combination of client feedback from our business banking platform and interviews we did with relationship managers belonging to the bank we were acquiring. Our secondary research came from iSky Research as they had product insight from the top Canadian banks in the industry.
By talking to Relationship Managers from the bank we were acquiring, we were able to understand who the clients were and what their individual needs were, while getting insight into the current banking features they offered instead of relying on stress testing their product.
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.
Interview Insights
After speaking with the Relationship Managers, we synthesized the interview insights into themes.
Interview insights can be daunting and easily misinterpreted when viewed out of context. By consolidating our interviews into common themes, this will help us to map out existing gaps in our current product and which features these users would find helpful in the payee management experience.
Secondary Research Findings
To be competitive in the business banking industry, we analyze banking trends
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 expected based on their current banking experience. If we don't offer enough competitive features, we risk the chance of these users moving to another bank.
Payment Templates
Templates were very important at the payee stage vs. make payment stage to help save time doing data entry for each payment
Payee Automation
Users store their payee information in their accounting software for reporting purposes. Being able to export a file vs. adding single payee would save time and reduce errors
Exporting Payees
Having the option to export a list of payees was crucial for reporting purposes
Verifying Payee Details
Having back-end system verification on payee details would help to reduce errors and failed payments
Usertypes
We have 3 usertypes that have different access levels and permissions that we need to consider.
Each usertype has their own set of permissions and access levels. As fraud and risk become more concerning for bigger corporations with large accounting departments, it becomes a requirement to have account restrictions and permission level put in place.
The 3 levels of users we have in the business banking portal include Doers, Approvers and Self-Approvers. Doers and Approvers have more restrictions compared to Self-approvers.
Stage 3
IDEATION
Task Flow
The new task flow was focused on shortening the flow to speed up the add payee process.
After creating the personas and synthesizing our research findings, we focused on creating a streamlined add payee + add payment method experience. Once I started mocking up possible solutions, we realized we could move the payment method selector to the beginning of the flow to reduce the amount of guiding questions. Our research found users were informed on which payment method to choose and didn't value having it at the end of the flow.
We also did a taskflow comparative analysis to see which payment method had the most payment details required so we could break up the task flow into common sections. By doing this, we were able to create a cohesive experience between each payment method so users didn't feel like they were relearning the add payee process because it required different payment details.
The end result was an add payee design that is 50% more efficient than the current design. We acheived this by removing the guiding questions and moving the payment selector to the beginning of the flow.
Here are the add payee pages that work for all payment methods:
1. Payment method selector page
2. Payee name + payment method details page
3. Review page
4. Confirmation page OR Approval page
Stage 4
WIREFRAMES
Concept 1
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 a mid-fidelity version based on our research and project requirements. Once those screens were complete, we created a prototype to demo the experience to VPs, Product Owners and Technical Team Leads. This helped them form an estimated build time so we could create a product roadmap.
During the stakeholder demos, they were impressed with the table design, flow optimization, and simplicity of adding payment details. They did have some reservations regarding account syncing and allowing users to upload third-party files. This would introduce new complexities and security risks that would drastically increase the technical requirements and project scope.
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 looked at which changes were most feasible and impactful to implement based on timeline, resources and product team buy-in.
Payee Detail Page Concepts
As the roadmap became more solidified, the project requirements also continued to change. This affected the current payee detail page and need for a full redesign.
When they originally defined the technical requirements and timeline for the payee project, they wanted to utilize the current state as much as possible to reduce the work effort. We knew this wasn't a scalable solution as we wanted to move away from cards focus on complex data tables to meet user needs.
To meet in the middle, we adjusted the UI design to address some of the client feedback we had, but there were scaling issues with the cards. Once key stakeholders and Relationship Managers started to see the gap in the current state of the payee details page, they realized it didn't scale for payment methods that required large amount of details such as recurring payments and wire payment details.
We then pivoted to a table design that would hold individual payment methods, recurring payments, and payment templates setup for a single payee profile. This would allow them to view anything payee related through a detailed table view.
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.
