Setting up and managing regular mortgage overpayments

Designing an end-to-end app experience for customers to set up and manage regular mortgage overpayments with confidence.

Role

Sole UI/UX Designer

Timeline

March-May 2025

Team

Product Owner, Business Analyst and Copywriter

Tools

Figma

Overview

Barclays customers could make regular mortgage overpayments through online banking, but they could not set them up or manage them in the mobile app. The project formed part of a wider initiative to expand the Mortgage Hub and give customers more control through the channel they used most frequently.

Stakeholders had already defined the business requirements and supplied Balsamiq wireframes. These described the required functionality, but not the complete customer journey. My task was to turn them into a connected app journey covering setup, review, confirmation and ongoing management.

The Challenge

Making a regular overpayment is more complicated than choosing an amount. A mortgage can contain several parts, each with different contractual payments, end dates and eligibility rules. Customers might be able to overpay some parts but not others.

The experience also had to account for:

  • Minimum and maximum amounts

  • Different payment durations

  • Direct Debit processing cut-off dates

  • Changes to the total monthly payment

  • Single-part and multi-part mortgages

  • Amendment and cancellation

  • Pending, successful and failed requests

The challenge was to explain these rules without overwhelming customers with the underlying complexity.

My Role

As the sole UX/UI designer, I owned the complete app experience across setup and ongoing management.

I was responsible for the single-part and multi-part journeys, exception scenarios, interaction design and final UI. I worked with product owner, business analyst and copy writer while retaining responsibility for the overall design direction.

Approach

1. Understand the brief and existing service

I reviewed the requirements, available customer insight and stakeholder wireframes. I also mapped the existing online-banking service to understand how regular overpayments currently worked and identify what needed to be retained or clarified in the app.

Online Banking Flow

1. Understand the brief and existing service

I reviewed the requirements, available customer insight and stakeholder wireframes. I also mapped the existing online-banking service to understand how regular overpayments currently worked and identify what needed to be retained or clarified in the app.

Online Banking Flow

2. Map the wider journey

I created a wider Mortgage Hub journey map to establish where regular overpayments would sit within the existing app experience.

I then developed the connected setup and management flows, covering single-part and multi-part mortgages alongside viewing, amending and cancelling an active arrangement. The mapping also accounted for eligibility, validation, Direct Debit timing, pending requests and failure states.

Wider Journey

2. Map the wider journey

I created a wider Mortgage Hub journey map to establish where regular overpayments would sit within the existing app experience.

I then developed the connected setup and management flows, covering single-part and multi-part mortgages alongside viewing, amending and cancelling an active arrangement. The mapping also accounted for eligibility, validation, Direct Debit timing, pending requests and failure states.

Wider Journey

3. Translating the journey into designs

Because of the delivery timeline, I worked directly with design-system components instead of creating low-fidelity wireframes.

I developed the single-part and multi-part journeys together, focusing on how payment amounts, durations, eligibility messages and summaries would work consistently across setup and ongoing management.

Translating Journey into Design

3. Translating the journey into designs

Because of the delivery timeline, I worked directly with design-system components instead of creating low-fidelity wireframes.

I developed the single-part and multi-part journeys together, focusing on how payment amounts, durations, eligibility messages and summaries would work consistently across setup and ongoing management.

Translating Journey into Design

4. Challenge and refine the journey

I presented the complete experience to designers who were unfamiliar with the project. Their independent perspective helped challenge the screen order, mortgage-part selection, payment hierarchy, eligibility messaging and confirmation experience.

I used the feedback to refine the journey before the final accessibility review.

Define Topic & Goals

Happy Path for Singular Journey

4. Challenge and refine the journey

I presented the complete experience to designers who were unfamiliar with the project. Their independent perspective helped challenge the screen order, mortgage-part selection, payment hierarchy, eligibility messaging and confirmation experience.

I used the feedback to refine the journey before the final accessibility review.

Define Topic & Goals

Happy Path for Singular Journey

Key Decisions

Show eligibility before asking customers to begin

Customers could only create an arrangement when they had an active Direct Debit, were not in arrears or too close to the end of the mortgage, and had terms that permitted overpayments.

I surfaced eligibility before customers entered payment details so they would not invest time in a journey they could not complete. For multi-part mortgages, ineligible parts remained visible with an explanation. Hiding them would have simplified the screen, but could have made customers think that parts of their mortgage were missing.

Show eligibility before asking customers to begin

Customers could only create an arrangement when they had an active Direct Debit, were not in arrears or too close to the end of the mortgage, and had terms that permitted overpayments.

I surfaced eligibility before customers entered payment details so they would not invest time in a journey they could not complete. For multi-part mortgages, ineligible parts remained visible with an explanation. Hiding them would have simplified the screen, but could have made customers think that parts of their mortgage were missing.

Keep multi-part mortgages within one journey

Treating each mortgage part as a separate task would have reduced the complexity of individual screens, but fragmented the overall decision and made the combined Direct Debit impact harder to understand.

I brought all parts into one journey, allowing customers to select eligible parts and enter an amount and duration for each one. Progressive disclosure kept part-level controls hidden until they were relevant.

During a review with other designers, feedback highlighted that customers could lose sight of the overall cost while configuring multiple parts. I added a sticky footer showing the combined monthly cost, while the final review showed how the total overpayment was distributed.

Keep multi-part mortgages within one journey

Treating each mortgage part as a separate task would have reduced the complexity of individual screens, but fragmented the overall decision and made the combined Direct Debit impact harder to understand.

I brought all parts into one journey, allowing customers to select eligible parts and enter an amount and duration for each one. Progressive disclosure kept part-level controls hidden until they were relevant.

During a review with other designers, feedback highlighted that customers could lose sight of the overall cost while configuring multiple parts. I added a sticky footer showing the combined monthly cost, while the final review showed how the total overpayment was distributed.

Separate the contractual payment from the overpayment

Showing only the new total Direct Debit would have reduced the amount of information on the review screen, but could have obscured how much was contractual and how much the customer had chosen to overpay.

I therefore separated the amounts before showing the combined total. The summary included:

  • The usual contractual payment

  • The selected overpayment

  • The new total Direct Debit

  • The first and final payment dates

  • The distribution across mortgage parts

The expected effective date was also shown before confirmation. If the next Direct Debit had already entered processing, the experience explained that a new, amended or cancelled arrangement might not take effect until the following month.

The cancellation journey reinforced that stopping an overpayment would not cancel the customer’s normal mortgage Direct Debit.

Separate the contractual payment from the overpayment

Showing only the new total Direct Debit would have reduced the amount of information on the review screen, but could have obscured how much was contractual and how much the customer had chosen to overpay.

I therefore separated the amounts before showing the combined total. The summary included:

  • The usual contractual payment

  • The selected overpayment

  • The new total Direct Debit

  • The first and final payment dates

  • The distribution across mortgage parts

The expected effective date was also shown before confirmation. If the next Direct Debit had already entered processing, the experience explained that a new, amended or cancelled arrangement might not take effect until the following month.

The cancellation journey reinforced that stopping an overpayment would not cancel the customer’s normal mortgage Direct Debit.

Design Solutions

Outcome & Reflection

Outcome

The final design connected setup and ongoing management across single-part and multi-part mortgages, covering eligibility, validation, review, amendment, cancellation and recovery. It presented part-level configuration, payment summaries and effective dates consistently throughout the journey.

The completed experience went through an accessibility review before the designs were finalised, and the feature is now due to launch.

As it has not yet gone live, measurable customer and business impact is not yet available.

Reflection

This project strengthened my ability to design a complex financial service as one connected experience rather than a collection of individual journeys.

The most challenging aspect was balancing part-level mortgage information with the overall payment impact. Decisions made during setup also needed to remain understandable when customers later viewed, amended or cancelled their arrangement.

The main limitation was the absence of formal customer testing. Future research would include moderated sessions with both single-part and multi-part mortgage customers, focusing on payment comprehension, part selection and effective dates. The findings would inform post-launch optimisation and identify where customers needed greater clarity or support.

Lets create better experiences

I'm always open to new UX opportunties, exciting challenges and teams where I can contribute and continue to grow.

Lets create better experiences

I'm always open to new UX opportunties, exciting challenges and teams where I can contribute and continue to grow.

Lets create better experiences

I'm always open to new UX opportunties, exciting challenges and teams where I can contribute and continue to grow.