NF Broker Portal
Role: UX/UI Designer on the NF broker portal, a FairSquare contract. I own the product requirements and design the product end to end, writing decision-ready specs and Given/When/Then acceptance criteria before anything gets built.
The portal is where brokers submit loan applications for their small-business clients and track each deal to funding. Funding is high-stakes and detail-heavy, so the product has one job: a broker should always know where every deal stands and exactly what it needs next.
My bet is a requirements-first workflow. I decide every flow and state in Confluence up front, which compresses the design-to-engineering handoff and keeps the build from looping back for rework.
Outcome
The full broker deal lifecycle specced, from application and document intake through review, stipulations, and funding, with acceptance criteria signed off for every state before design starts.
A requirements-first workflow that resolves edge cases and tradeoffs before the build, not after.
AI-assisted spec-to-build: structured prompts across Cursor, Figma Make, and Claude take signed-off requirements to production-ready product fast.
See it in action

The problem
A broker runs many deals at once, each moving through submission, review, approval, contract, and funding. The hard part isn’t any single step, it’s holding the whole picture: which deals are stuck, what each one needs next, and which stipulations are still open. When that’s unclear, deals stall and brokers burn time chasing status.
The hard part isn’t any single step, it’s holding the whole picture: which deals are stuck and what each one needs next.
How I worked
I owned the requirements and designed against them, keeping the team aligned on one outcome:
Requirements first. I wrote Given/When/Then acceptance criteria for every flow and state in Confluence before design, so decisions got made once and weren’t relitigated mid-build.
Edge cases early. I surfaced the messy states (errors, missing documents, open stipulations) and framed the options for Product, so tradeoffs were resolved up front.
AI as a force multiplier. Structured prompts across Cursor, Figma Make, and Claude took the signed-off specs to production-ready product fast.
1. A pipeline you can read at a glance
The applications view is the broker’s home base. I designed it around status: a count of deals in each stage across the top, then a table where stage, requested and approved amounts, last update, and open stipulations are all scannable in one pass. The goal was to answer “what needs me today?” without opening a single deal.
The applications view is built around status, so a broker answers “what needs me today?” in one scan.

2. One place for the whole deal
The loan detail pulls a single application together: requested, approved, and term up top, a stage tracker from Submitted to Funded, and a clear flag when stipulations need attention. Overview, Stipulations, Documents, and Messages live in tabs, so a broker gets from “where is this?” to “what do I do next?” without leaving the screen.
The loan detail puts one deal in one place, moving a broker from “where is this?” to “what do I do next?” in a single view.
3. Submission without the rework
New applications run through a short, guided submission: business details, the submitting agent, and a document upload with the required items spelled out. Writing the acceptance criteria for each state first (empty, error, in-progress, complete) is what kept the build from looping back once it reached engineering.
Writing the acceptance criteria for every state first is what kept submission from looping back once it reached engineering.
4. Reporting brokers actually use
Brokers are paid on funded deals, so reporting had to make commissions obvious: paid, pending, and processing totals up top, then a per-deal breakdown of funded amount, term, rate, and commission. It turns “what am I owed?” into a glance.
Reporting puts commissions front and center, turning “what am I owed?” into a glance.

The result
The payoff is a portal a broker can move through with confidence: the pipeline shows what needs attention, each deal has one place with the full picture, and every flow was specced to its edge cases before it was built. Deciding the hard states first, in writing, is what let the work ship without looping back for rework.
The lesson I keep coming back to: in a high-stakes workflow, clarity is the feature. Settle the messy states up front and the rest of the product gets easier.
A portal a broker can move through with confidence: the pipeline shows what needs attention, and every state was specced before it was built.
The lesson: in a high-stakes workflow, clarity is the feature. Settle the messy states up front and the rest gets easier.
