Building digital twin interfaces: when the 3D model helps and when analytics should lead

A 3D digital twin helps the people using building and energy software when their question is spatial: where is this asset, what is it connected to, and how do I explain this building to someone who has never walked it? For the repeated work of a shift, such as scanning for problems, comparing sites and working through exceptions, the interface should lead with a ranked list, charts and alerts, and use the twin to show where a problem sits. The products that work let people move between the two without losing the asset, the time window or the question they started with.

Put simply, the twin is a map. The list of what needs attention is the working day. Below we set out what a building twin is, which view should lead for each job, what research on 3D and 2D displays shows, a checklist for when 3D earns its place, a pattern for keeping context between views, and how to put AI recommendations on top.

What a building digital twin is

The term is used loosely, so start with research rather than a product page. In a study published in Building and Environment in 2025, Abdelrahman and colleagues analysed more than 15,000 full-text articles and drew on a panel of 52 experts to derive a definition for the built environment. In summary, a building digital twin is a spatial and temporal virtual representation of a physical asset or system that manages its static and dynamic information, adapts to operational changes at suitable intervals and can forecast scenarios to support decisions.

Three findings from that paper shape interface decisions.

• A model that is not kept up to date is not a twin. The authors state that a BIM model which lacks regular updates reflecting changes in the real building does not meet the criteria for a digital twin. Geometry is the starting point; data that changes over time is what makes it a twin.
• Building twins support decisions over time. The paper sorts twins into two groups: high-performance real-time twins, used in manufacturing, self-driving cars and aerospace, and long-term decision support twins. It places every built-environment twin it studied in the second group. Most building software helps people decide, rather than steering a machine second by second.
• Geometry and meaning both count. The experts named accurate 3D geometry and rich semantic information as critical components. The interface question is which of the two should lead for a given task.

Semantic information is what lets any view, 3D or not, answer a question such as "which air handler serves this zone?" Two open efforts describe it. Brick standardises semantic descriptions of the physical, logical and virtual assets in buildings, with relationships such as feeds (the subject is upstream of the object), hasPoint (the subject has a source of telemetry) and hasLocation. Project Haystack describes sites, equipment and points, and links them with references such as siteRef. When the data underneath carries relationships like these, a selected asset can be found in a floor plan, a list and a chart alike. When it does not, the 3D model is a picture, however detailed.

Match each job to the view that fits it

A twin interface should be designed from the jobs people do, not from the model. Operators, energy managers, finance leads and sustainability leads all draw on the same building data, and most of their work follows one loop: spot a problem, find where it is, understand why, decide, act and verify. Each step has a view that answers it fastest.

Two further jobs sit outside the daily loop, and both favour 3D: learning a building or portfolio for the first time, and explaining it to people who will never operate it, such as owners, investors, tenants or a board.

For the list and chart views, the general rules of analytics design apply; we cover them in our guide to SaaS dashboard design.

What research says about 3D and 2D views

There is little independent research comparing 3D and 2D views inside building software itself, so the strongest evidence comes from wider visualisation research, plus one usability study of a working twin.

Melanie Tory, Arthur Kirkpatrick, Stella Atkins and Torsten Möller compared 2D, 3D and combined displays in a series of experiments published in IEEE Transactions on Visualization and Computer Graphics in 2006. They found that 3D displays with cues such as shadows worked well for approximate navigation and relative positioning, but not for precise navigation and positioning, except possibly with good viewing angles or measurement tools. For precise tasks, two of the combined 2D and 3D displays they tested (an orientation icon and ExoVis) did better than strict 2D or strict 3D displays, inspired higher confidence and allowed more integrated navigation; a third combination, clip planes, was not effective for 3D orientation. Task characteristics, orientation cues, occlusion and how close together the views sat all shaped which displays people preferred.

The same paper reviews earlier work that maps neatly onto building software. Field observations found 2D views used to establish precise relationships, and 3D views used for a qualitative understanding and to present ideas to others. A study by St. John and colleagues found 3D better for understanding shape and 2D better for judging relative position.

A 2025 study of a working twin points the same way. Wang and colleagues at the National University of Singapore tested BEAM, a web-based urban digital twin for thermal comfort with 3D building models and a switch between 2D and 3D, with ten urban planners and researchers. On the User Experience Questionnaire it scored well for attractiveness (1.67) and stimulation (1.70), but below the benchmark average for perspicuity, the scale for how easy a product is to learn (0.75). The authors report that manipulating the 3D view and the layer menu posed usability problems. Every participant started the thermal walk playback, but only 20% connected the survey responses with the measured climate data, and participants asked that selecting a survey response should move the timeline of the measured data to match. It is an urban twin and a sample of ten, as the authors note, yet the pattern is familiar: the twin impresses, and people get lost when they try to relate one piece of data to another.

Our reading of both studies: 3D is good at overview, shape and approximate location; 2D views are better for precise position, comparison and scanning; and a combination beats either alone when the views are linked.

Where 3D earns its place, and where it slows people down

The 3D model wins the demo and the onboarding. The list of what needs attention wins the working day. That is our position, and the checklist below is how we test it on a given product.

3D earns its place when:

• the question is spatial: where an asset is, what sits above, below or beside it, or how a zone connects to the plant that serves it;
• the user does not yet know the building: a new starter, a newly acquired site, a contractor on a first visit;
• the audience will never operate the building and needs to grasp it quickly, such as owners, investors or a board;
• relationships between systems are the point, such as solar, storage, chargers and the loads they serve, and the data carries those relationships;
• the model is simplified to what the decision needs, not to everything the building contains;
• the user can leave 3D in one action and land on the same asset in a list or chart.

3D slows people down in four kinds of work:

• Repeated monitoring. An operator checking the same sites every morning needs a list that ranks what changed. Rotating a camera to find the red asset takes longer than reading a sorted row, and an asset behind another one is hidden; Tory's team counted occlusion among the factors that decided which displays people preferred.
• Comparison. Comparing ten buildings, or this month with last, needs aligned bars on one scale. Perspective changes apparent size and position.
• Exceptions. A queue of faults needs sorting, assignment and status. Those are list operations.
• Precision. Reading an exact value or checking a threshold is a chart's job, in line with the finding that strict 3D displays struggle with precise tasks.

One test settles most arguments in a review. Remove the twin from the screen and ask which job users could no longer do. If the answer is none, the twin belongs in onboarding and in the sales demo, not in the default view of the working day.

Keep people's place when they move between views

Relating one view to another is where BEAM's participants struggled most. The pattern we recommend is a single shared selection that every view reads and writes.

1. Hold the state outside any one view. The selected assets, the time window, the scale, the filters and the alert or question that started the session live in one place, and every view draws from it. Put that state in the address, so a reload or a shared link opens the same place.
2. Let selection travel. Choosing a row in the alert list highlights that asset in the twin, dims the rest and opens its chart for the same period. Choosing an asset in the twin scrolls the list to it.
3. Let time travel. A time window chosen on a chart sets the period the twin colours by, and the reverse. This is the link BEAM's participants asked for.
4. Keep scales fixed by default. Most BEAM participants preferred fixed scales as the default, which suit comparison over time. Keep the colour scale identical across views, so red means the same thing in the twin, the plan and the chart.
5. Show the way back. Ben Shneiderman's visual information-seeking mantra, "overview first, zoom and filter, then details-on-demand", lists history among the seven tasks an interface should support. A visible trail of where the user has been lets them step back to the portfolio without starting again.
6. Place views by how the task uses them. Tory's team suggests displays with views closely together when 2D and 3D are used closely together, and separate views when a task has distinct 2D and 3D phases. If operators read the chart while looking at the asset, put the twin and the chart side by side; if they locate first and analyse later, a switch will do.

Related ideas show in a coded demo we designed for ConnectX, a company in building energy management whose brief was AI-first energy management for commercial buildings. Early concepts explored detailed 3D and realistic building models, but more fidelity did not automatically create more understanding, so the twin became an abstract 2.5D model. Assets could be highlighted, dimmed or brought into focus according to the user's request, inside a persistent workspace with charts and controls. It was a demonstrated model of eight defined scenarios on an interim data layer; it did not demonstrate live telemetry, adoption, operational savings or commercial outcomes.

Put AI recommendations on top of the twin, not instead of it

The most direct use of AI on a twin is a recommendation: lower this setpoint, shift this load, inspect this unit. The twin gives a recommendation a place, and the shared selection gives it evidence. The Guidelines for Human-AI Interaction, 18 guidelines published by Saleema Amershi and colleagues at Microsoft at CHI 2019, translate directly.

• Attach every recommendation to an asset and a period. Opening one should select the asset in the twin and show the chart that prompted it. This answers the guideline "Make clear why the system did what it did".
• Separate measured from forecast. A recommendation built on a forecast should look different from one built on a reading, and say how reliable the forecast has been: "Make clear how well the system can do what it can do".
• Show the knock-on effects before the user accepts. If a change to an air handler affects the zones it feeds, light those zones in the twin first. The guideline is "Convey the consequences of user actions", and the feeds relationship is what makes it possible.
• Make dismissing and correcting cheap. "Support efficient correction" means the user can reject or adjust a recommendation and say why, without leaving their place.
• Hold back when the data is thin. "Scope services when in doubt" applies when a meter is offline or a model has little history. Say so, rather than recommending with false confidence.

Expect the AI layer to be the least mature part of the stack. The Abdelrahman review found that simulation, AI and machine learning, real-time capabilities and two-way data flow are not yet fully mature in built-environment twins. Design for recommendations people check, not ones they must trust.

Questions to answer before you design the twin

For a product lead scoping a twin, these questions decide most of the interface before anyone opens a design tool.

1. Which jobs does each role do daily, and which occasionally? Daily jobs get the default view.
2. Does the data carry relationships, through Brick, Haystack or an equivalent model? Without them, the twin cannot show what feeds what.
3. How often does each source update, and does every view show how old its data is?
4. What is the simplest model that answers "where is it" and "what is it connected to"?
5. Can every alert be opened in the twin, and every asset in the twin be found in the list?
6. Where will AI recommend, and what will it show as its reason?

This is the work we do in climate tech and energy software: deciding what each role sees, keeping measured figures apart from forecasts, and designing twin and site views that sit alongside the analytics rather than in front of them.