Understanding the challenge
When an MTF customer hits financial difficulty, three different support workflows can come into play – Payment Waiver, Hardship, and, in more serious cases, Repossession. Each had grown up independently: hardship cases were tracked as tasks on the arrears page, Payment Waiver had its own claim-based language, and there was no shared way to see, on a loan, that any of these were in motion. Franchise teams were working reactively off the failed-payments and arrears pages, piecing context together manually.
My role
I led the UX research and systems design work to identify and define the shared pattern, working directly with franchise feedback and stakeholders to validate the model, and with engineering leads to sanity-check what it implied technically before it went further.
mapped onto where each sits in a loan's lifecycle: Lead/enquiry → Application → Assessment → Decision → Loan active → Support required → Recovery → Closed.
Laying the actual state models side by side surfaced the real insight: Hardship and Payment Waiver are nearly identical in shape, while Repossession's states genuinely differ because it's recovery work, not assessment work. I also separated Decision state (the human call) from System state (what the loan is actually doing), since conflating the two was a root cause of the ambiguous statuses teams were already struggling with.
The tempting version of this project was one big rebuild covering all three workflows end to end. I pushed back on that scope. The real V1 goal was to establish the shared foundation – consistent statuses, visibility, a reusable timeline – without rebuilding the entire servicing model up front.
Concretely: a lightweight "Support & Servicing" summary card, structured records, and a shared timeline, deliberately leaving full workflow builds for later phases. This traded a longer path to "complete" for something teams could use and give feedback on immediately.
A single Phase + Status model shared as scaffolding across all three — while each keeps its own status model and case record, never merged into one workflow
– Decision/System state separation, so a human decision and its system consequence are never conflated
– A recommended first-slice MVP
– Recognition of Loan Support & Recovery workflows as a named, reusable pattern
– Explicit UX principles carried across all three: surface actions before information, one source of truth per object, show what needs attention first.
This work established the shared model now underpinning execution across all three workstreams – it's the reason the Payment Waiver claims specification could adopt one clean status pipeline instead of fragmented language. This model is also the direct domain grounding for the AI-ready design system now being used to prototype Payment Waiver and Hardship as MTF Connect features.
The tempting version of this project was one big rebuild covering all three workflows end to end. I pushed back on that scope. The real V1 goal was to establish the shared foundation – consistent statuses, visibility, a reusable timeline – without rebuilding the entire servicing model up front.
Concretely: a lightweight "Support & Servicing" summary card, structured records, and a shared timeline, deliberately leaving full workflow builds for later phases. This traded a longer path to "complete" for something teams could use and give feedback on immediately.
A single Phase + Status model shared as scaffolding across all three — while each keeps its own status model and case record, never merged into one workflow
– Decision/System state separation, so a human decision and its system consequence are never conflated
– A recommended first-slice MVP
– Recognition of Loan Support & Recovery workflows as a named, reusable pattern
– Explicit UX principles carried across all three: surface actions before information, one source of truth per object, show what needs attention first.
This work established the shared model now underpinning execution across all three workstreams – it's the reason the Payment Waiver claims specification could adopt one clean status pipeline instead of fragmented language. This model is also the direct domain grounding for the AI-ready design system now being used to prototype Payment Waiver and Hardship as MTF Connect features.
