Role & Summary
Led the redesign of PropertyGuru's Search Results Page, replatforming onto Hive 2.1 and adding map-based discovery without regressing lead generation. Map search hit 6% conversion; inquiries grew 3x.
Business Context
PropertyGuru's Search Results Page was the highest-traffic surface, extended incrementally for years across web, mobile web, and native app without a shared design system. 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, but this page carried too much revenue risk for a routine refresh: it drives the inquiries connecting buyers and renters to agents, and any regression would be felt immediately. The redesign also had to work across every region PropertyGuru operates in, facing different data shapes market to market.
Strategic Decision
Migration Safety vs. Feature Ambition
Context: the team wanted map search shipped alongside the migration. Together meant a bigger, riskier release; apart meant shipping the design system twice as slow.
Options: (1) ship replatform and features together, or (2) replatform first with parity, then add map search later.
Trade-off: together risked a harder rollback, since a failure could come from either the migration or the feature. Apart meant a longer wait before new capability shipped.
Decision: ship combined, gated on one non-negotiable: no regression in lead generation or conversion.
Why: map search depended on the same infrastructure work anyway; deferring it meant duplicating effort. The real risk was regression, not scope, so we controlled for it directly.
Design Principles
1. Consistency Over Novelty: every screen had to match Hive 2.1's patterns, not introduce new ones, so the redesign wouldn't become a fourth inconsistent surface.
2. Discoverability Over Density: features buried in the drawer needed to be reachable in fewer taps, even at the cost of a shorter list on screen.
3. Zero Regression: no ship 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. Replaced the drawer with tab navigation: a bottom tab bar plus a dedicated Search overlay for MRT/district/HDB estate replaced the buried legacy drawer, cutting the taps between users and core discovery features.
2. Fully redesigned result cards: new cards led with price, MRT distance, tags, and listing recency instead of a minor refresh, contributing directly to the 3x increase in inquiries.
3. Made filters easier to find, not more numerous: property type, district, and price were surfaced earlier with clearer controls instead of nested menus, supporting the overall conversion gains.
4. Built a fully interactive map mode: a dedicated map view with clustered price markers and a list/map toggle let users browse new launches spatially, reaching 6% conversion on its own, two points above conventional search.
Outcomes
Business: map search converted at 6%, two points above conventional search, and total inquiries grew 3x.
Customer: users could discover new launches spatially for the first time, and previously buried features (Home Value, Mortgages) became reachable through flat navigation.
Operations: consolidating three inconsistent surfaces onto Hive 2.1 gave the business one design system to evolve instead of three.
Engineering: migrating onto the new stack surfaced legacy code, extending the timeline to over a year: a cost that removed a structural blocker for future work.
Support: no support-specific data was available for this feature.
Reflection
The biggest surprise was how much of the timeline the migration consumed versus the visible feature work. Map search and new cards were what the business could see and measure, but most of the real risk (and most of the year-plus timeline) lived in legacy code we couldn't see the shape of until we were migrating it. I'd push for dedicated QA time earlier next time, since limited QA against tight timelines let bugs surface only after other markets ported the same design.
The principle I still carry: when a redesign touches revenue-critical infrastructure, treat "don't regress what already works" as harder than any new feature: the downside of getting it wrong is asymmetric and immediate.
