Role: Lead Product Designer coordinating research and design development of the a new banking and payments platform.
Overview
The “Be a Bank” mission team’s purpose is to build a fully functional current account that encompasses account management, customer ledger and operational accounting integration to NatWest. Moving Mettle from offering a prepaid business account under the PPS e-money licence to offering a full FSCS protected business current account under the NatWest licence.
The Genie ‘product’ or platform is a cloud native, digital banking and payments solution providing: A. access to banking services (ledger, accounts, cards) B. access to payments (banking (e.g.FPS) and card payments) through a B2B API, Banking-as-a-Service (BaaS) offering with a supporting operational interface. Genie is building a banking ledger from scratch and is working with partners to build its payments capabilities.
The Challenge
The product setup was very much initiative lead, with a long list of required functionality, 3rd party integrations, regulatory and compliance necessities, all within very tight deadline requirements. A design presence was also introduced quite late on into the program, meaning there was already substantial tech and design debt to deal with.
The main challenge was changing the course of the product teams to move away from thinking solely about functional build requirements and consider the end user journeys. Understand who the features or functions were being built for, and why and how they would be used.
Buy in from Product Managers, stakeholders and leadership to change course was the first goal. Conducting a comprehensive discovery, identifying all user groups and determine the Jobs To Be Done.
Discovery
Competitor anaylsis
Analysis focused on specific platforms and services currently being used Analysis consisted of:
1️⃣ UI Overview
2️⃣ Heuristic & UX Principle Analysis Specifically investigated screens that relate to reconciliation and settlement journeys
Research & Business Objectives:
Before running any user research we created a research plan that acts as a living document to define the problem(s) and list out our key research and business objectives.
Problem statement: How and why Finance Operations (Fin Ops), Payment Operations (Pay Ops) and Customer Operations (CS Ops) use existing financial ledgers and payment processing platforms and services.
Research Objectives:
• Understand the end-to-end process of how participants are currently performing specific financial and payment platform tasks
• Uncover the different tools and features participants use to make decisions
• Identify any problems or barriers they encounter when trying to make decisions
• Learn about any improvements we could make to their current decision-making and work flow process
Business Objectives:
• Ensure customers’ money is being protected
• Ensure the bank’s money is being protected
• Reduce time (and therefore cost) required to do Finance Ops tasks
• Eliminate / minimise the use of data extracts which could compromise our data security
• Customer loyalty (through delightful user experience, innovation)
What we did
• Conducted one-on-one interviews with 10 participants. all with varied experiences across Finance and Payment • Operations in Natwest and Mettle banks.
• Ran discovery workshops, digging into the how and why of each activity and process.
• Conducting a diary study: Capturing daily tasks, tool and process performed across Mettle.
Current user journey mapping
Outlining the existing user journey’s provide an opportunity to visualise the process and identify the pain points, touch-points and tools required to complete tasks and opportunities to be explored during the design sprint.
High level findings across each domain:
• There are certain tasks that are legal and bank requirements to fulfil statutory reporting needs.
• There are tasks that we need to complete in order to remain a member of the FPS and Mastercard scheme.
• There are tasks that we need to complete so that we can account for the movement of all customer funds, wherever they are held.
• There is a reliance on a lot of NatWest core bank systems that we need to account for when building the best solution.
• There is a lot of reliance on spreadsheets, secured email environments and a clear lack of automation involved.
• There is a lot of overlap with the work completed by Finance Ops and Payment Ops (in particular reconciliations).
• A lot of the tasks completed are initiated as 2nd line support requests from a customer interaction so there is an opportunity to merge the work with the CSO tasks hopefully (based on the discovery work from the CSO interviews).
• There is a lot of reliance on spreadsheets, secured email environments and a clear lack of automation involved.
• There are tasks that we need to complete in order to remain a member of the FPS and Mastercard scheme.
• There are tasks that we need to complete so that we can account for the movement of all customer funds, wherever they are held.
• There is a reliance on a lot of NatWest core bank systems that we need to account for when building the best solution.
• There is a lot of reliance on spreadsheets, secured email environments and a clear lack of automation involved.
• There is a lot of overlap with the work completed by Finance Ops and Payment Ops (in particular reconciliations).
• A lot of the tasks completed are initiated as 2nd line support requests from a customer interaction so there is an opportunity to merge the work with the CSO tasks hopefully (based on the discovery work from the CSO interviews).
• There is a lot of reliance on spreadsheets, secured email environments and a clear lack of automation involved.
Initial user and scenario flow mock ups:
Initial flows and mockups were developed to start wider conversations around the various scenarios we would have to cater for and to determine the ideal journey for a first phase approach to CoP implementation.
Using CoP Operational Guideline and Pay UK documentation as reference we started early discussions with our marketing department to tailor the copy treatment of each scenario message.
Mockup of drawer navigation
Case Study: Information Architecture and Search Navigation
Why: Understanding the Goal
In order for us to solve a customer query, conduct an investigation or analyse specific accounts, Payment, Banking (Finance), Fincrime, CSO operation users need to be able to locate a specific account or specific account details as efficiently and as effectively as possible.
Expecting these users to rely on a search box only, as a solution, isn’t enough in terms of allowing for discoverability of journeys and the system.
Where this might be fine for expert users that know the system, it results in poor experience for novice users. Models for an effective search, considering users’ different behaviors (from novices to experts), is a balanced initiative between specific search and navigation through browsing.
In other words, it’s not just the user groups that need to be considered but also the subset of user types that belong to them.
Expecting these users to rely on a search box only, as a solution, isn’t enough in terms of allowing for discoverability of journeys and the system.
Where this might be fine for expert users that know the system, it results in poor experience for novice users. Models for an effective search, considering users’ different behaviors (from novices to experts), is a balanced initiative between specific search and navigation through browsing.
In other words, it’s not just the user groups that need to be considered but also the subset of user types that belong to them.
Who:
• CSO
• Payops
• Fincrime
Key hypotheses
• Search enables users to specify a word or an ID to find relevant pieces of content without the use of navigation.
• Search will be fundamental in locating an account for specific investigations and analysis.
• Presenting a search function as part of the UI is a far better UX than relying on URL manipulation
• Navigation is very important because it provides users with a view from what they can find and teaches them about the structure of the search space, and what they can search.
• Showing upfront content that they can recognise substantially improves usability because it reduces their cognitive load.
• Using navigation categories is often faster and easier for users than generating a good search query
• Through navigation, we can improve usability by reinforcing one important usability heuristic: Recognition over recall.
• Not all pages and use cases will require direct search functionality at this moment in time.
• Performing certain job types more effectively requires different search / navigation options
Reworked Information Architecture
Value to the business
• We want to reduce the time it takes to solve a customer’s query, analyze and investigate accounts. Being able to locate an account or transaction with a simple search of an account or transaction ID will help achieve this.
• By also providing a hierarchical navigation structure, users will be able to develop an understanding of the system and they wouldn’t need to know precisely the terms of what they’re searching for in order to locate something. Knowing the system will enable users to perform their job better.
• This would cater for all levels of users.
Experiments
• Card sort exercise was conducted.
Internal user tests, with mixed user groups and some participants with existing knowledge of the system, the following observations were made:
• It was quite clear that search only option would not be suitable as the terminology used was not understood by all. A correction of terminology would not necessarily fix this issue.
• A discoverable navigation option would be required for some users to work their way around the system. Closed card sort was more effective than an open card sort.
Landing and navigation example
Mockup of journey progression
Case Study: Account Creation
Why: Understanding the Goal
We needed to create the functionality that allowed for the setup of the banking account structure for Mettle but also ensure the feature could facilitate and be flexible to cover a BaaS solution.
Who:
• Financial Account Operatives
Problem
• There are multiple paths a user could go down to complete account setup. We wanted to create the flexibility to accommodate banking structures outside of Mettle’s requirements.
• We had to consider and work around existing technical constraints within the ledger and account structure.
Solution
After many iterations we settled on a conditional form framework. Common requirements in the accounting setup starts the process and based on a users inputs, they would be taken down individual paths for account creation.
Conditional user journey
Prototype of account creation journey
Mockup of DD mandate view and DDIC drawer
Case Study: Direct Debit Mandate inclusion
Why: Understanding the Goal
Payments Operatives need to be able to raise Direct Debit Indemnity claims within the UI so that they can be submitted to the BACS scheme (via Form3 API) and sent to the originator for processing.
Who:
• Financial Account Operatives
• Customer Support
Problem and process requirements:
• When we go live with Direct Debits, there is a scheme requirement to have a Direct Debit Indemnity Claim (DDIC) process in place, where we could raise a claim under the Direct Debit guarantee scheme on behalf or a customer where it is claimed that a Direct Debit has been incorrectly paid from their account and to reclaim the funds back from the originator.
• Upon establishing a valid claim (which will be determined by CSO and Payments Ops) we need to create a Direct Debit Indemnity claim and submit this to Form3. To create the DDIC submission this requires details from the original payment(s) and additional details to be input by the Payment Ops user.
• The customer then also needs to be credited with the amount being claimed back (this will need to be debited from a dedicated suspense account. Once the DDIC has been submitted, the funds are then returned back from the originator and received into Genie on day 14 days, where Payments Ops will post the journal movements to clear the debit from the suspense account.
• We will need to check that there have not been any previous claims paid out against a transaction to ensure we do not raise a claim against the same DD twice.
• We also want to be able to view all DD mandates set up on an individual customers account so that I can service any customer queries and investigations.
Solution:
A table view is required to list the DD Mandates set up against a customers account and the payment history of those. Each mandate has a unique reference and when the payment collection request comes against that mandate it will quote the same reference in order to pass validation and check that there is a valid mandate set up on the account. So the view is a mixture of data from the Form3 Mandate management solution and details from any DD payment collection requests that have been received against the mandate:
User flow for DDIC
Prototype of DD cancellation and DDIC claim journey
