Restructuring the configuration backbone of a loan management platform to reduce cognitive load, fix broken interaction logic, and scale for the future.
My Role
Lead Product Designer
Team
Annie Wang
Product Manager
Responsibilities
IA mapping & restructuring, UX audit & gap analysis, Interaction design & logic fixes, Page Structure System
Project Timeline
2 Months

Context
Mortgage Automator is a loan management platform for private lenders, anchored by two core products: Loan Origination (deal setup through funding) and Loan Servicing (payment collections, compliance, and portfolio management post-funding).
Company Settings is the configuration backbone of the entire platform. Every setting on this page directly affects how loans appear, how calculations run, when payments are collected, how documents are generated, and how stakeholders interact with the system. It is also the first page every new client is walked through during onboarding—making it both a critical first impression and a foundational setup step that determines how the platform behaves for that client’s business.
Problem
A settings page that had grown in complexity without growing in structure.
The existing Company Settings page had accumulated complexity over years of feature additions without a unifying structure. Settings were presented in a flat, single-level sidebar with 16+ items - no grouping by product, no hierarchy, and no indication of whether a setting belonged to origination, servicing, or general administration. Users had to mentally parse the entire list every time they needed to find or configure something.
Beyond the structural issues, individual settings contained broken interaction logic. Multiple settings used inverted checkbox patterns where unchecking a control revealed child options—the exact opposite of expected user behaviour. Other settings presented all options as flat, undifferentiated checklists with no progressive disclosure, forcing users to process every available option even when only a subset was relevant to their selection.
The downstream impact was tangible: increased support calls, heavier onboarding sessions, and frequent questions from both clients and internal teams. The settings page, intended to be a one-time configuration step, had become a recurring source of friction.
This was not a UI polish exercise. It was a structural redesign of the configuration backbone that the entire product depended on.
Jobs To Be Done
Three distinct user needs the original design failed to support.
The Company Settings page serves users with fundamentally different goals depending on their context. Understanding these jobs shaped every design decision that followed.
“When I’m onboarding a new client, I need to walk them through settings in a logical order so that setup is efficient and the client feels confident in the platform.”
“When I’m configuring a new loan product, I need to find and adjust only the settings relevant to origination without being distracted by unrelated servicing options.”
“When I need to change a specific setting months after setup, I need to get to it quickly without re-learning the page structure every time.”
These three jobs map to three distinct behaviours: exploration during onboarding, product-specific configuration during active use, and fast retrieval for experienced users. The original flat sidebar and broken interaction patterns failed all three.
Research & Discovery
The problems with Company Settings were well-known across the organization, but addressing them required understanding the specific pain points beyond surface-level feedback. Discovery drew from three sources.
Onboarding & Client Servicing Team Feedback
The CS team walked every new client through Company Settings during onboarding. Settings-related questions were a recurring theme in support interactions, and the team had developed informal workarounds and verbal guides to compensate for the interface’s lack of clarity. Their accumulated knowledge of where users got stuck provided the most direct signal of what needed to change.
Onboarding Call Observations
Sitting in on onboarding sessions for new client servicing employees provided a proxy for the new-user experience. Watching someone with fresh eyes encounter the settings page for the first time revealed the specific moments of confusion, the questions they asked, and the assumptions they made about where settings should live.
Product Expertise & Interface Audit
Working within the product daily had built deep familiarity with the settings page’s structural shortcomings. A systematic audit of every setting mapped current placement against logical groupings and identified broken interaction patterns, redundant steps, and opportunities to reduce cognitive load by consolidating related settings.
Process
The project began with a re-categorization framework provided by the Product Manager in the form of an Excel file mapping all settings into the new three-pillar structure. From there, the design process followed four stages:
01 IA Mapping
Mapped the PM’s re-categorization against the existing system to understand setting relationships, dependencies, and edge cases where settings touched multiple product areas.
02 UX Audit
Audited every setting on the page to identify broken interaction logic, unnecessary steps, and opportunities to consolidate related settings — reducing cognitive load without losing configurability.
03 Structural Exploration
Explored multiple sidebar structures, nesting depths, and navigation patterns. The initial design used a 3-level hierarchy, which was later expanded to 4 levels based on stakeholder feedback and user data.
04 Interaction Design
Redesigned individual settings with corrected logic, proper control types, progressive disclosure, and contextual feedback — iterating through multiple options for each complex setting before arriving at the final solutions.
Working files showing the IA mapping and UX audit in practice — the PM's re-categorization spreadsheet mapped against redesigned UI, with progressive disclosure and sub-header decisions flagged during the audit
Side-panel exploration board showing multiple structural iterations
The Accordion Decision
The initial design used accordions to manage the visual complexity of the expanded settings page—the logical choice for reducing visible content while maintaining structure.
During stakeholder reviews, the onboarding and CS team raised a critical insight: users had an established pattern of using Ctrl+F (browser find) to locate specific settings quickly. Accordions would break this behaviour entirely—browser search cannot find content hidden inside collapsed sections.
Based on this discovery, the accordions were removed, preserving the expanded layout that supported Ctrl+F as a power-user retrieval method. A dedicated search bar was proposed as a complementary retrieval mechanism for both new and experienced users (who hadn’t yet built Ctrl+F muscle memory) and experienced users (who could now search with more intelligence than browser find offered).
The result addressed two of the three jobs to be done directly: the new hierarchy supported exploration during onboarding, while search and Ctrl+F supported fast retrieval for experienced users.
Solution
Restructuring the page, fixing the logic, building for what comes next.
Information Architecture
The redesigned Company Settings page replaced the flat, product-agnostic sidebar with a three-pillar hierarchy aligned to how the platform and its users actually operate.
Loan Servicing organized by lifecycle stage — Repayment, Advances, Renewal, Discharge — not by setting type.
Administration Settings was stripped down to company-level essentials: Operating/Lending Company Setup, Application Logo, Main Letterhead, and Tax Report Settings. These are settings that apply globally across the platform and are typically configured once.
Loan Setup/Origination was organized into logical groupings that mirror the deal setup workflow: Property Fields, Loan Fields, Standard Origination Fees, Loan Underwriting, Payment Method & Calculations, Repayment Methods, Stakeholder Setup, Flow of Funds, Documents, Workflow Management, and Integrations. Each grouping contains its relevant sub-items, creating a clear mental model for users configuring how new loans are originated.
Loan Servicing was structured around the loan lifecycle rather than by setting type—a deliberate decision to align with users’ mental models. The four lifecycle stages—Repayment, Additional Loans/Advances, Renewal, and Discharge—each contain their own Payment Method & Calculations, Fees, and Document Configurations. This repeating pattern makes the structure predictable: once users understand how one stage is organized, they can navigate any stage intuitively. A dedicated Integrations section for servicing-specific tools completes the pillar.
A key IA decision involved settings that touch both products. Investor-related settings were split based on when they’re relevant in the workflow: Default Investor setup, fee configurations, and flow of funds sit under Origination (configured during deal setup), while Treatment of Investor Payments and statement settings sit under Servicing (relevant during active loan management). This workflow-aligned placement reduced the ambiguity that had previously forced users to search across unrelated sections.
This directly addressed the second job to be done — product-specific configuration without distraction from unrelated settings. Users configuring origination no longer had to parse servicing options, and vice versa.
Before and after comparison of the Information Architecture
Interaction Design
Restructuring the navigation was only half the work. A systematic audit of individual settings uncovered repeated anti-patterns — inverted logic, missing progressive disclosure, and scattered related settings — each addressed with consistent design solutions.
Inverted Checkbox Logic — Multiple settings used checkboxes where unchecking the control revealed child options, inverting expected behaviour. This pattern appeared across several critical settings.
Flow of Funds (Investors): The original presented all options as checkboxes with no separation between Origination and Discharge flows. The redesign replaced checkboxes with radio buttons for mutually exclusive choices (Lawyers pay vs. Lender pays), introduced progressive disclosure so child options appear only when the parent selection is made, and clearly separated the two flow types as distinct sections. Multiple structural options were explored before arriving at the final solution.
Flow of Funds- Before
Before
Flat checkbox list with no separation between Origination and Discharge flows. Inverted logic — unchecking checkboxes reveals child options. Users had no way to distinguish which settings belonged to which flow.
Flow of Funds - Iteration board + Final direction
Iteration 1
Introduced two parent checkboxes to group Origination and Discharge flows — didn't exist before. Checking reveals child options, fixing inverted logic. 'Via PAD' sits outside both groups.
→ PAD placement ambiguous — unclear which flow it belongs to.
Iteration 2
PAD nested contextually under each child option, resolving the ambiguity. Parent labels renamed to 'Origination/Discharge flow of fund.
→ Checkbox parents imply flows can be deselected — not a valid business action.
Iteration 3
Removed parent labels entirely. Flat list with correct radio buttons and progressive disclosure. No inverted logic.
→ Too close to the original problem — no visual separation between flows.
Iteration 4 - Final
Non-interactive section headers separate Origination and Discharge flows. Radio buttons for Lawyers/Lender pay. Progressive disclosure for child options. Mirrors the broader IA structure — Origination and Servicing as distinct categories
Investor Standby Interest: The same inverted pattern existed here, but with greater complexity due to three contribution models (Total Facility Upfront, Advances/Draws only, Loan-by-loan basis), each requiring different allocation rules. Four design options were explored. The final design uses radio buttons at the top level with contextual sub-sections that appear based on selection, and info icons for settings requiring additional explanation.
Investor Standby Interest - Before
Before
Unchecking 'Standby interest will always be allocated to our admin company' reveals child options — inverted logic. Single checkbox controlling complex allocation rules.
Investor Standby Interest - Iteration board + Final direction
Iteration 1
Radio buttons for three contribution models. Selecting reveals child options — core logic fixed. Greyed-out options show what exists.
→ Moved to Option 2 - Child options too limited — didn't reflect full allocation complexity.
Iteration 2
Full allocation methods surfaced per model. Correct progressive disclosure, but three levels of nesting creates decision fatigue.
→ Moved to Option 3 - Users had to click through each radio to discover what options existed.
Iteration 3
Contextual sections always visible — solves discoverability. Checkbox-driven activation per section.
→ Moved to Option 4 - Independent checkboxes implied both scenarios could be active — doesn't match either/or business logic.
Iteration 4 - Final
Radio selection drives contextual sections. Either/or logic reflected accurately. Info icons for domain-specific terms. Pattern adopted across similar multi-condition settings.
Investor Management Fee and Sales Tax: The redesign consolidated scattered settings into a single section with a master toggle pattern, dependency-based nesting, and contextual tooltips replacing inline descriptions.
Investor Management Fee and Sales Tax - Before
Before
Related settings scattered across different sections of the page. No progressive disclosure, no grouping. Redundant inline Save button for a page where users save all settings at once.
Investor Management Fee and Sales Tax - Iteration board + Final direction
Iteration 1
Consolidated all settings into one section. 'Enable management fee' as master toggle reveals child options. Removed redundant Save button. Contextual description moved to tooltip — available on demand, not taking permanent space. 'Apply sales tax' revealed on check with percentage field.
→ Moved to Option 2 - Dependent and independent options at the same depth — hierarchy doesn't express the dependency chain.
Iteration 2 - Final
Three nesting levels matching actual dependencies: master toggle → default fee with currency selector → sales tax. 'Apply sales tax' visible but disabled rather than hidden — reduces click-depth while maintaining discoverability. Independent options stay at first child level, not buried under unrelated toggles.
Disconnected Previews & Outdated Inputs
Colour Scheme Selection: The redesign replaced free hex input with curated colour palettes per scheme, a 'Custom' option for full control, and a live template preview.
Colour Scheme Selection - Before
Before
Hex codes displayed in dark filled boxes resembling static labels — no affordance indicating they're editable.
Decorative colour wheel serves no functional purpose.
Weak connection between colour selection and template output.
Colour Scheme Selection - Iteration board + Final direction
Iteration 1
Clear separation of colour swatch and editable hex input. Live template preview added. Still allows any hex value — risk of off-brand or inaccessible combinations.
→ Moved to Option 2 - Fixed the interaction, didn't address error prevention.
Iteration 2 - Preferred
Pre-defined palettes replace free hex input — curated, tested combinations prevent errors. 'Custom' option preserves full control. Live preview retained. Guardrails with an escape hatch.
Logo & Letterhead Upload: Raw browser file inputs with no upload feedback — the drag-and-drop area remained static after upload with no visual confirmation. Preview and guidelines opened in separate tabs, breaking the user flow. The redesign consolidated upload and preview into a single container with full state coverage, inline actions, and a guidelines overlay within the preview modal
Logo & Letterhead Upload - Before
Before
No upload feedback, no inline preview, no error handling. Raw browser inputs and separate tab links for preview.
Logo & Letterhead Upload - After
After
Full state coverage with inline preview, drag-and-drop, error handling, and a guidelines overlay — branding setup that matches the product's quality.
Scalable Page Structure
The redesign surfaced a need that extended beyond Company Settings: a scalable structural framework for organizing dense, form-heavy content across the platform. Rather than solving only for the immediate project, a page structure system was designed that defines how content should be organized at one, two, three, and four levels of depth.
Each level has clear visual differentiation through nesting, indentation, and container treatment. The system accounts for different content patterns: simple field groups, sub-sections with their own fields, repeatable sections with “+ Add” functionality, and “Expand All / Collapse All” controls for multi-item sections.
These templates became part of the Pattern Library being built concurrently, creating a reusable framework that any future settings page—or any dense form-based page in the product—could follow. The Pattern Library provided foundational components and structural patterns; the Company Settings project stress-tested and extended those patterns in a real, high-complexity product context. Each project strengthened the other.
Trade-offs and Pragmatic Decisions
Shipping a project of this scope within 6–8 weeks of design required deliberate trade-offs. The goal was to deliver the highest-impact changes on schedule while leaving room for iteration.
3-Level to 4-Level Depth
The initial sidebar structure used three levels of nesting. During stakeholder reviews, feedback supported by user data indicated that a fourth level was necessary to properly represent the Loan Servicing lifecycle hierarchy. While deeper nesting carries interaction risks, the structured visual treatment at each level (distinct indentation and background treatment) and the sidebar’s persistent wayfinding made the added depth navigable. This was approved as the right first step, with the understanding that the structure could evolve based on user feedback post-launch.
Simplified Versions for Timely Delivery
To meet the development timeline, certain settings shipped with simpler versions of the proposed design. The Colour Scheme selection shipped with a functional but less polished version of the curated palette approach. The Letterhead preview shipped without the full inline guidelines toggle experience. These were documented as planned enhancements for subsequent iterations, ensuring nothing was lost.
Preserving Ctrl+F Over Ideal Patterns
Removing accordions in favour of an expanded layout was a trade-off between visual tidiness and respecting established user behaviour. The expanded layout is longer and requires more scrolling, but it preserves the Ctrl+F search pattern that users depended on. A dedicated search bar was later proposed as a complementary retrieval mechanism, recommended for future iteration.
Impact
The redesigned Company Settings page shipped in full and is live in the product today.
For Users
The restructured settings page reduced cognitive load by organizing settings around the user’s mental model — grouped by product area and workflow stage rather than by arbitrary categories that had accumulated over time. Fixed interaction logic (corrected control types, proper progressive disclosure) eliminated recurring confusion points that had previously generated support queries and slowed onboarding.
For the Business
The revamped Company Settings page streamlined the onboarding experience, reducing the time and effort required to walk new clients through the configuration process. The client servicing team had a more intuitive settings structure to reference when supporting clients, and the reduction in settings-related confusion contributed to smoother daily operations
For the Product
The three-pillar hierarchy and repeating lifecycle pattern within Loan Servicing created a predictable framework for future settings — new stages or configuration areas slot in without restructuring existing flows. This structure also informed multi-level workflows beyond settings, giving the product team a proven model for organizing complex, nested content across the platform.
Reflection
This project reinforced that settings pages are systems problems, not interface problems. The visible transformation—a restructured sidebar, cleaner layouts—is the surface. Underneath, the work required information architecture, interaction logic auditing, progressive disclosure design, scalable component thinking, and constant negotiation between ideal solutions and shipping realities.
With more time and resources, direct user testing on the new structure would have validated the IA decisions with quantitative data. A purpose-built search bar remains a recommended next step — contextual search that surfaces related settings and reinforces the new hierarchy over time. Settings pages are where product complexity meets user patience. Getting them right isn't glamorous work — but it's the work that determines whether a platform feels considered or cobbled together.



























