Helping customers invest with more confidence

Outcomes:

• Increase in trading volume

• Increase in trading on mobile

• Thousands of asset searches in the first 3 months post-launch

The challenge

This was my first project when I joined the bank in 2023. Customers who wanted to explore investments in the mobile app had no way to browse, search or learn about what the bank offered. If you were new to investing, the app gave you nowhere to start. The NPS score showed it.

The goal was a mobile-first experience where customers could explore, learn and invest, whether they were investing for the first time or had done it for years.

My role

I led the design end to end for 12 months, inside a product squad with a product owner, tech lead, business analyst, front-end developers and a UX writer. I owned the UX strategy, user flows, prototyping, research, stakeholder presentations, accessibility and design QA through to launch.

Learning the investment universe first

I interviewed senior stakeholders across the investments team. I wanted to know what the bank actually offered: which asset types, how the business rules worked, what data the platform could show, and what had already been tried.

I also read the existing research. The strategy team had already interviewed customers about how they research investments and make decisions, so I built on that instead of starting again.

In a complex financial product, you can't design a good information architecture until you understand the information.

Designing the whole journey before cutting it into phases

Product squads like to break work into small pieces. That's good for engineering. For design it has a risk: if you only ever think one phase ahead, nobody designs the full journey.

So I designed the complete end state first, with every scenario, edge case and screen state. Then I sat down with the product owner and tech lead and agreed how to deliver it in phases. Everyone could see where we were going, and decisions in phase one didn't cause problems in phase two.

I mapped the flows in FigJam and ran working sessions with the tech lead to find technical constraints early. When I presented to senior stakeholders, I used interactive prototypes and always answered three questions: what problem are we solving, what does the evidence say, and what trade-offs did I consider.

Designing the north star

Product squads naturally want to break scope into small, deliverable pieces. That works well for engineering. For design, it creates a risk. If you only ever think one phase ahead, you end up with an experience that no one planned at the full journey level.

My approach was to design the complete end state first, covering every scenario, edge case, and screen state and then work backwards with the product owner and tech lead to agree on phasing. This gave the whole team a shared picture of where we were heading and meant that phase one decisions didn't create problems for phase two.

I used FigJam to design detailed user flows and ran working sessions with the product owner and tech lead to identify technical constraints and delivery risks early.

I presented ideas to the team and senior stakeholders at regular intervals, using interactive prototypes to communicate complex flows. Every presentation explained what problem are we solving, what does the evidence say, and what trade-offs did I consider.

Testing with customers

When the core journey was ready, there was no UX researcher available. I didn't want to wait or skip testing, so I ran an unmoderated study on UserTesting.com myself. It let us recruit quickly and get real reactions to the prototype within the timeline.

Before the test, I worked with the UX writer on the tone of voice. After it, I presented the findings to stakeholders with specific design changes. The research found problems I hadn't expected, and we fixed them before any production code was written.

Key decisions

Search and browse

The research showed two kinds of customers. Some knew what they wanted and needed to find it fast. Others were still learning and wanted to browse. I combined one global search across shares, funds, ETFs and trusts with browse paths by asset type. Filters helped experienced investors narrow down. Short explanations of each asset type helped newer investors feel confident enough to explore.

Market data

Stakeholders wanted market data in the experience: index performance, top risers. The risk was overwhelming or misleading less confident investors. I worked with the investments and compliance teams to agree what to show, how to label it and which disclosures were required.

Compliance

In a regulated business every screen with financial information goes through risk and compliance review. I brought the compliance team in early. When a requirement clashed with a good experience, I worked through it with them until we found a version that met both.

Accessibility

Every design was checked against WCAG AA before handoff.

Working with engineering

Because I worked with the tech lead from the start, most constraints were solved before handoff. During the build I ran regular design reviews with the front-end developers and gave CSS guidance where needed. My computer engineering background made conversations about APIs, data and trade-offs much faster.

Impact

In the first three months after launch:

• +46% trading volume

• +54% trading on mobile

• Thousands of asset searches by customers

The journeys are still growing, with new features added from customer feedback.

What I learned

In a large organisation with many stakeholders, the habit that helped me most was making every decision visible: the problem, the choice, and the evidence behind it. That's what kept the design moving.

Designing the full journey before agreeing phases took more time at the start. It saved much more time later.