Guide them, don’t take over

The problem space

ubank’s self-serve home loan application let customers apply without a banker. But when a customer got stuck, or failed a step, they called, and the banker on the other end was working blind.

Bankers couldn’t see what the customer had entered or where they’d stopped. Often the only way forward was to take the application over and start it again: up to 40% of applications from customers who called. That cost banker time, threw away the customer’s progress, and turned a self-serve customer into an assisted one.

Behind that were wider problems:

• No lead prioritisation. Leads from customers who dropped off part-way through an application came in with no way to tell which were most likely to convert.
• Manual serviceability checks, worked out in Excel.
• Fragmented notes spread across systems, so context was lost between calls and between bankers.
• Twelve or more systems for bankers to switch between, with no single view of the customer.

My role

I was design lead for the work from end to end: defining the design challenge, running the research, shaping the vision and roadmap, and designing through to delivery.

It was the first thing I started at ubank, under the codename Project Ninja. Over the following year it was picked up and put down a number of times as priorities shifted, alongside my work on the self-serve home loan application. The final CRM work went out as I left.

Process & artifacts

Framing the challenge

The question I set for the work was specific: what does a banker need to know to help a customer who is stuck or has failed in the self-serve application?

I ran problem-framing and collaboration sessions with the business to build the value proposition: banker efficiency, better application quality, higher conversion, stronger compliance, and bankers and customers working on the same application rather than in parallel.

Research with the people doing the work

I designed the research, moderated it and synthesised the findings: 13 interviews with brokers, bankers, an operations manager, a risk manager and a lending consultant. They covered residential and commercial lending, and risk and compliance, with experience ranging up to more than eight years at ubank.

The themes were consistent: software, data integration, process, serviceability, calculators, support and training.

One line from a banker summed up the brief:

“If I could have a single interface to let me know what leads each day to follow up.”

Others filled in the detail:

• “A direct channel to see where each lead is up to and which are the highest priority.”
• “Being able to see chat and call incoming in one place without having to switch between windows.”
• “Statements and payslip upload direct in channel.”

A vision and an MVP

The research led to a Banker Portal concept: lead scoring to prioritise leads from customers who dropped off, a view of the customer’s application, and integrated note-taking.

I ran co-design sessions to shape the roadmap and prioritise the MVP. I pushed for two capabilities to be in it, because they were what the research said mattered most:

• Bankers can see the customer’s application, including the ID verification (eKYC) and illion bank data
• Integrated note-taking, so the context of every conversation stays with the application

The pivot

Partway through, the direction changed from the top. To grow fast, ubank had built its technology on foundations that weren’t designed to work together, and technology leadership set a new strategy: a single pane of glass, one bankers’ workbench in place of many tools.

A standalone Banker Portal didn’t fit that strategy, so the work moved into the workbench. The research and the MVP features carried across; the destination changed.

One design language, three tech stacks

The customer’s application was built in React, our component library lived in Storybook, and the CRM ran on Angular. For a banker to work alongside a customer, they needed to see what the customer saw.

So alongside the workbench, I aligned the design across all three, working towards a single future-state design system shared by the application and the CRM.

When the pivot didn’t land

The workbench wasn’t successful: it didn’t meet its operational outcomes.

That could have been the end of Loan Assist. It wasn’t, because of the design system. The CRM already shared it with the customer application, so we could roll Loan Assist into Lending, as a feature build in the CRM that gave bankers the customer’s application as back-end functionality. The customer’s screens and the banker’s view were built from the same parts, so they matched step for step.

Impact

Loan Assist put the customer’s home loan application inside the CRM, so bankers could work alongside the customer in real time: see where they were stuck, and guide them to carry on themselves.

The measure of success was set before launch, and the final release went out as I left, so I didn’t see the results:

• Bankers taking over applications: from up to 40% of those where the customer called, to a target of 5%. Instead of restarting, the banker sees where the customer is stuck and guides them to carry on.
• More customer-led submissions. The expected outcome was a larger share of submitted applications coming from self-serve, with bankers’ time going where it was needed.

What I learned

• Early discovery pays for itself. It let the business see the value proposition clearly, and the research outlasted every change of direction.
• Talk to the people doing the work. Research directly with bankers showed where the most impact was.
• Top-down pivots don’t always land. The workbench was a technology leadership call, and it didn’t meet its outcomes. Design can’t always stop that, but it can make sure the work survives it.
• Foundations are insurance. The shared design system was the least visible part of the project, and the reason Loan Assist shipped.
• Designing for colleagues is designing for customers. When the banker can see what the customer sees, the customer gets help without losing their place.