Overview
Ostrich is a private London property marketplace where homeowners explore selling on their own terms, without agents or public listings. The product had always presented listings in a clean, card-based list view. But as the catalogue grew and buyers started comparing properties across neighbourhoods, a gap kept surfacing in user feedback: there was no way to understand where anything actually was. People were evaluating homes with no spatial context. I was asked to explore adding a map-based browsing option that would give buyers spatial context without compromising the clarity the product was known for. It turned into more decisions than I expected, but the same principle held throughout: the map should focus the experience, not clutter it.
Note: Personal data in the visuals is illustrative. No real users, properties, or prices are shown.
The starting point
The brief was simple: let buyers toggle between list and map views. The hard part was everything around it. On desktop, the question was how to introduce a map that supported browsing without competing with listings for attention. Most property platforms default to map-heavy interfaces that bury the homes themselves behind pins and tooltips. I wanted to avoid that.
On mobile, the challenge was more structural. Screen space is limited, browser chrome eats into the viewport, and trying to show a list and a map simultaneously results in a cramped, unfocused experience. The mobile solution could not be a scaled-down desktop. It needed its own interaction model entirely.
There was also a quieter problem. The map needed to feel like part of Ostrich, not a bolted-on feature. The product’s identity is built on restraint and simplicity. Introducing a map risked breaking that tone if it brought with it the visual noise and interaction complexity that maps typically carry.
Finding the desktop layout
I started with desktop because the layout constraints were more forgiving, and it let me establish the interaction model before tackling mobile. My first instinct was a split view with listings on the left and controls moved into the side panel, giving the map the full available height. But before committing, I explored an alternative: keeping the filter and sort controls full-width across the page with the map sitting below them. The idea was to give the controls more horizontal space and show full button labels on desktop. The problem became obvious in the prototype: the map scrolled with the page. Fixing the controls under the header would have solved that, but it ate into the viewport height and left the map feeling cramped. I came back to the side-panel approach with more conviction. It gave the map a stable, full-height canvas and kept the controls contextual rather than global.
With the layout settled, I introduced an expand control: a single button that widens the map to the full viewport, hiding the list entirely. In full-width mode, buyers can scan a neighbourhood and immediately see how many properties are available, compare positions relative to each other, and get a feel for density and spread. Clicking a price pin surfaces a compact property card with enough detail to decide whether to explore further, and a tap takes them into the full listing page. The same button collapses back to the split view, which avoids the dead-end problem of full-screen maps where users lose access to listings and have to navigate back.
Making list and map talk to each other
Once both views existed, the challenge shifted to making them feel like one surface rather than two disconnected panels. Price pills on map pins mirrored the pricing hierarchy in the list. Hovering a card highlighted its location on the map, and clicking a pin scrolled the list to the matching card. That two-way relationship was essential. It meant the list and the map supported each other instead of competing.
A related question was what to do with secondary content. On the list view, the product shows additional properties below the search results: homes the buyer might be interested in that don’t match their current filters. On the map, that creates a problem: how do you distinguish between search results and recommendations when everything is a pin? We explored colour-coding the price pills, but it added visual complexity to a view that was supposed to be focused. In the end, we simplified: the map only shows search results. If a buyer’s filters return no results, the map toggle is disabled entirely, which avoids sending them to an empty map.
Rethinking browsing for mobile
Mobile required a fundamentally different approach. Rather than trying to squeeze the map into the existing layout, I treated it as a separate mode: a distinct state the user switches into, with its own focused experience. Users land in the familiar list view and can intentionally switch into a full-screen map. Once there, the filter and sort controls are hidden, partly because mobile viewport space is too precious, but more importantly because the map mode serves a specific intent: understanding where properties are. If buyers want to change their preferences, they return to the list. This mirrors the logic of the desktop full-width mode: when the map takes over the screen, the interface narrows its focus to location.
When buyers tap a price pin on the map, a bottom sheet surfaces a compact property card. Swiping the sheet left or right moves to the next or previous property in the list, so browsing on the map still feels sequential and connected to the underlying catalogue. A visible close button ensures users always know how to return. Filters and sorting persist when switching between views, so the map always reflects the buyer’s current preferences, even on mobile where the controls themselves are hidden.
Pressure-testing in the browser
At a certain point, Figma was not giving me enough signal on the interactions that mattered most. Static mockups and even Figma prototypes could not tell me how the map would feel in a real browser: how scrolling would interact with the viewport, whether hover states felt responsive or jittery, how the bottom sheet would behave under a thumb. So I built a coded prototype in Cursor to experience the design in its actual medium.
That prototype surfaced several things I would not have caught otherwise. The biggest was hover intent: on desktop, scrolling through the property list caused the map to highlight each card the cursor passed over, reacting to exposure rather than deliberate interest. Moving the cursor toward the map briefly passed over other cards, switching the highlight unexpectedly. I worked with the engineer to introduce a hover intent delay of around 120 to 180 milliseconds, so the highlight only activated when the cursor settled on a card. Click behaviour stayed immediate. It was a small detail, but it made the interaction feel deliberate rather than jittery. The prototype also helped me refine the bottom sheet transitions on mobile, how properties loaded when panning the map, and the animation easing across the board. Each of these findings went back into Figma as updated specs before handoff.
Engineering feedback and animation standards
Outcome & reflection
The feature went from first sketches to shipped in roughly four weeks, launching on 3 March 2026. At the time of writing, 549 out of 4,367 property page visitors have used the map view, roughly 12.6%. For a feature that is optional, unpromoted, and sits next to a list view that already works, that is a real number. Buyers who care about location are finding the map on their own.
The decision that mattered most was framing the map as a mode rather than a layout. That shaped everything downstream: the toggle pattern, the mobile strategy, the bottom sheet, the way filters persist, the choice to hide controls when the map takes over. Starting from “how do we fit a map on screen?” would have produced a weaker design than starting from “what mental model should this support?”
The other thing I would take forward is the value of building a coded prototype mid-process. Going from Figma to a real browser, even a rough one, changed specific decisions for the better. The hover intent delay, the bottom sheet transitions, the loading behaviour: none of these surfaced in static design. It is something I want to do more of, using the actual medium to pressure-test interactions before handing off, not after.
