Overview
Ostrich is a private London property marketplace where homeowners explore selling on their own terms, without agents or public listings. Buyers sign up, set their search preferences, and receive email alerts when matching properties become available. My role was to evolve the buyer-facing experience as Ostrich expanded from a handful of North London boroughs to a much larger geographical footprint. This was not a single project with a tidy brief. It was a series of interconnected design challenges that unfolded over several months as the product and the business grew.
Note: Personal data in the visuals is illustrative. No real users, properties, or prices are shown.
The starting point
When I picked up this work, the buyer signup flow asked for a lot upfront. After entering an email and creating an account, buyers landed on a full email alert preferences screen where they chose areas, bedrooms, property type, and price, all before seeing a single property. We did this for two reasons: personalised email alerts and tailored first-visit results. Both goals were sound. But it created friction. Buyers had no frame of reference for what Ostrich offered, and the preferences screen was doing heavy lifting for users who had not yet built any trust in the product.
The scope of the project was also about to expand. Ostrich had started in Islington and later added Hackney, Camden, and Haringey. With four boroughs, simple checkbox-card selectors worked fine. But a larger London rollout was coming, and the area selection UI would not scale. Borough names varied in length, each contained a different number of neighbourhoods, and new areas would be switched on incrementally as inventory came online. The same selector also appeared in three places: the preferences flow, the All Properties filters, and the email alert settings. Anything I changed had to work in all three.
There was a parallel question coming from the business side. Ostrich lists properties across different sale timelines: some sellers are ready within a year, others are planning further ahead. The team wanted to favour the shorter timeline without hiding the longer one. The initial proposal was to stack three sections on All Properties with decreasing prominence. Was that the question we were actually trying to answer?
So the brief was layered: rethink the signup flow to reduce friction without losing personalisation, redesign the area selectors to handle a growing geography, and find a way to surface sale timelines that served both buyers and the business.
Rethinking the signup flow
The first significant change was removing the email alerts screen from signup entirely. Instead of asking buyers to declare preferences before seeing anything, the redesigned experience let them browse the All Properties page immediately. After a short preview, the feed fades out and a prompt invites them to personalise. The logic was simple: tell us what you want, and we’ll stop showing you irrelevant homes. Exploratory first, personalised once a buyer had reason to care.
Preferences then moved to a dedicated two-step flow accessible from the All Properties page. Step one asks “Which areas are you considering?” - the fundamental buying decision. Step two asks “What are you looking for?” covering bedrooms, property type, and price. Email alerts were folded into step two as a default-on toggle, which recovered the opt-in rate without the upfront friction of a dedicated screen.
The split between steps wasn’t arbitrary. As I worked through the IA, three tiers of specificity kept emerging, and the more I sat with them the more they felt like the right way to think about the whole project. Preferences are sticky buying decisions - area, bedrooms, type, price - things that define who you are as a buyer and rarely change session to session. Filters are session-based and exploratory: tenure, balcony, number of floors, the kind of thing you toggle once and ignore the next visit. None of these existed in the product yet, but they had come up in crits and reviews, so I knew the design needed to leave space for them. And the sale timeline was different again. It tied directly to Ostrich’s positioning: owners can list without being in a rush to sell, which is part of what separates the platform from a traditional agent. Buyers don’t naturally think in those terms, but the product needed a way to surface that distinction. Each tier needed its own home in the interface, its own persistence logic, and its own moment in the experience. That model became the spine of every decision that followed.
Scaling the area selector
The area selector was the most technically demanding piece. With four boroughs, the original checkbox cards had worked fine. Dozens of neighbourhoods across a growing number of boroughs needed a different approach. I tried longer flat lists and implicit “select all” patterns before landing on grouping areas by borough with a “Select all” option per group.
Borough-level selection mattered more than it might look. Many London buyers think geographically at the borough level first - “I’m looking in Hackney” - before narrowing down to specific neighbourhoods. Forcing them to tick every neighbourhood in Hackney one at a time would have been the wrong shape for the way they were actually approaching the search. Letting them select a whole borough in one move respected that mental model.
Two smaller details did a lot of work. Each area displayed its postcode alongside the name, and newly launched areas received a “New” badge. The postcode addition came out of a real search behaviour: many London buyers search by postcode rather than area name, so including it meant the search input could match on either. Once postcodes were visible, the same insight shaped the search interaction more broadly. I built a working prototype using AI to test how search should behave inside the grouped list, and it surfaced a spatial problem I would not have caught in Figma. Initially the search bar sat below the page heading, so it scrolled with the content. The prototype made it obvious that the search needed to lock to the top of the screen on focus, with the heading disappearing while search was active. Simple CSS handled the interaction without adding engineering complexity.
The design also had to handle incremental expansion. New areas would appear as properties became available, not all at once. Ops needed the ability to switch areas on and off, and the UI had to look complete at every stage, whether Ostrich covered five boroughs or fifteen. The selector also had to feel consistent across three surfaces: the preferences flow, the All Properties filters, and the email alert settings.
Selling soon and selling later
Ostrich lists properties across different sale timelines: some sellers are ready to move within a year, others are planning further ahead. The business wanted to prioritise shorter-timeline properties without hiding the longer-term ones entirely. The initial proposal was three stacked sections on the All Properties page with decreasing prominence: preference matches at the top, longer-timeline properties below, then everything else.
I pushed back. If we were burying the longer-timeline results, why have them at all? Different sale timelines are part of what makes Ostrich distinctive, not a problem to manage. Treating them as second-class content in the layout undermined the thing the product was actually for.
Before landing on a solution, I worked through several approaches. A simple toggle. A filters button that grouped timeline with tenure and floors. A third preferences step to explain the concept. Each of them was a reasonable piece of UI, and each tried to manage the complexity within the existing interface. But they were all answering the same question: how do we explain a confusing concept to buyers? That was the wrong question. The question was: what browsing mode does this distinction actually represent?
What worked was a tab-style selector at the top of the feed: “Selling soon” and “Selling later.” Two browsing modes, given equal structural weight. The default sits on “Selling soon,” aligning with the business preference, but “Selling later” is a single tap away. The language replaced internal jargon - “0-12 months” and “12+ months” - with words that match how people actually talk about property.
When a buyer selects “Selling later” for the first time, a contextual banner appears explaining that these properties have a longer sale timeline and that owners may not be ready for viewings yet. Browsing homes that aren’t actively on the market is the unusual thing about Ostrich, and the banner sets expectations the first time it matters. It appears once and can be dismissed - a small piece of UI doing real work in managing trust.
The tab interaction debate
Supporting the ecosystem
Two smaller pieces rounded out the project, both of them using information the buyer had already shared.
As Ostrich expanded into new boroughs, existing users needed a way to discover the new inventory. I designed a modal that announces each expansion and prompts buyers to update their preferences, creating a re-engagement loop tied directly to inventory growth. After launch, 27% of users who saw the modal added one or more of the newly available areas. The trigger for the modal was the same data the buyer had set during signup, so it knew which areas were genuinely new to them.
The other piece was a cross-sell modal for buyers who indicated during signup that they own their home. Their postcode, originally captured for personalisation, became the basis for a tailored prompt to list their property on Ostrich. Not a hard sell, just a quiet acknowledgment that some buyers were also potential sellers. The same field that shaped their search quietly became a lead for the other side of the marketplace.
Outcome & reflection
After launch, the signup flow showed healthy conversion across all acquisition channels, with overall completion at around 83% and preference set rates between 86% and 100% depending on channel. The new areas modal drove a 27% adoption rate among prompted users. We also took a deliberate call on email alerts: default them on, and don’t expose the toggle on the first pass through preferences. Buyers got alerts from day one without being asked to make a decision they hadn’t formed yet, and could turn them off later once they had context. These are post-launch health metrics rather than before-and-after comparisons.
Underneath all of this was the same question: what information matters at which moment? The original flow asked for everything upfront. The redesigned experience lets buyers explore first, commit when ready, and refine over time. Preferences define the buyer, filters help them browse, the timeline gives the business a lever without forcing buyers into a choice they may not naturally make.
The thing I’ll take forward from this project is knowing when to stop refining and start reframing. The sale timeline work went through several iterations that all tried to manage complexity within the existing interface - a toggle here, a preferences step there, a banner to explain what was happening. Each one was a reasonable solution to the wrong question. The tabs worked because they stopped asking “how do we explain this concept?” and started asking “what browsing mode does this represent?” It’s easy to keep iterating on what you have without asking whether what you have is still the right frame. Sometimes the better design is the one that changes the question.
