This project was part of Handelsbanken’s migration from a legacy mortgage platform to a new system. As part of this journey we needed to support all types of journeys to fully transition to the new system. One of the key areas I explored was the End of Benefit (EOB) journey, the point at which a customer’s preferential mortgage rate (such as a fixed or tracker period) comes to an end and the loan transitions to a new rate. My role was to analyse the existing process in the legacy system and redesign it to be more intuitive: reducing the number of steps while still capturing all the necessary information.
Handelsbanken, London, UK
UX Designer
Introduction to Project
Our Goal
Discovery to Design
Measuring Success
Lessons learned
Figma
Challenge
Complexity of a Legacy System:
Much of the workflow in the legacy system relied on outdated logic, and simplifying these into a more intuitive experience without breaking existing flows required a lot of mapping, collaboration, and creative thinking.Limitations on Using Automated Process:
Due to system constraints, we couldn’t fully migrate or automate the movement of cases from the legacy platform to the new system.Time Pressure and Ad Hoc Requests:
There were unexpected shifts in delivery timelines and business priorities, which meant parts of our proposed solution had to be adapted or de-scoped.
Results
25% Reduction in Processing Time:
By simplifying workflows and introducing smarter filtering and search capabilitiesIncreased Stakeholder Confidence:
Through frequent design reviews, storytelling sessions, and showcasing user insights, we gained the trust of product owners and BAs. This led to faster sign-offs and more openness to design-led decisions.Better User Experience with Less Friction:
Even though automation wasn’t possible, we tried hard to create a smoother and more guided journey for users.
Improved Team Collaboration & Visibility:
By running internal workshops and sharing design updates, I helped foster better understanding of UX practices across the product and tech teams.
Introduction to Project
This project was part of Handelsbanken’s migration from a legacy mortgage platform to a new system. One of the key areas I explored was the End of Benefit (EOB) journey, the point at which a customer’s preferential mortgage rate (such as a fixed or tracker period) comes to an end and the loan transitions to a new rate.
The EOB concept was completely new to me, so if you’re hearing it for the first time, you’re not alone. :)
To illustrate, imagine a 35-year mortgage: it may start with a 20-year fixed period, followed by an 8-year tracker, and then a 7-year fixed period. EOB events occur at the hand-offs between these benefit terms, making it essential that the system communicates changes clearly, guides users through the transition, and reduces unnecessary complexity or duplication.
What made this project especially complex?
It was a system migration challenge. Handelsbanken had many active loans in the legacy system that needed to be transferred into the new one. However, this couldn’t be done automatically, branch staff had to handle it manually. This created an additional layer of design: not only building the EOB journey for the new system, but also creating a specific path for bringing old cases into the new system
1- Design the EOB journey for the new system
2- Design EOB for cases from the legacy system
3- Supporting subsequent journeys
The challenge?
We had to design 2 different journeys and 2 separate designs.
1- One for our new system to enable branch users to create EOB for cases already in the new system
2- One for our legacy system to enable them to create an EOB case in our new system using the data already available in our legacy system
You may say transferring data can be easy and quick, but it wasn’t.
It wasn’t possible to bring old cases into the new system automatically, and if we wanted to let them enter the case from scratch this is the flow they needed to go through, so many steps to go through and information to fill in.
Normal user journey of creating a case from scratch
Discovery to Design
I needed to do some discovery
Focus group sessions
Hear each member’s point of view, even when they might contradict each otherInterviewing with subject matter experts
To check the policies we needed to be careful aboutInterview with Branch users
Ask more in-depth questions, looking at the legacy system and how users are working now
Going through different versions and options
As well as making sure that whatever I’m going for is feasible and supported by our design system
“After all these sessions, we had made really good progress, understanding what I needed to work on and how to design it”
Collaboration and involving other team members
Started involving influential members of Dev and QA.
Asking for other team members’ ideas and opinions.
Having regular calls with the PO to keep him updated ,
Working closely with the BA during the project
‼️What didn’t we expect? Wait, a curveball was coming
What happened
We had our refinement sessions when they cut the deadline short, which meant some parts of the process were now nice-to-have
What I learned
That’s when I realised that having everyone’s approval is not the end of the game
What I did
Organising calls with DH and other team members to see which parts could be achieved within the same timeline
Plus sharing the rationale behind the decision we made
After going through different versions, finally we were able to capture the right amount of information in fewer steps. In the picture below the green parts show the steps they need to complete.
User Journey for cases coming from the legacy system to the new system
This is the flow for cases that are already in the new system
User Journey for cases coming from the legacy system to the new system
After the final design
Some random screens
Measuring success
20% Reduction in case completion time (This is for cases already in the Legacy system)
Easier → fewer steps
Faster → Fewer data entries
Specific & Accurate
Build both journeys in a way that supports subsequent journeys as well
What I learned?
1- Being adaptable
Changes are out of my control, but I stay ready and adapt quickly to the situation.
2- I don’t own the solution
A design or solution isn’t permanent; it’s valuable only as long as it solves the problem.
3- Keep everyone in the loop
Sharing the story of the design and data with the team to keep them updated, helping them feel more connected to the project