Loansifter Mobile: 40 Desktop Fields, 30 Seconds in the Field
End-to-end iOS ownership for a native broker pricing app. Research-driven information hierarchy, progressive search form, and proactive requirements definition.
The Problem
Brokers using this platform’s desktop pricing engine need to respond to rate requests fast. During client meetings. At closings. On weekends. The desktop tool has 40+ search fields and result screens built for a monitor. Brokers were either delaying responses and losing business, or struggling through the desktop site on their phones.
This wasn’t about making a mobile version of the desktop tool. The desktop serves a 10-minute pricing session at a desk. Mobile serves a 30-second interaction in the field. Every design decision had to be filtered through that difference.
What I Owned
I led the iOS application end-to-end: discovery research, information architecture, interaction design, visual design, development handoff. Weekly cadence with product managers. Direct coordination with legal on regulatory requirements.
Product was slow to deliver specs. So I defined requirements based on research findings and filled gaps independently. By the time I brought recommendations to Product, the thinking was done — options, rationale, supporting evidence. Their feedback refined the final scope, and we moved forward.
Decisions That Shaped It
What goes on a 4-inch card?
The desktop results view spreads a dozen data points across a wide screen. On mobile, each card needs to answer one question fast: is this product worth looking at?
I ran 8 discovery interviews and a second round of solution validation testing multiple card layouts. The goal was specific: which data points do brokers actually scan first, and how should they be ordered? A survey of ~800 respondents refined the hierarchy further.
Price won. It gets a color-coded indicator (green or red) for instant signal. Rate, APR, and P&I follow in a structured left column. The broker’s eye runs down the left edge and evaluates dozens of products in seconds.
One constraint shaped the layout further. APR and Rate must receive equal visual treatment due to regulatory requirements. I flagged this proactively based on a previous compliance issue on another product and coordinated with legal before it became a problem. That’s why Rate and APR share typographic treatment in the left column, with Price differentiated through color rather than size.
Structuring 40+ fields for speed
The desktop search form has 40+ fields across loan, borrower, property, and product characteristics. Porting that to mobile was a non-starter.
The alternatives — a single long scroll, a wizard-style multi-step flow — either buried fields or slowed users down. I restructured the form into four collapsible categories with horizontal tab navigation for quick jumps between sections. Essential fields surface first. Advanced parameters are available but don’t block the common case.
I also worked with Product to reduce which fields were required. A broker in the field can fire off a rough search with minimal input and refine later. A broker at their desk can use the full form. Same tool, two speeds.
The Visual Direction Conflict
Product wanted increased prominence on certain result elements. I advocated for restraint. Lower data density, better scannability across a feed of 100+ results.
The resolution: increased prominence on the data points that research validated as most important (price, rate) while keeping the overall card footprint clean. Product got the visual weight they wanted. Users got cards they could actually scan. Neither side got steamrolled — Product saw their priorities reflected in the final decision, and the working relationship came out stronger for it.
That last part matters. Resolving visual disagreements without burning bridges is a skill that doesn’t show up in mockups. It shows up in whether people want to work with you again.
Depth When You Need It
When a broker taps into a product, they need the full picture: rate, APR, price, discount/rebate, lender fees, P&I, total payment, adjustments, rate sheet.
Total Adjustment shows the summary by default. Detailed adjustment reasons expand on tap. The Rate Sheet at the bottom lets brokers compare across lock periods without leaving the view. The pattern is consistent throughout the app: show what matters first, give full depth one tap away.
What I Learned
Requirements are something I co-author, not something I receive. On this project, specs were incomplete for weeks. I used research to fill the gaps and brought Product a more informed scope than they would have written themselves. That’s how the project stayed ahead of timeline despite the gaps.
Mobile isn’t a smaller desktop. It sounds obvious until you’re staring at a 40-field form trying to decide what to cut. The answer isn’t to cut fields. It’s to restructure around intent: fast search for the field, deep search for the desk. Same data, different moment.
What’s Next
Targeting Q2 2026 beta. Post-launch: voice-assisted search input (currently being validated on a sister product), expanded scenario management, and iteration based on adoption data.