3D Configurators for New-Build Developments

A 3D configurator lets a prospective buyer explore a new-build scheme interactively: turning a building, opening a floor, selecting a unit, comparing finishes. Used well, it becomes more than a showpiece — it turns plans, a technical specification and a set of finish options into an experience a buyer can actually follow, and it feeds real choices back to the sales team and the CRM.

Buying a home before it is built means projecting yourself into a space that does not exist yet: the buyer cannot check the proportions, feel the light or test how the kitchen connects to the living room and the terrace. Our guide to selling property before it is built covers that challenge in more depth; this article focuses on the layer that lets buyers configure and compare their own options.

Why a configurator matters at this stage

Spatial projection means being able to picture yourself inside a volume before occupying it. It works from the contractual documents while making them legible through an organised scene: proportions, openings, perceived ceiling heights, materials and possible uses, brought together in a single representation.

This visualisation needs to stay consistent with the specification, the plans and the technical constraints. An image that is too flattering, and hard to connect back to the unit actually being sold, can increase disappointment later and damage trust. A 3D configurator for new-build developments should show only the choices that are genuinely available, distinguish variants clearly, and keep a record of what was decided.

From browsing to a qualified appointment

Interest only becomes useful once it triggers a sales action. A configurator that records a chosen scenario — a building, a unit, a finish package — turns a browsing session into a starting point for a conversation, rather than a dead end. The sales adviser can then pick up the discussion from where the buyer left off, instead of starting the qualification from scratch.

Choosing the right format at each stage

A 2D floor plan, an exterior rendering, an orbital 3D model, a virtual tour and an interactive configurator each answer a different question, and a well-run sales campaign usually combines several of them rather than relying on just one.

• A 2D floor plan supports a first conversation with a prospect who is still comparing options.
• An exterior 3D rendering shows volumes and atmosphere, using light and materials to make a scheme feel real.
• An orbital 3D model lets people rotate the scheme and understand how it sits within its surroundings.
• A virtual tour lets a prospect explore a specific unit at their own pace, remotely.
• An interactive configurator lets a prospect record and compare their own choices, and passes that record on to the sales team.

Each format can be measured on its own terms, but a like-for-like comparison between them needs a shared, tracked journey and comparable sales conditions: price, location, financing and unit availability all influence a decision too, so no single visual should be credited automatically for a signature.

What a configurator adds on top of an orbital 3D model

An orbital 3D model answers the question a sales plan usually struggles with: where does the building actually sit within its surroundings? Buyers can rotate the scheme, look at the façades, locate the access points, understand how the buildings relate to each other, and see the outdoor spaces.

A configurator builds on that same 3D base but adds rules, states and actions that need to be described separately: rotating a model is not, on its own, a configuration journey. Selecting a building, opening a floor, choosing a unit and comparing a finish are all distinct interactions, each answering a specific question in the buyer's journey, and each needs to be specified rather than assumed.

Define the commercial role before the interface

Start from a user decision, not a list of 3D effects. Asking for “a configurator with rotation, filters and a materials library” says nothing about the data involved, the screens needed, or what should happen next in the journey.

Choose a priority audience

A prospect browsing alone on a scheme page needs simple instructions and a short path. An adviser in a sales suite can use more filters, explain the options, and pick the journey back up during an appointment. A communications agency will also expect brand rules, content formats and consistent integration with the campaign.

Describe the main audience, its context, and what it already knows. If several audiences are expected, state what they share and what changes between them: access, vocabulary, functions or visible information.

Write an observable success criterion

For each objective, define a checkable behaviour. For example: the user identifies a building, opens a unit type, views a variant and reaches the corresponding form. This kind of statement makes the tool testable, instead of leaving “success” open to interpretation once the configurator is built.

Map the user journey and limit choices at the right moment

A journey can start with an overview, move to choosing a building, then a unit, then a mood or finish package. Another might start directly from a specific unit passed on by a sales adviser.

List the steps and the possible exits. What happens if no option is available? Can the user go back a level? Can they keep their selection, or pass it on? These answers shape the interface, the data model and the production work.

Limit choices at the right moment

A configurator does not need to show every material, every unit and every piece of programme information at once. Group choices by intent — select, personalise, review, then get in touch — and surface information only when it helps the decision at hand.

Standard guidance on web forms generally favours short, simple forms, asking only for what is genuinely needed at each step. The same logic applies to a configurator: once a selection is saved, the user should get an explicit confirmation, and these behaviours belong in the brief just as much as the 3D views do — leaving them out only pushes the decision back to a later, more expensive stage of the build.

Define the objects, options and business rules

The core of a useful brief is a structured catalogue. List the objects being manipulated: scheme, building, floor, unit, unit type, room, mood, material or fitting. For each, state the information shown, its source, and who is responsible for validating it.

Do not confuse a visual option with a commercial one. Changing a wall colour to compare two moods does not automatically mean that choice can be ordered. The status needs to be explicit: inspiration only, an approved variant, an option still to be confirmed, or an included element.

For each option, specify:

• The available values and the order in which they are displayed.
• How the option should be represented in the scene.
• Any incompatibilities or dependencies with other choices.
• The source of truth and the date of the version supplied.
• The commercial status shown to the user.
• The person responsible for approving it.

If a price or an availability status needs to be shown, specify who supplies that data, when it is refreshed, and what the tool displays when it is missing. The studio should not be left to infer a commercial rule from a graphic naming convention.

Plan a minimum viable version

Sort functions into three groups: needed at launch, useful later, and out of scope. A first version can focus on a single journey, a handful of approved options, and a contact request that is properly connected — with future functions documented rather than added to the initial build. This makes trade-offs easier later: when a new idea comes up, it is measured against what launch actually requires, rather than added by default.

Specify the reference documents and the 3D data

A 3D model, plans, material schedules and mood references can all carry different dates. Build a list of documents with their version, their role, and which one takes priority.

An IFC file can be a useful exchange format, but the file extension alone does not guarantee that every piece of information the configurator needs is actually present: buildingSMART, the organisation behind the standard, describes IFC as an open format for describing built assets digitally, and notes that what a given file actually contains depends on its version and the model view it was exported with. Have the file, its objects, its properties and its real level of detail checked before relying on it.

Distinguish geometry, appearance and data

Geometry defines the volumes and the spatial relationships. Appearance covers materials, colours, lighting and staging. Data describes names, statuses, characteristics and rules. Keep these three layers connected to the same object, but do not assume that one automatically supplies the others: a well-modelled kitchen does not, by itself, tell the configurator whether that finish is included or an extra.

For anything still open — landscaping, furniture, unit boundaries, the finish range, or labelling — state whether the studio should wait for a decision, work from an approved assumption, or exclude that function from the first scope. A graphic assumption should never silently turn into a commercial promise: flag anything that needs sign-off before it goes live.

Specify the views and the interactions

Describe what the user can do in each scene: rotate around the scheme, zoom, select a building, hide a floor, open a room, or change a material. Every interaction should answer a specific question in the buyer's journey. Also state what needs to stay fixed, such as the north orientation, a building marker, or a running summary of the current selection.

Connect an interaction to a state

When the user chooses an option, describe what changes as a result: the image, a label, the summary, availability, or a call-to-action button. Also plan for the ability to cancel a choice or return to the starting state. A before-and-after visual showing an empty unit next to a furnished suggestion is a useful comparison to have in mind here: a similar function inside a configurator would need its own two states defined, a control to switch between them, a caption, and a clear non-contractual status for the suggestion — it is a comparison aid, not a working demonstration of the configurator itself.

Plan the interface, mobile use and accessibility

A configurator built for the web needs to be designed for mobile from the outset. Models, textures and interactions should be optimised so a prospect arriving from a property portal or a social post does not abandon the experience before reaching the projection they came for. Anything distinguished only by colour also needs a second marker — a label or an icon — so it still reads correctly for someone who cannot rely on colour alone.

WCAG, the international standard for making web content more accessible, covers dynamic and mobile content as well as static pages. A brief can ask for a target conformance level and appropriate testing, but conformance is verified on the finished product — it cannot be assumed from an interface mock-up.

Write the labels and the instructions

Use the words buyers and advisers actually use. “Kitchen mood” is clearer than an internal material code. Pair any complex command with a short instruction, placed at the point where it becomes useful, and plan for confirmation messages, error states and progress indicators. In a multi-step journey, the user needs to know where they are and how to go back without losing a selection they already confirmed.

Organise the data, the integration and the measurement

State where the configurator will be published: a scheme page, a mini-site, a tool used by advisers, or an integration inside an existing platform. List the data exchanges you expect, without assuming a technical vocabulary your own team may not use day to day.

For a contact request, specify what gets passed on with the user's consent: the scheme, the unit, the options selected, or the originating page. The form itself should explain each field, confirm submission, and let the user correct a mistake.

Define the source of truth

For every piece of data that can change, choose a responsible source. The configurator might receive a unit status from an external system, use a validated file, or be updated manually. The brief should specify the expected mechanism, how often it is refreshed, and what happens when information is missing.

Track only the events that answer a real question, and have the consent approach, the data retention period and access rights signed off by whoever is responsible for them in your organisation. The studio can implement the agreed tracking events, but governance and compliance decisions stay with your own team.

Agree the validation milestones

A configurator combines architecture, content, business rules and interface. Assign an owner for each area, and one person able to arbitrate when feedback conflicts. Plan validation milestones — journey and functions, data structure, scenes and options, interface, integration, and a final review before launch — with their number and timing agreed in the quote.

After launch, an option may be withdrawn, a unit renamed, or a finish replaced. Specify how such a request is submitted, approved and checked, and keep a version history of the source files and the screens affected. Keep correcting an error against the brief separate from updating data that was always expected to change, and separate again from adding a genuinely new function — the distinction keeps scope creep visible without blocking the product from evolving.

Checklist for choosing your 3D provider

Price alone does not make two providers comparable. A 3D configurator for a new-build development draws on your scheme data, your sales teams, your options, and sometimes the documents you send on to buyers.

• BIM compatibility: check whether the studio can use your models, schedules and plans directly, without needlessly rebuilding the project.
• Variant management: ask how flooring, kitchens, wall finishes and fittings are structured, priced and approved.
• Production timeline: request a schedule that separates modelling, review, corrections, integration and go-live.
• Technical responsiveness: identify who handles corrections linked to planning documents, plans, materials or units.
• Web and mobile integration: test the journey on a phone, a tablet and a desktop, with loading times compatible with your campaigns.
• Commercial connection: clarify which data can flow into the CRM, and in what form an adviser retrieves a saved configuration.
• Post-launch support: check the terms for maintenance, price updates and adding new options later.

A solid brief should include a demonstration on a real unit, an options matrix, and a sample appointment scenario. That way you are evaluating a sales tool, not just the quality of a presentation image.

Configurator brief template

Use the following headings in your consultation. Flag anything still undecided rather than leaving a blank field for the studio to interpret.

• Scheme context, priority audience and the configurator's objective.
• Final action expected, and the destination page or system.
• Main journey, alternative steps and a fallback path.
• Objects handled, options, rules, dependencies and displayed statuses.
• Reference documents, versions and the person responsible for each source.
• 3D scenes, camera views, interactions and anything excluded.
• Target screens, mobile use and accessibility requirements.
• Text, languages, legal mentions, imagery and brand rules.
• External data, forms, tracked events and data governance.
• Milestones, validation owners, testing and how updates are handled.
• Functions needed at launch, later phase, and out of scope.

Attach a sample journey and a completed option sheet. Flag any open questions instead of leaving the studio to choose a commercial rule or a data source on its own.

Frequently asked questions

Can the configurator work from an existing BIM model?

Yes, if the provider defines a clear workflow for checking geometry, materials, units and versions. A BIM model can supply part of the geometry or the data, but materials, commercial rules and interface content will usually still need to come from other sources. Have the files checked before confirming the scope.

Can options be linked to a price or an availability status?

Yes, if the price list and the validation rules are properly structured. Any price shown needs to stay consistent with your actual commercial terms, and the brief should say who supplies that data, how often it is refreshed, and what the tool shows when it is missing.

How many options should the first version include?

There is no universal number. Keep the approved options that support the main journey and whose rules are stable enough to ship. Document the rest for a later phase rather than adding incomplete choices to the first release.

Does it need to work on mobile and in the sales suite?

A shared base is possible, but usage, controls and screen constraints differ between the two. Define the priority devices and test the actual journeys: an interface designed only for a large touchscreen can become difficult to use on a phone.

How do we get comparable quotes from different providers?

Give each provider the same journey, the same options catalogue, the same source documents and the same expected deliverables. Ask each one to break out what belongs to model preparation, interface work, integrations, hosting and ongoing updates.

How do we stop a variant being read as contractual?

Give every option an explicit status, have the labels and legal mentions approved, and check they appear consistently across every screen involved. A 3D representation should never turn an inspiration or an assumption into an implied commitment.

In summary

A 3D configurator earns its place in a sales campaign when the commercial role, the audience, the options and the data are defined before the interface is built. Contact VIZION STUDIO with your available plans, the options you are considering and your distribution channels, and we will help you scope the 3D production, the interface and the integrations you actually need.