On a travel landing page, the hero sells emotion. On a marketplace for space — storage, parking, apartments — the first visit is a search job. Users open the site with a location in mind and a rough budget. If the map and filters fight them, they bounce to a competitor or a WhatsApp group.
We have shipped map-led discovery for storage and property products. The patterns below are the ones that keep showing up in usability sessions.
It helps to be precise about what kind of product this is. A travel brand can sell a feeling because the purchase is aspirational and the user has time to browse. A space marketplace is closer to a utility — someone needs 4m² of storage near their apartment by the end of the month, or a parking spot near a specific office, and they are comparing three or four tabs open at once. The product that gets to "yes" fastest, with the least friction between opening the site and seeing a real, bookable option, wins that comparison. Everything below follows from treating the first screen as a search tool first and a brand surface second.
Lead with place, not brand poetry
A short value line is enough. The primary surface should be:
- Map with readable pins or clusters
- Search for address / area
- Filters that match how people compare (price, size, labels)
"Near me" only helps if geolocation permission and feedback are honest. If you cannot locate the user, fall back to a clear city or region picker — not a blank map of half the continent.
The failure we see most often here is a hero section that pushes the map below the fold on desktop, or worse, behind a second screen on mobile — a marketing headline, a value proposition, a stock photo of a smiling person, and then, after a scroll, the actual tool. Every pixel spent on that framing before the map loads is a pixel the user has to scroll past to do the thing they came to do. It is not that brand messaging is worthless — it is that on this category of product, it belongs beside the map, not in front of it.
Geolocation deserves its own scrutiny because it fails silently more often than it fails loudly. A user denies the permission prompt (which a meaningful share of users do, on principle, regardless of the site), and if the product's only plan was "get their coordinates," the map now has nothing to show and no path forward. The honest design is to treat geolocation as an accelerator for a location picker that works perfectly well without it — type a city, pick from an address autocomplete, or select from a short list of served regions — rather than as the only door in.
Filters people understand
Three filters beat twelve. Typical winners:
- Price (range, monthly vs nightly — label the unit)
- Size (m² or unit type)
- Must-have tags (climate control, 24/7 access, parking)
"Clear all" is not optional. Users experiment; they need a reset without refreshing the page.
When results hit zero, say why ("No units under €80 in this area") and offer one action: widen radius, clear a filter, or contact sales. Empty states that only say "No results" train people to leave.
The instinct to add more filters usually comes from stakeholders who can see every attribute in the database and want all of them exposed. But every filter is a decision the user has to make before they can see results, and most attributes in a listings database are not decision-making criteria for a first-time visitor — they are detail-page information for someone who has already narrowed to two or three options. The three filters that consistently earn their place are the ones that map to how people actually describe what they want out loud: a price they can afford, a size that fits what they're storing or parking, and one or two non-negotiable features. Everything else belongs on the detail page or behind an "advanced filters" disclosure that most users never need to open.
The zero-results state is worth the design time it costs because it is not a rare edge case on a search-driven product — a meaningful share of real searches, especially in a market with limited early inventory, will land on zero results at some point in the session. Treating that screen as an afterthought (a generic "no results" message with no next step) turns a normal part of the search process into a dead end. Treating it as a real state — with a reason and a specific recovery action — turns the same moment into a chance to keep the user searching instead of leaving.
Listing cards that compare in five seconds
From the map or list, each card should answer:
- Where is it (neighbourhood-level is enough at this stage)
- Price with period
- Size or capacity
- One trust signal (photos count, verified host, or key amenity)
Deep storytelling belongs on the detail page. The browse state is for elimination.
The mental model worth designing for is that a browse session is mostly a process of rejection, not selection — a user scans ten or fifteen cards to eliminate the nine or fourteen that obviously do not fit, and only opens the one or two that survive. A card that requires a click to answer "is this even in my budget" fails that job, because it forces the elimination step to happen one detail-page load at a time instead of in a single scan across the list or map. This is also why consistency across cards matters more than any individual card looking polished — if price is sometimes per month and sometimes per day without a visible unit, the user cannot compare at a glance and has to open each one to check, which defeats the point of a browsable list.
Host tools are part of seeker UX
Broken host inventory means empty maps. If owners cannot publish photos, set price, or import a spreadsheet of units, seekers see "Listings found: 0" forever — and blame the brand, not the ops gap.
Design the publish flow as carefully as search: title, price, size, features, photo limits, and a preview of how the listing will look on the map.
This is easy to underinvest in because it is not the surface a founder or investor sees in a demo — the demo shows the seeker side, with the map full of pins. But every one of those pins came from a host who got through a publish flow without giving up, and marketplaces live or die on supply density in the areas where demand actually is. A publish flow with too many required fields, unclear photo requirements, or no way to bulk-import existing listings from a spreadsheet will quietly cap supply in exactly the neighborhoods where a competitor with an easier onboarding flow will not. The seeker never sees the publish flow, but they experience its failure directly, as a thin or empty map.
Dark UI and map contrast
Dark product shells look premium until the map tiles and pins disappear into the chrome. Check:
- Pin contrast on light map tiles
- Selected vs default pin states
- Filter bar readability on mobile (thumb reach, sticky vs scroll)
Test on a real phone outdoors. Marketplaces are often used on the go.
Map tiles are usually the one element on the page that a design system does not control — they come from a map provider, in whatever palette that provider ships, and most are light by default. A dark-themed product shell built and reviewed on a designer's laptop, indoors, at full brightness, can look sharp right up until someone tests it on a phone in direct sunlight, where a dark pin outline on a light tile either survives or vanishes, with nothing in between. The same applies to the filter bar on mobile — a bar that is elegant when the map is the only thing on screen can eat so much vertical space on a small viewport that half the map is hidden behind it, which is a real cost on a product where the map is the product.
Measure the right first-session events
Vanity: hero CTA clicks. Useful:
- Search submitted / "near me" used
- Filter changed then result opened
- Listing detail opened from map
- Host started "add listing"
If map interaction is low but bounce is high, the problem is usually discoverability — not brand colour.
The reason to instrument these specific events, rather than generic page views, is that they map to the actual job the user came to do. A high hero-CTA-click number can be entirely misleading on this kind of product — it measures whether people notice a button, not whether they found what they were looking for. "Filter changed then result opened" is a much sharper signal, because it captures the sequence that matters: a user narrowed their search and then found something worth a second look. When that sequence is rare but traffic is healthy, the fix is almost never a new hero image — it is usually that the map or filters are not surfacing results the way the user expects, and that is a product problem worth debugging with session recordings before it is treated as a marketing problem worth solving with new copy.
Stereasoft builds marketplace web apps in React and Next.js where search is the product. If your first screen could be swapped for another brand and still make sense, the map and filters are not doing enough work yet.