Designing a mortgage retention workflow
- My role
- Independent Product DesignerProduct design from definition to pilot; later also responsible for product management and delivery.
- Period
- Dec 2024 → Dec 2025contract, United States, remote
- Scope
- Product · UX/UI · design system · PM · admin · marketingproduct definition, prototyping, user-facing application, admin environment, market-facing pages
- Product
- Mortgage retention decisioningfor US banks and mortgage teams
- ~1 hour
- Daily manual preparation removed per advisor
- Before adoption~30% more
- Clients handled per advisor, daily
- Kickoff7 months
- To an MVP in production
Workflow improvements were measured by the bank during a three-month pilot.
The client and product are anonymised. Interfaces are reconstructed in English with synthetic data; photographs are illustrative.
Where it began
From a decision engine to a working product
The client had built a decision engine that identified mortgage retention opportunities from bank data.
I joined to design the product around it: data setup, result review, offers and borrower outreach. The decision model itself was outside my scope.
I worked with the client as a domain expert, developed the user flows and built an interactive prototype. He used it with prospective customers to gather feedback before development.
I then brought four engineers onto the project and took on product management alongside design. We delivered an MVP in around seven months, followed by a three-month pilot at a US bank.
A day in the product, in four screens
Each screen is shown in full further down; these link to where.
The whole of it
Designing the decision loop
Advisors previously assembled their worklist across internal systems and spreadsheets.
The product connected data preparation, prioritised opportunities and outreach in one workflow.
With the product
- Portfolio + additional data + current rates
- Decision engine
- Eligibility and score
- Opportunity
- Borrowers
- A specific offer
- Email / SMS
- Advisor follow-up
Product model
Defining the workflow
I worked with the client to map who would use the product, what data they had and which decisions needed human input.
The first design went through four iterations before we tested the interactive prototype with prospective customers.
Three inputs, three different lifecycles
Portfolio and supporting data belonged mainly to setup. Interest rates changed more frequently, so I separated their update flow from the initial import and mapping process.
From source file to usable data
- Bring the source in
- Translate somebody else's schema into ours
- Check the data before it enters the calculation
The two steps before it: the file, and the mapping
Daily work
Turn a prediction into a working day
Advisors started with a prioritised set of opportunities rather than preparing a list from the full customer base each morning.
Start with the opportunity, not the customer table
From internal campaigns to real decisions
Early versions used generic campaign names. We changed the structure to familiar mortgage opportunities, such as Cash Out and Rate & Term Refinance. Each showed the eligible audience and financial volume before the user opened individual borrower records.
Finding somebody to contact was only half the job
Advisors could filter borrowers, inspect records and exclude people contacted recently. They could then prepare offers, send email or SMS, or export a selected group for follow-up in the bank’s existing systems.
Freshness
Make freshness part of the decision
A good opportunity stops being good when the rate behind it changes.
Rates could change several times a day. I made source timestamps visible and added a warning when input data had changed since the last calculation.
Users could recalculate or continue with the existing result, with its status visible. Previous runs remained available with the source-data version used for each calculation.
- Rates update
- Source changes
- Stale run
- Recalculate or keep working
A second interface
An optional assistant for less common queries
We added an AI assistant for queries that did not fit the main interface.
Queries such as finding a custom borrower group or checking when rates were last updated. Routine tasks remained available through the conventional interface.
Adoption varied: some managers preferred the existing controls. The assistant remained an alternative way to use the product.
The rest of the work
Beyond the core product
The same work also had to be explained, sold and built by a team.
Signal now, trend over time
Managers could also review portfolio trends by geography, loan product, customer type and campaign activity.
Explaining the product was part of designing it
I designed marketing pages alongside the product to explain the workflow to prospective customers: combine data, identify opportunities and take action. The client used these pages and the prototype during market conversations.
Where it landed
From prototype to a bank pilot
We delivered the MVP in around seven months.
During a three-month pilot, the bank reported around one hour less manual preparation per advisor each day and approximately 30% more clients handled daily. Around 100 advisors were using the product after the pilot.
My work covered the user-facing product, admin environment, design system and marketing pages, alongside product management during development.
In hindsight
What I would improve in a similar project
Three things I would do differently on a similar project.
- Observe advisors directly earlier, alongside the client's domain input.
- Define workflow analytics before the first production release.
- Measure assistant usage separately to understand when it helps more than the conventional interface.
Open to Senior Product Designer roles
Based in Porto, Portugal, with authorisation to work here. Get in touch about a Senior Product Designer role or to discuss my work in more detail.