Start with the buyer's decision, not the animation.
Someone browsing a residential development is usually trying to answer a small set of questions: Which homes fit my needs? Where are they in the building? What is the orientation, layout and outdoor space? Can I enquire about a particular unit? A floor plan should make those answers easier to find.
An interactive floor selector is useful when position in the building materially changes the choice, when many units share similar names or when comparing floors and orientations is difficult in a plain list. It is less useful when the scheme is small, units are already easy to distinguish or the team cannot maintain the underlying availability data.
Do not begin by commissioning a 3D model of every apartment. First try the buyer journey with a table of units and readable plans. Add spatial interaction only if it removes a genuine ambiguity that the simpler interface leaves unresolved.
Give someone unfamiliar with the project three tasks: find a home with an outdoor space, identify its floor and send an enquiry that names the correct unit. If a simple list and plan already make those tasks effortless, the additional interactive layer needs a stronger reason to exist.
Four ways to present homes, from simplest to most complex.
These formats are not a hierarchy of quality. They solve different problems, and several can coexist. A clickable building elevation may help with orientation, while a structured list remains the fastest way to compare floor areas or unit types.
| Format | What it does well | Limitation to plan for |
|---|---|---|
| Unit list with filters | Compare types, floors and verified availability quickly | Location within the building may be unclear |
| Static floor plans | Explain individual layouts without a complex interface | Finding a unit's position may require a separate diagram |
| Clickable floorplate or elevation | Connect a unit ID to its physical location | Small touch targets and outdated status colours can mislead |
| 3D building or apartment selector | Help visitors explore complex spatial relationships | More assets, more testing and a robust accessible alternative |
For many developments, the strongest solution is a searchable unit list plus a clearly labelled building diagram. The list supports precise comparison. The diagram answers “Where is it?”. Neither should depend on the other to function.
Do not make a 3D selector the only route to an enquiry.
A visual interface may be slow on older phones, inaccessible to some visitors or difficult to use in bright sunlight. Every unit that can be selected visually should also be findable by its reference in ordinary text. That text-based path is part of the product, not a backup hidden in the footer.
One unit identifier should connect every view.
The architectural plan, sales sheet, building selector, contact form and sales team's system must agree on which home is being discussed. Give each unit a stable identifier and use it consistently. A floor selector should read from structured records, not from hand-edited labels embedded inside an illustration.
The fictional record illustrates relationships between fields. It deliberately contains no invented area, price, address, completion date or claim that the apartment is available.
Separate design facts from sales facts. Floor, unit geometry and plan revision may come from the design team; reservation status and publishable prices may come from the sales team. Decide who approves each field. The website should not silently turn an architectural drawing into a binding sales statement.
When a plan changes, record its revision and replace all public references to the superseded version. A visitor should not download one layout while seeing another in the selector. If documents are retained for audit purposes, keep them outside the public buyer journey unless publication is appropriate.
Make the spatial interface readable without a mouse.
On a desktop, hovering over a unit can reveal its reference. On a phone there is no hover. For keyboard users, a selectable unit needs a visible focus state and a predictable way to activate it. For screen-reader users, an unlabeled shape in a floorplate communicates almost nothing.
- Give every selectable unit a text name: for example, “Unit A-203, floor two”, with additional verified information where available.
- Support keyboard operation: focus should move logically, and selection should not depend on pointer hover.
- Do not encode status only by colour: show a readable status label in the unit detail and list.
- Keep a list or table alternative: the same homes and enquiry actions must remain available without interacting with the diagram.
- Explain orientation: show a north arrow or other clear reference only when its direction is verified.
- Test zoom and text enlargement: avoid controls that overlap or become unreachable at larger sizes.
An SVG floorplate can support crisp geometry and interactive regions, but SVG alone does not guarantee accessibility. Accessible names, focus behaviour, state announcements and the relationship between the selected shape and its unit details all require deliberate implementation and testing.
Use the building diagram for location, not for every fact.
Trying to squeeze area, room count, orientation, price and availability into a tiny polygon creates an unreadable map. Let the selection reveal a clear unit summary alongside a legible plan. Keep the comparison table for the information that is easier to scan in rows.
Design the mobile route before shrinking the floorplate.
A desktop building elevation can look persuasive at full width and become unusable at 390 pixels. On a phone, visitors may benefit more from a floor filter, a compact list and a button that opens the relevant plan. Do not assume the desktop selector must remain the primary mobile interface.
Test the page with real fingers, not just a resized browser window. Can visitors tap one unit without selecting its neighbour? Can they pan or zoom a plan without trapping the page scroll? Is the close control reachable? Does the selected unit remain identifiable after rotating the phone?
Large visual assets should not block access to basic facts. Load appropriately sized imagery and make the text-based unit list available while richer graphics are loading. If the 3D layer fails, the user must still be able to compare homes and enquire.
A visitor chooses “Two bedrooms” and “Floor 2”, sees matching unit references in a list, opens A-203, reads its verified plan and taps “Enquire about A-203”. The enquiry form carries that reference forward. A building diagram may help, but the journey does not depend on it.
Interactive does not mean live or accurate.
A colour-coded floor selector can give a powerful impression of real-time availability. That impression is dangerous when the data is maintained manually or the integration has stopped updating. Establish the authoritative sales source before designing green “available” badges.
- Define the statuses: for example, available, reserved, sold and enquire. Confirm their meaning with the sales team before publishing.
- Assign ownership: specify who can change a unit's status and how the website receives that change.
- Record freshness: keep a timestamp of the last successful verification or synchronisation.
- Plan for failure: if the feed is stale or unavailable, show a cautious “Enquire for current status” message rather than confidently presenting an old availability state.
- Test the handoff: an enquiry must contain the correct unit ID even when the visitor arrives directly on a detail page.
Do not invent a universal update interval. The acceptable delay depends on the actual sales process and what the public interface claims. If a unit can be reserved over the phone, the website needs a clearly defined policy for how quickly that information appears online.
Keep the same status in the list, map and unit detail. Three interfaces with three different answers are worse than one simple page that honestly asks visitors to confirm current availability.
Separate a marketing illustration from an approved plan.
Floor plans and architectural visualisations serve different purposes. A furnished illustration can help someone imagine a home; an approved drawing is better suited to explaining its layout and dimensions. The website should identify what each image represents, which revision it belongs to and whether it is illustrative.
Do not infer dimensions from a rendered image or present decorative furniture as included in the sale unless that has been verified. Check publication permissions for drawings, photography and visualisations. Where relevant, have the project's responsible team approve the wording of any qualifications or disclaimers.
The broader residential development website checklist covers project imagery, location, enquiry content and launch readiness. This guide focuses on the separate design and data decisions behind a unit selector.
Should every unit have its own indexable URL?
Not necessarily. A stable, useful unit detail page can help visitors share and return to a specific home. But generating dozens of nearly identical thin pages solely for search traffic adds little value. Decide whether each page has meaningful, verified information and a clear navigation role. When a URL changes, plan an appropriate redirect; do not quietly reuse an old unit URL for a different home.
Acceptance tests before the selector goes live.
Ask the future sales administrator, a developer and someone unfamiliar with the building to complete the same tasks. Test the published environment as well as a preview, because data feeds, forms and asset paths may behave differently after deployment.
- Find the same unit by reference in both the list and building diagram.
- Check floor, type, orientation and plan revision against approved source material.
- Open and understand the plan on a narrow phone screen without accidental taps.
- Use the selector by keyboard and complete the equivalent journey through a text list.
- Verify that status is communicated in words, not colour alone.
- Simulate an unavailable or stale sales feed and inspect the public fallback.
- Send an enquiry and confirm that the correct unit ID reaches the responsible team.
- Replace an approved plan revision and verify every visible/downloadable reference.
- Confirm image rights, credits, maintenance ownership and the escalation path for incorrect information.
- Check performance and layout on real mobile devices and ensure the basic unit list works if rich graphics fail.
The best interactive floor plan is not necessarily the most elaborate one. It is the simplest interface that helps a buyer identify a home accurately, understand where it is and make a useful enquiry, while the development team can keep its information current.