Closing feature gaps, informed by clients I already knew.
Financial spreading — turning a borrower's raw financial statements into a normalized, analyzable format — is core, daily work for credit teams. I redesigned an earlier spreading tool from 2022 to 2024; now, on its successor platform, feedback from those same legacy clients is shaping the feature-parity work I'm doing today.
A feature gap, seen from both sides.
I stepped into this project mid-flight, after the original designer left the company. My scope: two new features, migrating clients off a spreading tool I'd designed myself years earlier — so their feedback on what it was missing directly shaped this work. Spreading normalizes a borrower's financial statements so ratios and risk can be compared over time; if the features I owned didn't close the gaps clients actually felt, feature parity would be a checkbox exercise.
Two patterns, each solving a real friction point.
Two feature patterns had to work well for clients to feel the new tool was actually better: threaded comments, and support for spreads with many statement periods.
Threaded comments
The old commenting was one-way once a spread moved to the summary view — the checker could read but not reply. The fix: maker and checker reply, resolve, and reopen threads together, at the cell, row, period, or full-statement level.
Loading large spreads
Spreads with many statement periods took a real, felt delay to load all at once. The fix: load the most recent periods by default, with earlier history available on demand — the common case stays fast.
Testing both patterns at once, not one at a time.
AI-assisted prototyping let me build working versions of both patterns and test them in parallel — comparing review models and loading thresholds in days rather than the weeks a design-to-build handoff would take. That speed also closed the ramp-up gap from stepping into a project already in flight.
- AI-assisted prototyping
- Parallel pattern testing
- Stakeholder feedback loops
Feature parity clients could actually see.
Working prototypes early meant stakeholders could react to real behavior well before a full build — closing the loop with the same clients whose feedback shaped the work.