Lender Portfolio —
an analytics product for bank lenders

MountainSeed is an appraisal-management and analytics platform built for commercial real estate (CRE) professionals. When I came onto the the product team, a major expansion was being planned: extending the analytics platform to bank lenders — a new user type with workflows, mental models, and reporting needs distinct from the platform's existing appraiser audience.

The initiative was called the Lender Portfolio: a dedicated, subscription space where portfolio managers, credit analysts, and loan officers could consolidate and analyze their collateral properties. My job was to take that brief from an open-ended business goal to a validated, build-ready design.

Joining a fintech team with no background in commercial real estate or appraisal meant a steep learning curve before I could make sound design decisions. Rather than treat research as a single phase, I approached it as a continuous thread. The goal was to reach design-ready domain fluency quickly, then keep validating assumptions as the work progressed.

I built a foundation on three fronts: external study of CRE fundamentals, appraisal processes, and the commercial loan lifecycle; internal deep-dives into MountainSeed's historical artifacts and prior lender research; and stakeholder interviews with Product Manager Rosha Caines and UX Director Bethany Stolle.

Drawing on the team's existing lender research, we narrowed a broad audience to two roles: Credit Analysts as primary, and Loan Officers / Relationship Bankers as secondary.

Credit analysts were the priority for two reasons. Their responsibilities overlap with appraisers, so they could reuse tools MountainSeed had already built. Additionally, the property metrics they need would let the company utilize more proprietary data, opening a path to functionality the platform hadn't yet considered. Loan officers had narrower, simpler needs, so designating them secondary let us build faithfully for both without overextending the team.

From there I ran initial explorations independently, then worked with Bethany and Rosha to lock the feature requirements, data requirements, and key workflows. I wrote seven use-case scenarios — two designated as "key" — to give every major design decision a narrative grounding in a real user goal.

Our work in this "define" phase revealed three services the portfolio needed to deliver:

With our scenarios in place, I treated each as a narrative — a user's goal, needs, and behavior told in the context of the product — and translated the two key scenarios (plus three validation scenarios) into flowcharts, iterating on them with Bethany and Rosha. Once the flows were solid, I moved into UI, starting with hand-drawn sketches to explore information architecture and layout cheaply before comitting resources.

The first iteration tested whether all three services could live on a single portfolio page. Kept deliberately low-fidelity — but styled to MountainSeed's existing visual language to keep brand identity legible — it let users enter the portfolio to a map of their collateral properties, an analysis area, and a consolidated properties list below.

To shorten the learning curve, I borrowed interaction patterns from Microsoft Excel — applying Jakob's Law (users carry expectations from the tools they already live in) so analysts felt familiarity to the most prominent data analysis tool.

Consolidated properties lived below the dashboard with a card / list toggle. Because this area needed less functionality at this stage, I kept it a lower priority and concentrated exploration on the dashboard and its visualizations.

Holding all the workspaces on one page created competing demands on the user's attention. In the second iteration I split them into a tabbed interface to reduce cognitive load, and introduced a local navigation menu so users could control which insights were in view — freeing the dashboard to show deeper, more relevant visuals.

I also introduced market comparisons directly into the visualizations (benchmarking portfolio against market), and added properties actions like adding a property and viewing comparables. Card templates were still on the backlog, so those screens used placeholder content.

I also designed the export flow, with journeys originating from both areas. I set the map to be hidden by default and opened on demand into a split-screen via a button — applying progressive disclosure to prioritize core tasks like exporting and shorten the process of common workflows.

With the structure settled, I emphasized work on analysis workspace — the analysts' primary space, home to the most complex tasks and the least overlap with other roles, which made it our highest priority for upcoming usability testing. I deferred the properties and snapshot workspaces, keeping their screens low-fidelity rather than stopping work on them entirely.

Analysts need to run calculations, read visuals to inform strategy, and investigate the underlying data. That called for a workspace built around a primary visualization with controls to enrich it, supported by data augmentation and comparative layering.

Data visualization was never a single deliverable — it was an ongoing problem that shifted as the team learned what was technically possible. Getting it right meant working across three overlapping constraints: data-analytics principles, visualization-tool capabilities, and MountainSeed's actual property data. I held recurring sessions with senior data analyst Jake Gadbury to ground my research in the company's data and tools, and to review upcoming visualizations before I presented them in our weekly syncs.

The next iterations were shaped by usability testing. The headline finding: clients saw immediate value in the three-workspace model. An export-ready dashboard made it easy to deliver synthesized insight to executives; a consolidated properties area streamlined management and centralized property-level tasks like error reporting, detail edits, and running comparables.

In the analysis workspace I built out a Chart Actions panel for richer data augmentation, added a toggle to fitler proeprty type within the visuals, and introduced an "About Visual" panel describing each chart. Placing that description directly beside the chart applies the spatial-contiguity principle — related information sits together, so comprehension doesn't depend on memory.

Testing also clarified what the Snapshot workspace should communicate: visuals for portfolio diversity, composition, and perfromance. I added a table of insights broken out by property type, since metrics across types aren't comparable and shouldn't be read against one another. Because Snapshot's highest priority task is fast, simple export, I limited its filtering to geography and time frame — the only two controls users need to set how broad or narrow a view they want.

The Properties workspace already handled most workflows, but testing surfaced a new opportunity: error / ticket handling. Users told us property details routinely need to be adjusted, removed, or added to. I designed a side sheet ticket queue with three statuses — Pending, In Review, and Closed — so users could review active and past tickets, and added a flag affordance to mark any property attached to a ticket. Charts also gained a drill-down: selecting "See Property Data" opens the exact records behind a visualization. With this expedited flow, users could easily gather the property data informing a visual.

Heading toward a first release, weekly syncs with the analytics team — Technology, Data Ops, and Project Management — made one constraint clear: the visualization technology and data pipeline needed more time to mature. So I designed the v1 release to the reality of what could ship, scoping back the dynamic visualization features and deferring the ticketing queue to a later release, since it had to connect to existing systems.

That made the analysis workspace more static; instead of customizing visuals and switching through a tabbed interface, users see a visual for each data type on a single page. Showing one visual per data type kept the space dense, but it solved an inclusivity problem — every client, whatever their strategy, finds the view they rely on without having to configure it.

I also designed a pivot-table view for users who prefer reading metrics as a table over charts. To inform how analysts traverse and read pivots, I drew on AWS QuickSight's documentation on visual types; we didn't adopt QuickSight, but it let me design pivot tables our existing Tableau tooling could build.

Finally, I brought the map back to the top of the analysis view alongside a summary of the active parameters — a "Dashboard Overview" — so the filters applied to the visuals below are always visible. Now that the visuals were static, the workspace could support export like Snapshot, and exported material needed to communciate the variables affecting the output.

Once the prototype screens were final, my role shifted to supporting development: providing revised specs when dimensions or spacing needed adjustment, and testing implemented pages as soon as they were available.

I documented QA findings in structured reports — organized by area, date, and sub-section — and noted areas that passed review as well as those that didn't, so the project manager had a complete, auditable record of what had been checked.