01
Overview
The Problem
Servicing clients were migrating to Haven while core, regulated servicing functionality was still being built. In the interim, borrower workflows were routed back to legacy systems, creating a fragmented experience and raising questions about Haven's ability to fully support complex servicing use cases.
Why It Mattered
Mortgage servicing is highly regulated. Errors in servicing workflows can lead to fines, lawsuits, or loss of licensure. Without clear, compliant replacements for legacy functionality, clients needed confidence that Haven could eventually support borrower use cases without introducing regulatory or operational risk.
Who This Affected
Servicing clients responsible for operating compliantly at scale, along with internal product, implementation, and support teams managing parallel systems during migration.
Success Criteria
- Demonstrate that Haven could support core borrower servicing use cases compliantly
- Reduce reliance on legacy systems during migration
- Build client confidence that Haven could replace legacy servicing workflows without exposing them to regulatory risk
02
Context & Constraints
Constraints
Mortgage servicing is highly regulated. All designs needed to meet strict compliance requirements and withstand legal scrutiny. At the same time, requirements evolved as the roadmap shifted and client understanding of future-state workflows matured.
Known Risks
If designs failed to accurately reflect compliance requirements or real servicing scenarios, clients could lose confidence in Haven's ability to replace legacy systems. There was also risk that work would stall or be deprioritized as dependencies shifted, leaving designs unused or partially implemented.
Dependencies
Progress depended on close collaboration with the servicing client across payments, escrow, legal, and customer support. Outcomes were also shaped by internal product strategy decisions, engineering capacity, and evolving third-party vendor partnerships, particularly around payments.
Tradeoffs
We prioritized clarity, compliance, and stakeholder alignment over speed to production. Several designs were taken to high fidelity and engineering readiness even when implementation timing was uncertain.
Stakeholders
Servicing clients focused on maintaining compliance and minimizing regulatory risk while migrating off legacy systems. Internal product partners balancing client commitments, evolving roadmap priorities, and long-term platform strategy. A constrained engineering team supporting this work alongside other critical platform initiatives.
03
Approach
Use design to reduce risk early
Servicing clients were migrating to Haven while core functionality was still being defined. Rather than waiting for requirements to stabilize, we used design as a way to surface risk early and align on how complex, regulated workflows would need to function in the future.
Work directly with domain experts
We partnered closely with client stakeholders across payments, escrow, legal, and customer support. Through frequent working sessions, we reviewed real servicing scenarios, compliance requirements, and edge cases, using design artifacts to pressure-test assumptions and resolve ambiguity before it reached engineering.
Make the future state concrete
Because compliance and trust were central concerns, designs were taken to high fidelity. These artifacts gave clients and internal teams a clear, defensible reference for how Haven could eventually replace legacy servicing workflows without introducing regulatory risk.
Design for alignment, not just delivery
In many cases, the primary value of the work was not immediate implementation. The designs helped bridge the gap between idea and reality, align stakeholders across teams, and build confidence that Haven could support complex borrower use cases compliantly at scale.
04
Design & Execution
The goal of this work was to replace legacy servicing functionality with compliant, migration-ready designs that clients could trust. We focused on the highest-risk servicing areas first, using concrete design artifacts to clarify requirements, surface edge cases, and align stakeholders before implementation.
Core servicing modules
Fix 01 — Payments
How might we support mortgage payments without introducing compliance risk?
Why it matters: Payments are one of the most regulated and error-prone areas of mortgage servicing. Incorrect handling of payment status, timing, or allocation can expose servicers to fines, disputes, or legal action. Clients needed confidence that Haven could eventually replace legacy payment workflows without ambiguity.
What changed: We designed future-state payment flows that reflected real servicing rules and edge cases, including status states, payment timing, and borrower expectations. Designs were reviewed directly with client payments and legal teams to ensure accuracy and defensibility, even as implementation timing remained uncertain.
Fix 02 — Escrow
How might we make escrow balances and activity understandable without oversimplifying them?
Why it matters: Escrow is a frequent source of borrower confusion and support calls. At the same time, escrow calculations and disclosures must follow strict rules. Any attempt to simplify the experience had to preserve accuracy and compliance.
What changed: We redesigned escrow views to clarify balances, components, and changes over time, helping borrowers better understand what they were paying for and why. These designs gave clients a clear model for how escrow information could be presented transparently without compromising compliance.
Fix 03 — Specialized loan types
How might we support non-standard loans without fragmenting the platform?
Why it matters: HELOCs and construction loans introduce additional complexity and edge cases that legacy systems handle differently from standard mortgages. Without a clear approach, these loan types risked blocking migration entirely.
What changed: We designed flexible servicing patterns that could accommodate specialized loan behaviors while remaining consistent with the broader platform. These designs helped clients see how Haven could support more complex loan products over time without building one-off solutions.
05
Outcomes
Not all servicing modules shipped immediately, but the work achieved its primary goal: helping servicing clients see that Haven could realistically replace legacy systems without introducing compliance risk.
Several areas shipped and began supporting real borrower use cases. Settings and preferences launched and established a foundation for account-level control. Escrow and payments shipped in part as Haven integrated with a third-party servicing backend, enabling progress without taking on the risk of building a full system of record.
This approach enabled faster progress and helped shape Haven's platform-integration strategy, but reliance on an external backend limited available data. As a result, some shipped experiences represent an early V0.5 rather than the intended end state.
Even so, the designs aligned stakeholders, guided integration decisions, and provided a clear reference for future expansion. They continue to inform conversations about expanding data access and reclaiming more servicing functionality within Haven over time.
06
Reflection
This work reinforced that in highly regulated and complex domains, design artifacts are often tools for conversation more than answers. Prototypes and mocks were rarely about getting something right the first time. Instead, they created a shared space to explore assumptions, test interpretations, and surface gaps in understanding across teams.
Much of the value came from iteration. We moved fluidly between one-to-one representations of legacy behavior and more aspirational North Star concepts that assumed fewer data constraints. These shifts helped everyone involved better understand how servicing workflows functioned today, how data powered them, and what a better future experience could look like.
The process was intentionally collaborative. Rather than operating in a contractor-style handoff model, we worked alongside client stakeholders to co-design solutions, learn together, and refine ideas in real time. Over time, this approach helped build trust—not just in the designs themselves, but in Haven's ability to navigate complexity, ask the right questions, and partner effectively in a challenging domain.
Ultimately, the work showed that progress in complex systems is rarely linear. By using design to facilitate learning, alignment, and trust, we were able to move forward even when constraints, dependencies, and data realities made perfect execution impossible.