Replatforming Search
Optimizing Discovery for PropertyGuru
Role
Business Context
PropertyGuru's Search Results Page was the product's highest-traffic surface, and it had been extended incrementally for years across three environments — web, mobile web, and native app — without a shared design system. On the app specifically, the legacy sidebar drawer buried features like Home Value and Mortgages behind a menu most users never opened. The business needed to move onto Hive 2.1, the company's current design language, but this page carried too much revenue risk to treat as a routine visual refresh: it drives the inquiries that connect buyers and renters to agents, and any regression during the migration would be felt immediately by the business. Any redesign also had to work across every region PropertyGuru operates in, not just Singapore, which meant the same components would face different data shapes and edge cases market to market.
Strategic Decision
**Migration Safety vs. Feature Ambition**
Context: the team wanted to ship meaningful new capability — most notably map search — in the same effort as the platform migration. Combining both meant a bigger, riskier release; separating them meant shipping the new design system twice as slow.
Options: (1) ship the replatform and new features together in one release, or (2) replatform first with feature parity only, then layer in map search and other new capability afterward.
Trade-off: shipping together risked a harder rollback if something broke, since a failure could be caused by either the migration or the new feature. Shipping separately meant a longer overall timeline before users saw any new capability.
Decision: I recommended shipping combined, but gating it on a hard non-negotiable — no regression in lead generation or conversion — validated incrementally rather than only at the end.
Why: the business case for map search depended on the same underlying infrastructure work the replatform required anyway; deferring it would have meant doing overlapping technical work twice. The real risk was regression, not scope, so we controlled for that risk directly instead of avoiding it by descoping.
Design Principles
1. **Consistency Over Novelty** — every screen had to match Hive 2.1's existing patterns rather than introduce new ones, so the redesign wouldn't create a fourth inconsistent surface.
2. **Discoverability Over Density** — features previously buried in the drawer (Home Value, Mortgages, Find Agent) needed to be reachable in fewer taps, even if that meant a shorter list on screen at once.
3. **Zero Regression** — no ship, however improved, was acceptable if it reduced lead generation or conversion versus the legacy experience.
4. **Map as a First-Class Mode** — map search had to be a fully supported way to browse, not a secondary view bolted onto list search.
Key Product Decisions
**1. Navigation & search entry restructure**
Problem: the legacy drawer navigation buried features like Home Value, Mortgages, and Find Agent behind a menu most users never opened, and search itself required navigating into a separate flow.
Options explored: keep the drawer but reorganize its contents, vs. replace it with a flat, tab-based navigation and a dedicated search entry point.
Decision: replace the drawer with tab-based navigation and a unified search overlay.
Solution: a bottom tab bar (Home, Search, My Activities, More) replaced the hamburger drawer, and a new Search overlay let users search by MRT, district, or HDB estate from one entry point.
Business impact: reduced how many taps stood between a user and PropertyGuru's core discovery features, addressing a structural cause of the app's inconsistent experience.
**2. Revamped search result cards**
Problem: SRP cards were cluttered and didn't surface the details that actually influenced a decision (distance to transit, listing freshness, tour availability).
Options explored: minor visual refresh of the existing card, vs. a full redesign of the card's information hierarchy.
Decision: full redesign.
Solution: new cards surfaced price, distance to the nearest MRT station, "new project" and unit-type tags, and how recently the listing was reposted — moving the least useful information out and the most decision-relevant information up.
Business impact: contributed to the 3x increase in inquiries by making cards easier to scan and act on.
**3. Enhanced filters**
Problem: filters existed but were underused — user research found poor discoverability was the main reason, not lack of interest in filtering.
Options explored: add more filter options, vs. make the existing filters easier to find and use.
Decision: focus on accessibility of existing filters over adding new ones.
Solution: filters like property type, district, and price were surfaced earlier in the search flow and redesigned with clearer controls (checkboxes, toggles) instead of being nested in menus.
Business impact: supported the overall conversion gains by reducing the effort required to narrow a search.
**4. Map search integration**
Problem: PropertyGuru had no way to browse new property launches spatially — users could only search by list, even though location is often the first thing a buyer decides on.
Options explored: a simple map overlay showing pins with no additional detail, vs. a fully interactive map view with price markers, clustering, and a list/map toggle.
Decision: fully interactive map view.
Solution: a dedicated map search mode for new launches, with clustered price markers and a one-tap toggle back to list view.
Business impact: map search reached a 6% conversion rate on its own — two points higher than conventional search — becoming a meaningfully better-converting discovery path, not just a novelty feature.
Outcomes
**Business:** map search converted at 6%, two points above conventional search, and total inquiries grew 3x versus the previous experience.
**Customer:** users could discover new launches spatially for the first time, and previously buried features (Home Value, Mortgages) became reachable through flat navigation instead of a hidden drawer.
**Operations:** consolidating three inconsistent surfaces (web, mobile web, app) onto Hive 2.1 gave the business one design system to evolve going forward instead of three.
**Engineering:** migrating onto the new tech stack surfaced significant legacy code, extending the timeline to over a year — a real cost, but one that removed a structural blocker for all future search work.
**Support:** no support-specific data was available for this feature.
Reflection
The biggest surprise was how much of the timeline the migration itself consumed versus the visible feature work. Map search and the new cards were what the business could see and measure, but most of the actual risk — and most of the year-plus timeline — lived in legacy code we couldn't fully see the shape of until we were migrating it.
If I were doing this again, I'd push harder for dedicated QA time earlier in the process. Limited QA against tight design and engineering timelines meant some bugs and regional inconsistencies only surfaced after other markets started porting the same design, which cost more to fix after the fact than it would have earlier.
The principle I still carry from this project: when a redesign touches revenue-critical infrastructure, treat "don't regress what already works" as a harder requirement than any new feature — the downside of getting that wrong is asymmetric and immediate.