Property platforms often serve two very different types of users.
One person wants to find a home. Another wants to publish a property and find the right tenant. Both may use the same platform, but their goals, expectations, and workflows are quite different.
From a frontend and UX perspective, this makes real estate products particularly interesting to work with. Here are five details I try to keep in mind when designing property-related interfaces.
1. Start With the User's Intent
It can be tempting to build one large interface around all the functionality a property platform provides.
In practice, the first question should be much simpler: what is the user trying to accomplish?
For someone searching for a rental, the starting point might be:
- location
- monthly budget
- number of rooms
- move-in date
A landlord has a completely different starting point:
- property address
- property type
- size
- expected rent
- availability
Separating these journeys early makes the rest of the interface easier to understand.
From a frontend perspective, even a simple intent selector can help establish the correct flow:
<div class="intent-selector">
<button data-intent="find">Find a property</button>
<button data-intent="list">List a property</button>
</div>
The goal is not to show fewer features. It is to show the right features at the right moment.
2. Keep Search Filters Predictable
For renters, filters should behave exactly as users expect them to.
Price ranges need clear minimum and maximum values. Selected filters should remain visible, and removing one filter should not reset the entire search.
On mobile, I prefer keeping secondary filters behind a single obvious button and showing the number of active filters next to it.
For example:
<button class="filter-button">
Filters <span class="filter-count">3</span>
</button>
It is a small detail, but it gives users immediate feedback about the current state of their search.
The same principle applies to landlord workflows. If someone has already entered an address, property size, and monthly rent, moving between steps should not cause those values to disappear.
Predictability is often more valuable than clever interaction design.
3. Make Property Cards Easy to Scan
A property card does not need to show everything about a listing.
Its main purpose is to help users quickly decide whether a property is worth exploring further. I usually prioritize a few key pieces of information:
- photo
- location
- monthly rent
- size
- number of rooms
- availability
A simple structure might look like this:
<article class="property-card">
<img src="apartment.jpg" alt="Apartment interior">
<div class="property-content">
<p class="location">Copenhagen, Denmark</p>
<h2>Modern City Apartment</h2>
<p>2 rooms · 78 m²</p>
<strong>14,500 DKK / month</strong>
</div>
</article>
The visual hierarchy matters more than the amount of information shown. Price and location should be immediately noticeable, while secondary details can remain less prominent.
This becomes especially important when several property cards appear next to each other. Consistent placement of key information makes comparison much easier.
4. Design the Listing Flow Around the Landlord
Property platforms should not treat listing a home as an afterthought.
For someone who wants to udlej lejlighed i København, the process may involve much more than uploading a few photos and entering a monthly price. Property details, availability, documentation, presentation, and tenant expectations can all become part of the journey.
That creates an interesting UX challenge: how do we collect enough information without turning the listing form into one intimidating page?
A step-based approach usually works better:
const listingSteps = [
"Property details",
"Location",
"Rent and availability",
"Photos",
"Review"
];
Each step should have a clear purpose, and users should always know how far they are from completing the process.
Progress can be communicated with something as simple as:
<progress value="3" max="5">Step 3 of 5</progress>
I also prefer saving form state between steps. Losing ten minutes of property information because of an accidental refresh is exactly the kind of small technical failure that becomes a major UX problem.
5. Design for Mobile From the Start
Property platforms involve a lot of interaction.
Renters open filters, browse photos, save listings, return to results, and compare options. Landlords may upload images, enter property details, review information, and respond to inquiries.
Trying to compress a desktop interface into a smaller screen usually creates unnecessary friction.
For a renter, the core flow might be:
Search → Results → Property → Back to Results
For a landlord:
Property Details → Photos → Pricing → Review → Publish
The previous state should survive throughout both journeys.
Buttons need comfortable touch targets, filters should not cover essential information, and forms should use appropriate mobile input types wherever possible.
Image upload is particularly important for landlord flows. Users should be able to select multiple photos, understand upload progress, and reorder images without fighting the interface.
Final Thoughts
Good property-platform UX is mostly about reducing small points of friction.
Clear filters, scannable property cards, useful forms, preserved state, and predictable navigation may seem like relatively minor decisions individually. Together, they determine whether using the platform feels straightforward or exhausting.
The most important lesson for me is that property products rarely have just one user journey.
Renters and landlords may meet on the same platform, but they arrive with very different goals. Good frontend architecture and thoughtful UX should make both paths feel intentional rather than forcing everyone through the same interface.
For developers, that is a useful reminder that UI components should not only look clean in isolation. They need to support the decisions users are actually trying to make.
Top comments (1)
Good points, especially the focus on preserving state. That’s one of those things that looks small during development but makes a huge difference in a real property platform.
I’d also pay close attention to URL state for the renter flow. Keeping filters, sorting, and pagination reflected in the URL makes results shareable and means users don’t lose their search when navigating back from a listing.
For the landlord side, autosaving draft data is another place where a little frontend architecture goes a long way. A partially completed listing should feel recoverable rather than being tied to a single browser session.
The two different user journeys also make a strong case for designing the component system around reusable primitives rather than forcing both flows into the same page structure.
Really practical UX considerations here. I’d be interested to see how you’d structure the frontend state and API boundaries once the platform gets larger.