Embedded Files
Challenge
[Large Regional Bank] wanted to increase market share by transitioning into a banking-as-a-service (BAAS) platform and providing a financial services backend for startups. Apart from infrastructure modernization, several operational challenges stood in the way. My role involved conducting discovery to identify core issues from the customer/employee perspective and to find potential solutions.
Approach
Research
I was brought in seemingly as an afterthought. Previous consultancies had previously journey-mapped the bulk of bank operations. Our business strategy unit had been onsite for six months and was finalizing the vision and strategy work and building out target service blueprints. The UX research and design teams were already working on future-state experiences and completing a design patterns library. Anything I intended to do would be a duplication of effort, and others continually challenged my involvement.
Nevertheless, as I pored over the deliverables from the previous teams and conducted stakeholder interviews, it became apparent that a critical piece had gone overlooked: No one had effectively communicated to the organization why it was necessary to become a BAAS, causing alignment issues across the bank.
To build a case for the transformation, I collected industry reports, noting the initiatives of other companies and markets and looking at trend forecasts. I distilled the research and constructed a POV on data-driven banking experiences and best practices, providing digestible narratives highlighting the five use cases chosen to test the new data backend. The narratives illustrated how modern data systems improved the customer and associate experience, especially when utilizing predictive banking.
The POV became a critical part of the vision, and because of my insights, leadership assigned me to help the data-ops team, which was struggling to make headway with the bank fraud detection team.
Until the POV, no one told the organization why transformation was necessary.
Synthesis
The fraud team was too busy to meet with our data-ops team, so the groups had spent weeks sending lists of data points back and forth, trying to get to a set of requirements for an account takeover (ATO) detection MVP. I questioned the data ’s use, and while the engineers could tell me what the data referenced, they could not tell me the process for using the data to detect attempts to take over an account. They planned to echo back the data as a spreadsheet like the fraud team currently used.
A spreadsheet solution was ill-suited. Humans stumble over walls of data, and with all the data points requested, it would be too big a set to parse manually. To identify the subtle signs of suspicious activity from it would be impossible. I pushed back against the engineers’ solution, surmising there was a way to present the data that would improve the fraud team’s ability to detect account takeovers.
Without much to go on, I put together a needs assessment and a rudimentary strawman to elicit feedback (model-driven inquiry), requesting a review with the ulterior motive of facilitating a requirement gathering and co-design workshop. Seeing the review as a milestone event, the fraud team manager chose to participate.
A spreadsheet was not enough, a thorough needs assessment was required.
Exploration
In the co-design workshop, I facilitated the manager through a Miro board of activities describing the fraud team’s current experience and what they dreamed of having in the future. I translated the manager’s comments into current and future state journey maps, pain points and opportunities, and a list of functional requirements for a UI. The manager was encouraged to see her thoughts and requests taken seriously.
Having analyzed the workshop output, I proposed a simplified dashboard. The product owner approved the idea, acknowledging the fraud team’s need for a more purposeful solution and seeing the eventual output as a win for the project.
I mocked up an ATO dashboard, but the product owner requested that the prototype match a BI platform. Unfortunately, there are no presentation specifications for Tableau and Looker. The only way to understand the design capabilities and limitations is by building within the tool. With no data-viz engineers available to assist, I signed up for trials and learned to develop them myself.
The stakeholder was facilitated through a co-design workshop.
Evaluation
Having completed BI-compatible dashboard designs, I called for a final review. The fraud manager was eager to see what I had come back with. The manager, expecting a spreadsheet, was surprised by what she saw. The dashboard was far more than the fraud team could’ve asked for and exactly where they’d hoped to go. The design was approved.
Next, I conducted a walkthrough with the data visualization team tasked with building the ATO dashboard. I had taken great pains to match the capabilities and aesthetics of the platform. The data-viz team excitedly remarked that the dashboard was how they thought it should be built within the tool and feasible.
A prototype was constructed within the BI tool.
Outcome
As of this writing, [the bank] ’s leadership reprioritized the value streams, deciding that the equipment financing (AEF) use case should precede ATO as MVP. The ATO dashboard still awaits development, and its impact is undetermined but predicted to improve monitoring efficacy, preventing future account takeovers.
This case study began with the question as to why no one had asked the bank why modernization was necessary. What did it mean to be a BAAS? Internal stakeholders wanted to know why this initiative was so important and at such an expense. I was able to interpret and articulate that value. Stakeholders outside the technology division came away from the POV I presented, expressing gratitude and enthusiasm, now understanding where the bank was heading and why the work was necessary.
Google Sites
Report abuse