Designing investment discovery for thousands of users

The short version:

• Learn the domain before you start designing.

• Design the end state first, then phase back for delivery.

• Adapt your research methods to the constraints you have.

• Bring compliance in early, not at the end.

• Narrate your decisions, it gets better feedback and less pushback.

What a year designing at scale taught me about working in financial services

In 2023, my first project at a major UK bank was to redesign the investment experience on the mobile app. There was no investment discovery journey in the app at the time, and the NPS score reflected that. Customers couldn't easily explore what to invest in, search for specific assets, or understand what they were looking at. The problem was clear. Getting to a good solution was considerably less so.

A year later, trading volume on mobile was up and the search feature alone logged thousands of asset searches in its first three months. Here's what I learned along the way.

Start by learning the domain

My first few weeks weren't spent in Figma. I spent them talking to senior stakeholders, the investments team and product owners. I was trying to understand the investment universe the bank offered and how it worked. What assets were available? How did the business logic work? What had already been tried?

This is one of the most valuable things you can do when you join a team working in a complex domain. You can't make good decisions about information architecture if you don't understand the information. You can't have a credible conversation about what to surface to a customer if you don't know what's in the product.

It also builds relationships early. Asking a subject matter expert to teach you something is one of the fastest ways to establish trust.

Design the north star before you negotiate the phases

Product teams work in sprints and they break scope into pieces to ship faster. That's a sensible delivery approach, but it creates a problem for design. If you only ever think one phase ahead, you end up with a fragmented experience that no one planned.

My approach was to design the complete end state first (every scenario, every edge case, every state) and then work backwards with the product team to agree what would ship in each phase. This gave us a shared picture of where we were heading. It meant that design decisions made in phase one didn't contradict what we needed in phase two. And it gave stakeholders confidence that the phased work was adding up to something coherent.

If you go straight to scoping phase one without that north star, you'll spend the next six months doing expensive rework.

When there's no researcher, adapt

At the point we needed to test the designs, there was no UX researcher available for the project. The timeline was tight. The easy option would have been to ship without testing.

Instead I ran a round of unmoderated research using Usertesting.com. It wasn't the research approach I'd have chosen in an ideal world. Moderated interviews give you richer insight, more ability to probe, and a better sense of why people are doing what they do. But unmoderated research, done well, gives you something real. We recruited quickly, got genuine reactions to the designs, and uncovered problems we hadn't anticipated.

Some evidence is always better than none. A good designer adapts their methods to the constraints they actually have.

Treat compliance as a design constraint

Working in financial services means working with risk and compliance teams. Designers who treat this as a late-stage approval process tend to get burned.

Compliance constraints are just another type of requirement, and the best way to handle them is to bring them into the design process early rather than treating them as a final approval gate. I worked closely with the compliance team to understand the rules, and made sure every design decision was grounded in the research insights we had. When you can show that a choice serves the customer and meets the regulatory requirement, you're rarely in a fight.

The places where this gets hard are when a compliance requirement genuinely conflicts with good UX. In those cases, the answer is negotiation and iteration. Understand what the rule is protecting, then look for a design solution that protects it without damaging the experience. There's almost always one.

Make your decisions visible

One of the most important habits I developed on this project was narrating my decisions. Every time I shared designs with the team or stakeholders, I explained what problem I was solving, why I'd made the choices I had, and what evidence backed them up. It makes the work easier to engage with.

When people understand your reasoning, they give better feedback. They push back on the right things. And they're far less likely to override a design decision based on personal preference when they can see the logic behind it.

At the scale of a large organisation, persuasion and craft are equally important. You need both to ship something good.