Designing a deal, not a platform
Overview
Reframing commercial lending around a single mental model. I restructured the product around the deal as its central object, connecting previously fragmented workflows across underwriting, servicing, closing, and platform administration.
Industries
Year
2026
Reframing commercial lending around a single mental model
Bridge is a commercial lending platform connecting businesses seeking financing with institutional lenders. Over time, the product had grown across more stages, users, and workflows, but its underlying structure had not evolved at the same pace.
The result wasn't simply a complicated interface. The product was representing the same financing journey as several different things.
A borrower created an RFP. A lender responded to it and entered a Deal. Documents lived inside a Deal Room. Due diligence had its own area. Each concept made sense individually, but together they fragmented something users experienced as one continuous transaction.
The challenge became less about improving individual screens and more about deciding what the product should consider a Deal in the first place.
Finding the underlying problem
I mapped the platform across its different users and stages of a financing request, looking at how concepts related to one another rather than treating each screen as an isolated destination.
That revealed a recurring pattern: the product was confusing identity with state.
A financing request changes throughout its lifecycle. Lenders respond to it, documents are collected, underwriting happens, terms evolve, and eventually the transaction closes. Its state changes continuously, but its identity doesn't.
The software was doing the opposite. An RFP became a Deal. Due diligence became another area. Documents became a Deal Room. Users were still working on the same financing request, but the product kept renaming and reorganizing it.
The work was progressing. The software was renaming.
That became the central design problem.
Old architecture and navigation (navigating from RFP's to Tasks). Because the platform treated different Deal states as separate concepts, they were spread across five different areas.
The Deal becomes the central object
Instead of treating each stage as a separate concept, I redesigned the product around the Deal as the persistent object throughout the financing lifecycle.
This wasn't simply a naming change. It changed how information and workflows could be organized.
The Deal became the place where the different aspects of a transaction belonged: its summary, lender responses, files, tasks, participants, and eventually the workflows associated with later stages of the lifecycle.
This gave the product a stable mental model. Users could move through changing stages without having to learn a new conceptual structure each time the transaction progressed.
The distinction was simple:
The Deal stays the same. Its state changes.
That principle became the foundation for the navigation and information architecture that followed.
New information architecture - five different platform areas become one
From pages to a workspace
Once the Deal became the central object, I treated it less like a destination and more like a persistent workspace.
The old experience made different parts of the transaction feel like separate places. The redesigned structure kept them within the same context, allowing users to move between different aspects of a Deal without feeling like they had left it.
This also meant removing concepts that existed primarily because of the platform's internal history.
One example was the Deal Room. It described a collaborative area where documents were stored, but users weren't thinking about entering a "Deal Room." They needed to find or manage their Files.
Changing the terminology was small, but the reasoning behind it was broader: wherever possible, the interface should use concepts people already understand rather than making them learn the product's vocabulary.
The same principle applied to the structure itself. Files, tasks, lender responses and other capabilities didn't need to become separate destinations simply because they were separate features. They could remain different aspects of the same Deal.
Rebuilding navigation around hierarchy
With the Deal established as the central object, navigation became a question of hierarchy rather than simply finding better places for pages.
The platform needed to distinguish between different levels of context: the global product, the current Deal, and the work happening inside it.
I explored different ways of expressing that hierarchy, including more traditional top navigation and dashboard-driven structures. They could work for the product as it existed, but they became increasingly fragile as the platform expanded.
The roadmap was already moving beyond the original origination workflow, with more operational stages and capabilities being introduced. A navigation system that worked for a handful of sections would quickly become difficult to maintain as the Deal accumulated more information and workflows.
The resulting structure used layers of context. Global navigation established where users were in the platform, while contextual navigation kept them oriented within the selected Deal. More focused interactions could happen in temporary spaces without forcing users to abandon that context, while complex workflows could take over the full screen when they required deeper attention.
The goal wasn't simply fewer clicks.
It was less context switching.
Users shouldn't have to reconstruct where they are every time they move from one aspect of a Deal to another.
The new navigation levels
The complete architecture and wireframes for each persona (admin, lender, and borrower), organized by navigation level
A model that could grow with the product
The value of the new structure went beyond making the existing platform easier to navigate.
As Bridge continued evolving, the product expanded beyond origination into underwriting, closing, and servicing. The UI changed significantly as these capabilities were introduced, but the underlying Deal model could remain intact.
The work within each stage was different, with different users, workflows, and interfaces. What remained consistent was the relationship to the Deal: the same transaction moving through different stages of its lifecycle.
This was an important validation of the architecture. The goal wasn't to predict exactly what Bridge would become, but to create a model that could accommodate the product as it grew.
The architecture evolved as Bridge expanded into underwriting, closing, and servicing, while the Deal remained the shared context.
More importantly, it shifted the product away from reflecting its own history and toward reflecting the user’s work.
Users don’t experience the sequence of decisions that created a product. They experience the continuity of their own work.
For Bridge, that meant preserving the identity of the Deal while allowing everything around it to evolve.
The result wasn’t a simpler version of commercial lending. It was a product that made its complexity easier to understand.