Simplifying the interface without simplifying the work

01 / THE PRODUCT CONDITION

The complexity belonged to the work

Dealpath helps institutional real estate teams organise listings, deals and portfolio information. The engagement began with a broader product audit, but Connect Listings gave us a focused place to act on what the review had uncovered.

A listing can include units, square footage, year built, price guidance, building class, occupancy and investment profile. That density is not accidental. Acquisitions teams need it to judge whether an opportunity deserves attention.

Removing fields would have made the screen cleaner by making the product less useful. The design task was to make the information easier to interpret without pretending the work itself was simple.

02 / THE HIERARCHY

Give the decision a reading order

The original card gave too many fields similar visual weight. A user could find the information, but the interface offered little help in deciding what to read first.

The redesigned card created three recognisable zones: image and listing status; property identity and highlights; and core values for closer comparison.

The change was hierarchy, not subtraction. The same information remained available, but the first scan could now answer a more useful question: is this opportunity worth investigating further?

03 / THE WORKFLOW DECISION

One action carried the wrong assumption

Improving the card clarified the first decision. The more consequential problem appeared when a user selected Add to pipeline.

The existing route opened Create deal immediately. That made sense for a genuinely new opportunity, but not when the listing belonged to a deal already being tracked. The workflow asked for creation before it asked whether creation was necessary.

We reversed that order. The revised flow begins with Attach to a deal, where the user can search existing records and select a match. Create new deal remains available when there is no match, but it is a deliberate fallback rather than the default.

THE PRODUCT DECISION

Search existing records first. Create a new one only when there is no suitable match.

EVIDENCE BOUNDARY

This is a design decision, not a production outcome claim. The evidence shows that the proposed flow removed an assumption that made duplicate creation easier. It does not establish how duplicate rates changed after release.

04 / THE SCOPE DECISION

The rest was left alone on purpose

The listing experience supported four related actions: view the listing, add it to the pipeline, mark it as a comparable, or pass on it.

Only one contained the structural issue. We changed the add-to-pipeline path and largely preserved the comp and pass paths.

That restraint matters in mature software. Every familiar workflow carries learned behaviour, implementation effort and regression risk. A redesign should earn the cost of change. Here, the main pipeline action earned it. The others did not.

05 / THE COMPONENT CONSEQUENCE

One hierarchy across every view

The listing card also appeared in more than one context. The dashboard, map list and map-pin details offered different amounts of space, but they represented the same opportunity.

We kept property identity, status and core values recognisable across all three. The component could compress without changing the order in which the product explained the listing.

06 / WHERE IT STANDS

A buildable direction, not a measured outcome

The work was designed within Dealpath's existing system and technical constraints, with implementation remaining with the client's team. The material available to us documents the proposed interface and interaction decisions. It does not confirm which version shipped or establish a measured user or business result.

That boundary clarifies what the work proves: in a mature product, simplification is the separation of complexity the work requires from friction the product has accumulated.