CASE STUDY
Crypto Experiments
Connecting a bank account is a crucial step for customers before they can invest with WealthBar. As we scaled, various circumstances forced us to reimagine the optimal flow for users to connect.
My Role
Lead Designer (Research, UX, UI Design)
Team
Tina Yiu, Product Designer
Travis Rempel, Engineer
Mel Delosada, Engineer
Problem
An uptick in cases of users using our service to commit fraud (money laundering) forced us to block our bank change feature and direct all client bank change requests through a rigorous manual staff verification process. The core problems included:
- ⏳ Long Lead Times — Our manual process forced customers to wait a minimum of 3 business days before they could begin transferring funds to/from their bank accounts.
- ⬆️ Rising Volume — Staff became more and more overwhelmed with the volume of banking requests as we grew.
- ✋ Compliance — Our manual staff process did not adequately satisfy compliance requirements for keeping records of changes.
Service Blueprinting
As part of our initial research for this feature, we roped in a few folks from our Client Services Team to create a service blueprint to better understand the problem. The goal of this was two-fold:
- We wanted to understand the ways in which users have been committing fraud (user stories); and
- We wanted to map out the current process for ID and bank verification conducted by staff (completely manual).
After creating the initial blueprint and conducting a few interviews with staff, we presented our findings to stakeholders. We outlined the issues that needed to be addressed and ran a workshop to define an ideal state for the workflow.
Current State — I worked closely with our client services team to flesh out our current service blueprint.
Ideal State — We ran a blueprinting workshop with key stakeholders to collaborate on an ideal solution.
Final Service Blueprint — This map helped us identify key pain points that hindered our staff's ability to identify fraud quickly and accurately.
Solution
(1) Redesign the existing bank change feature to include a secure authentication process — allowing for automated approvals that doesn’t require staff intervention.
(2) Design an internal workflow feature that allows staff to track and complete client bank change requests.
The Client Flow
Improving the client flow was important. After deciding on a third-party service that allowed users to securely and automatically connect their bank accounts, I began mapping out a new flow.
User Flow (Client) — Leveraging Flink's service, users would be able to verify their bank accounts using their own banking login credentials. This allowed us to auto-approve a large chunk of bank change requests.
Screen Flows
After a few rounds of testing and iterating, I ended up with this final flow. Clients were now able to verify their accounts using a banking connection integration with Flinks.
Changing a bank account — Users can easily change between existing bank accounts that have already been verified.
Adding a bank account — Any new bank accounts would require users to verify using their online banking credentials.
The Staff Flow
Our staff needed an interface to help keep track of pending request tickets and a request details page that aggregated all relevant information associated with the request.
Content Modelling — Identifying key pieces of information for account validation and running a card sorting exercise.
Information Architecture
We began by shadowing our staff as they conducted the manual verification process. This allowed us to identify key pieces of information that staff needed to validate and process each new request, we started card sorting to form a basis for the feature’s IA.
Sketching
With a good sense of all the information the UI would have to accommodate, I began sketching some wires. This allowed me to begin mapping out different pieces of data to define possible flows and IA structures on each screen.
Early Wire Sketches — Exploring different ways of organizing crucial client information.
Earlier Iterations — Exploring different ways of displaying client data.
Testing & Interation
We ran usability tests with our client services team. This was particularly useful since we could test the design directly with the users who would be using this feature on our admin platform.
Testing Results — I ran two rounds of usability tests with staff to continuously iterate on the solution.
Approve, Reject, Comment
Hey there, this is the default text for a new paragraph. Feel free to edit this paragraph by clicking on the yellow edit icon. After you are done just click on the yellow checkmark button on the top right. Have Fun!
Staff Updates — Allows staff to leave comments and record a papertrail to meet our compliance standards.
Hi-fidelity Mockups
After a few rounds of iterations, I refined the designs to this. This flow involves a work queue of pending bank requests and a request details page where staff can approve or reject each request.
Bank Request List — Bank requests are bucketed in 3 possible states: unassigned, under review, and completed.
Request Details — All the relevant data that staff needs to review before either approving or rejecting a bank request.
Outcomes
Upon rolling out this new feature in early 2020, we began to see immediate results in both our back-end staff process, as well as the overall customer experience.
- Reduced average lead time by 65% — Average wait time for new bank accounts shortened to 1 business day and auto-approved account changes became instantaneous.
- Reduced staff verification tickets by 50% — Auto-approvals accounted for a little over half of all new bank change requests.
- Meets compliance requirements — Our manual staff process did not adequately satisfy compliance requirements for keeping records of changes.