Jump To
Project overview
Discovery
Design
Results
How do we close down an old legacy platform and move users to a new one not originally built with them in mind without alienating them?
No time to read the full case study?
My Role
Senior UX Designer
UX Researcher
Team
Product Owner
Business + Change Analysts
8 Full Stack Developers + testers
Other stakeholders: Risk, Legal, Compliance
Timeline
3 Month Programme
Impact
Simplification of
3 complex financial services journeys
Drastic improvement in feedback about user's
sense of belonging
As a large financial services company, we had multiple different propositions to support different revenue streams and acquisitions. One of our legacy platforms was a direct-to-customer platform where customers either signed up independently or were signed up via their employer, and could manage their pension and other investments via a single portal. This platform was incredibly simplistic with restrictive fund choices.
On the other hand, our newest platform was an adviser-driven platform where financial advisers could invite their customers to view managed products.
Our old platform was built on legacy software and had notorious maintenance issues for years. It was determined the most economical move was to migrate the user base onto the new, adviser-led platform.
From the start, it was clear that the needs and wants of customers investing via a financial adviser versus those investing through a workplace or individually were drastically different. The project became about striking a balance that kept all users — including advisers — happy.
"I feel like this isn't designed for me. I feel like this is saying this is for serious investors and you don't belong here. It makes me just want to get in, do what I need to do, and get out as fast as possible"
- A power user of the old platform seeing the new, unchanged platform for the first time
User feedback like this, while alarming, was instrumental in getting stakeholder buy in for additional changes. Talking to user's allowed us to illuminate to the business the scale of the issue we were tackling, and the pace that would be necessary to deliver it all.
The number one starting point was addressing the expectation mismatch in the steps to add money to a product.
Building three new journeys presented maintenance challenges and technical resistance, especially as we couldn't rely solely on web components. Negotiations with the technology team were key.
Eventually we struck a balance that suited our technical needs, timeframe, budget and, most importantly, the users. We built it as one journey, as so many assets were shared, but linked it in a way that users would always perceive it as three separate journeys.
This took the technical benefits of our original journey and married them with the users' needs, resulting in a seamless experience shift.
One of the big learnings from user testing was that there was a lot of jargon in our current journeys, and users didn't feel confident risking making a decision, so they would rather abandon the process than guess wrong.
We cut out as many unnecessary technical questions as possible, but some remained and required simplifying.
Indexation proved a particularly difficult point; in lay terms it means increasing a payment each year to align with inflation/the Retail Price Index, but the concept was completely new to our users. By making the question more wordy and explaining and highlighting an example of how it works, we were able to bypass one of our toughest dropout points.
As a regulated industry, it's natural that there are lots of technical terms to contend with. Wherever possible we tried to strip out unnecessary user choices, like checking "yes" to having done their fund research even if paying into their existing funds. Other times, we found compromises to simplify questions we couldn't remove and make them less intimidating to our users.
In research, our users reacted with horror to our current dashboard designs. They were too technical-looking, too stark, too serious.
Fixing this came in two parts: making the actions easier to understand, and bringing more tools and features into the experience to feel less stark.
Unfortunately, our work had to be paused due to large-scale organisation restructuring. While we can't currently deliver the value as planned, there is a clear, well-documented series of design files and business artifacts awaiting a future team to pick up the work if desired.
Pausing the project, while disappointing, allowed me to refine my UI spec work, as I had to ensure the new component designs could be picked up and shipped even if no one attached without relying on current stakeholders. The Specs (formerly EightShapes) were a great tool for accomplishing this, as when I had clean components I could automate some of the more repetitive documentation, allowing me to spend my time on detailed work like accessibility tagging.
"This really feels like it's been designed for me, by someone who understood exactly what I need"
- Recurrent interview theme from users of the old platform seeing some updated screens of the new platform for the first time
While we couldn't get the project live, speaking to users and hearing that they feel seen - and how rare that feeling is in financial services - has proven to me the value of this project and its outcomes.
This project required very fast paced, simultaneous design work. In order to keep to the timelines, I had to learn quickly when to delegate work, and when to deprioritise and do quick benefit/risk analyses . It was great getting to work so close with customers again, being able to hear honest feedback and critiques of there experience and make them feel seen.