Broker Loan Editing Workflow

Impact and Outcomes

✅ Reduced Support Tickets: Initial phases projected to reduce edit-related tickets by 5–10%, saving hundreds of hours annually.
✅ Broker Empowerment: Improved control over loan details, reducing delays.
✅ Operations Efficiency: Freed up internal teams to focus on complex issues.
✅ Design System Alignment: Established reusable patterns for future Loan Edits phases.

‍

Problems

• No Edits Post-Registration: Brokers could not update critical loan details (assets, liabilities, employment/income, purchase price) after registration but before underwriting.
• High Support Volume: Thousands of monthly support tickets required manual edits by Rocket staff.
• Slow Loan Process: Brokers and borrowers experienced delays when corrections were needed.
• User Confusion: Brokers didn’t always understand what could or couldn’t be changed, leading to errors and frustration.

‍

Project Goals

• Empower Brokers: Enable self-service edits of key loan details before underwriting.
• Reduce Support Load: Lower the number of support tickets for manual data edits.
• Improve Data Quality: Reduce incorrect or incomplete information entering underwriting.
• Clarify Limits: Clearly communicate which fields can be edited and when.

‍

Research and Requirement Gathering

To understand the problem in depth and define scope, I collaborated closely with Product Management, Engineering, and Operations:

• Support Ticket Analysis: Reviewed categories of manual edit requests to identify highest-volume fields needing edits.
• Operations Interviews: Partnered with frontline support staff to understand workflow pain points and high-friction broker interactions.
• Engineering Feasibility: Aligned on data model and workflow constraints, identifying which fields could realistically support editing in the pre-underwriting phase.
• Regulatory Considerations: Ensured compliance with investor and underwriting guidelines on editable data.

This research defined the Minimum Viable Scope for Phase 1, while informing a roadmap for future enhancements.

‍

Design and Redesign

The Loan Edits Epic was structured in multiple phases, with each phase expanding broker editing capabilities and increasing complexity.

Phase 1

✅ Non-Mortgage Liabilities
‍
Phase 1 laid the foundation for all future Loan Edits work. It established the navigational structure and engineering patterns that would support editable data in the broker portal, delivering consistent UX and easing future development.

‍

Phase 2

✅ Assets
✅ Combined Employment and Income page
✅ Mortgage Liabilities
✅ Real Estate Schedule

Phases 2 and 3 were where I led design efforts for more complex, interdependent loan details:

• Inline Editing Patterns: Developed consistent, intuitive UI for brokers to update multiple fields within a single, familiar page layout—reducing learning curve and errors.
• Employment/Income Combination: Simplified two separate workflows into one cohesive page, balancing broker expectations with system validation requirements.
• Mortgage Liabilities and Real Estate Schedule: Required deep alignment with engineering on data models and edge cases (e.g. property types, multi-unit structures).
• Validation Rules: Designed guardrails that enforced business rules without frustrating brokers, including clear error messaging and state changes.
• Scope Management: Negotiated compromises when engineering constraints limited ideal UX, documenting design debt for future improvements.

These pages represented the bulk of the editing work, making broker workflows much more self-serve while aligning to compliance needs.

Phase 3

✅ Flip to Purchase Conversion
✅ Edit Loan Amount and Purchase Price
✅ Regenerate and Send Disclosures

‍

Phase 3 was the most complex and high-value phase:

• Flip to Purchase Conversion: Enabled brokers to convert a TBD loan to a purchase loan by collecting new property details. This required coordinating updates across multiple application pages, ensuring field-level validation, and maintaining a seamless experience without introducing errors that would delay underwriting.
• Skipper vs. No-Skipper Testing: Led design explorations and user testing to evaluate whether brokers could skip non-required fields or should be forced to complete all required data in one flow. This decision balanced speed and broker flexibility with the need for underwriting-ready data.
• Editing Loan Amount and Purchase Price: Tackled engineering constraints that made even seemingly simple edits technically complex. Worked with engineering to scope a viable MVP that delivered real value while planning future iterations.
• Regenerate and Send Disclosures: Designed workflows to manage regulatory complexity. Edits in this phase often required triggering new compliance documents. I partnered with operations and engineering to clarify triggers, manage timing expectations, and ensure brokers understood the requirements.
• Change Management: Drove alignment across Product, Engineering, and Operations to ensure feature prioritization, MVP scope definition, and phased delivery strategy.

‍

Design System Context

An added layer of complexity throughout this work was navigating our fragmented design system landscape.

While our consumer team uses the newer R4 design system, the broker portal was split between SPARK (our oldest) and RDS6 (intermediate). All Loan Edits pages were designed in RDS6, intentionally moving us away from SPARK and toward a more modern, maintainable system. This work required constant alignment with engineering to ensure consistency and plan for incremental migration without disrupting the broker experience.

‍

Constraints and Tradeoffs

Designing Loan Edits required extensive scoping conversations with Engineering, Product, and Operations to balance broker needs with technical feasibility and business priorities.

• Data Model Limitations: Some asset types that Rocket’s internal support staff can add aren’t supported in the broker-facing application. We chose to make these records read-only for brokers to avoid errors or incomplete submissions, while ensuring the experience still provided full visibility into the loan file.
• Validation and Business Rules: We needed to carefully define what fields could be edited, when they locked, and how changes impacted underwriting. This required close alignment with compliance and operations teams to reduce risk while improving broker flexibility.
• Engineering Bandwidth: Tight delivery timelines and limited capacity meant prioritizing MVP scope for each phase.

A good example of a design tradeoff emerged during the Regenerate Disclosures feature:

• My initial designs included a preview page where brokers could review the new disclosure package before manually sending it to the client portal.
• Engineering flagged that breaking this process into separate steps would require significant new development work.
• To keep delivery viable, we revised the flow to handle regeneration and sending automatically in one step. We added a confirmation modal to clearly inform brokers that selecting "Regenerate Disclosures" would immediately generate and send the updated package to the client portal.

‍

These kinds of decisions were documented as design debt for future exploration, ensuring we shipped meaningful improvements quickly while staying transparent about opportunities to enhance the experience later.
‍

Flip To Purchase Feature (In Progress)

One of the most complex and high-value features in the Loan Edits Epic is TBD to Purchase Conversion.

Problem: Brokers with a TBD loan often need to update the loan to include a property address and details once the borrower goes under contract. Previously, this required support intervention and multiple back-and-forth steps, with some users finding it easier to start over as a purchase loan, creating duplicates in our system.

Goal: Allow brokers to convert TBD loans to purchase loans self-serve, reducing support volume and broker effort.

Design Challenge: Brokers must provide new data across multiple screens. We explored:

• Skipper vs. No-Skipper Flows: Whether to allow brokers to skip fields or require full completion.
• Field State Management: How to clearly indicate which fields were required or editable in conversion mode.

Status: User testing is underway to determine which approach best balances broker speed and data quality. Early feedback has highlighted user expectations around required fields and seamless handoff to underwriting.

‍

Research and Testing

For launched features, we:

✅ Reviewed Support Ticket volume post-launch.
✅ Conducted moderated usability testing.
✅ Monitored broker feedback channels.

Key Learnings:

• Brokers valued inline edits over separate flows.
• Clear field state (editable vs. locked) reduced errors.
• Support ticket volume declined ~5% for Assets and Liabilities edits after launch.

‍

Conclusion

Loan Edits represents a significant step toward a more broker-friendly, efficient Rocket Pro experience. Despite tight timelines and engineering constraints, our phased approach allowed us to deliver real value while laying the groundwork for continued improvements.

The ongoing Flip To Purchase work demonstrates our commitment to solving complex broker workflows and shows my ability to lead design strategy through ambiguous, high-impact problems.