Modernising A Retail Bank
We were asked to help a major retail bank to make it easier for customers to apply for accounts online without any human interaction. They knew their existing online forms were a barrier to new customers. They were hard to use and the conversion rates were less than 5%. The challenge was that most of the time it was necessary for new customers to come into a branch to complete the account opening process, often new customers would simply drop out of the process rather than complete the application.
The technical challenge was the mainframe banking system that sat behind this process. This legacy system included workflows that had been designed years before that assumed a customer would start and end the process in a branch, with an account manager. The problem was that the world had moved on but we knew it was unrealistic to replace the banking system. It was at the core of all their operations, from branches to call centres to internet banking, so we knew a major change there would add years and risk to the project.
Designing the product
Whenever we need to design a product with a legacy backend system we need to think about what the user will experience and how that will impact the data in the backend. We need to consider how we can design the legacy integration to provide the user with a modern and sleek experience but can provide the backend with the correct data. We needed to ensure someone could start their onboarding in the new application but if there is a problem or if they do not meet some regulatory requirements then the application would have to be completed in a branch.
As with any new product, the place to start was with the users. Our UX team worked with users online and in branches to understand the pain points and start thinking about ideas to improve the process. At the same time we deployed our technical team to understand the backend requirements and to design a way of managing the data that would provide flexibility without compromising the data. One of the objectives was to improve the way applications could interact with data and to lay the foundation for future product development.
Armed with the knowledge of users and the technology we ran a series of workshops with the internal stakeholders to test the possible solutions we had identified. The goal was to work with people who understood the backend systems, branch processes and local banking regulations to ensure our solutions were viable before we tested them with real users.
Once we knew what could work, we designed a series of Microservice based API’s that would allow product agnostic interaction with the backend. The API’s we created included a series of low-level backend interactions that enabled us to work with the backend systems via HTTP. Then we created a more modern, Restful set of API’s that worked with the low-level API below. The result was a set of API’s that would allow any product to be built, providing a single route into the workflow engine, a single data representation of a customer and a single view of a product.
The UX team went back to the users to continue to refine the approach. We used the API design to allow our technical designers to craft screens and processes without needing to know about all the details of the backend. After several iterations of the user interface we had a design that would greatly improve the application process and would work correctly with the backend systems.
Building a banking application
Once the initial design was in place we started to look at building the application. Our team split out the features into our critical Version 1 features and those that could be added later. We identified the highest risk items so we could look at them first, these include the base backend interactions and the integration of the existing security system. We prioritised these aspects so that we could identify the challenges we would face, in doing so we uncovered several issues that needed to be addressed and would have delayed the whole project if they had not been found early.
We worked closely with the internal teams throughout the build so that we knew we would get the approvals we needed at the right time to get application live and other teams would be able to do their part. We needed the teams who managed the public website, internet banking, advertising and others to make sure customers could reach our application.
What happened?
After a short building phase we had a product that could be launched. It had a simple to use UI and a set of API’s that allowed data to pass through the system in ways that were impossible before. Immediately after launch we sat and watched the logs as customers started to use our applications. Most of them worked exactly as expected but we saw cases when errors would occur due to unusual combinations of data or downstream systems being less reliable than expected. Fortunately we had expected this and our team was in full hyper-care mode, we found the cause of errors and quickly created test cases so we could reproduce and fix them. Over the first week after launch our team was releasing 3-4 minor changes per day, an unheard of pace in a bank. We continued to operate a 24/7 support model to ensure things ran smoothly.
Quickly the errors died away and the platform was stable. Our UX team continued to work with customers and refine the approach. Over the next 6 months we saw multiple releases a week to improve the journey, reduce drop off and improve reliability. As a result the bank saw an increase in completed applications of more than 40%, meaning new customers in the tens of thousands.
Our model grew and the bank embraced the agile, remote approach we had pioneered. New products were defined and new territories asked for help. We helped to create a dynamic internal culture that included over 150 people across 10 countries and it continues to grow.