Visualization & Dashboards

The workhorse of a twin's interface is the dashboard: a screen that summarises the building's state and performance at a glance. The single most important design principle is hierarchy - the most important information, biggest and first; supporting detail, smaller and later; everything else, one click away. A dashboard where every number is the same size is a dashboard with no priorities, and a reader with no idea where to look.

That top layer is usually a small set of KPIs (key performance indicators) - the handful of numbers that actually express whether the building is doing well: energy use, comfort or air quality, open faults, maybe cost. Choosing them is a discipline in itself. A good KPI is tied to a decision or a goal; if a number changing would not change anyone's behaviour, it is decoration, not a KPI. Five well-chosen KPIs beat fifty gauges every time.

Below the KPIs sit the supporting views: time-series trends (how a value has moved over hours or days, which is often far more informative than a single instantaneous reading), comparisons and benchmarks, and breakdowns by floor or system. The art is arranging these so the eye travels naturally from how are we doing (KPIs) to what is going on (trends and breakdowns) to what needs attention (alerts) - a path, not a wall.

Good dashboards also respect a few quieter craft rules that separate a usable screen from a pretty one. Give a number context, not just a value: 640 ppm of CO2 means little on its own, but coloured against a healthy threshold it reads instantly as fine or not. Use colour sparingly and consistently - reserve red for genuine problems so it keeps its urgency, rather than painting the whole screen in a rainbow that signals nothing. Label units and time ranges so no one has to guess whether a figure is today or this month. And design for the glance: an operator should grasp the building's state in a couple of seconds, then dig deeper only where something invites it. These are small disciplines, but together they are the difference between a screen people rely on and one they learn to squint past.

The most eye-catching part of a twin interface is the spatial or 3D view - a floor plan or model with live data painted onto it, so you see where things are happening. Colour a plan by temperature and an over-cooled zone jumps out; place fault markers on a model and an operator finds the right room in seconds. When location matters, spatial views are genuinely powerful, and they communicate to non-technical people in a way tables never will.

But apply the same honesty as the anatomy lesson: spatial views earn their place only when the question is spatial. For a portfolio energy comparison, a plain bar chart beats a rotating building every time. A common failure is a beautiful 3D twin that looks spectacular in the boardroom and is useless at the operator's desk, because finding a number takes ten clicks through a 3D scene that a simple list would have shown instantly.

So choose the representation by the task. Use spatial views for locating and for communicating extent; use charts and tables for comparing and quantifying; use trends for understanding change over time. The best interfaces mix them, letting a user move from a spatial overview to a specific asset to its history. The 3D is a tool for certain questions, not a mandatory centrepiece - and treating it as compulsory is how interfaces get slow, heavy and unloved.

An alert is where a twin stops being passive and asks a human to do something - which makes alert design one of the highest-stakes parts of the interface. Get it wrong and you cause alarm fatigue: so many alerts, so many of them trivial or false, that operators start ignoring all of them, including the one that mattered. A flood of alerts is functionally the same as no alerts.

Good alerting follows a few hard-won rules. Prioritise ruthlessly - not everything is critical; rank by severity and consequence so the important few are not buried under the trivial many. Make each alert actionable: it should say what is wrong, where, how serious, and ideally what to do - AHU-1 filter pressure high, replace filter beats a bare code. Tune the thresholds so you are not crying wolf; an alert that fires ten times a day for nothing trains people to dismiss it. And route alerts to the right person by the right channel, so they reach someone who can act.

The deeper principle is that alerts should be decision-shaped, not data-shaped. The twin's job is not to tell the operator everything that is happening; it is to tell them the few things that need a decision, clearly enough to act on. That is a very different design goal from a dashboard that shows all the data - and confusing the two is how twins drown their own users.

Alerting also improves when it is treated as something that gets tuned over time, not set once and forgotten. Every alert that fires should, in effect, be auditable: did anyone act on it, and was the action worth the interruption? Alerts that fire constantly and are always dismissed are candidates for a higher threshold or deletion; conditions that hurt but never alerted are candidates for a new rule. Some teams add a simple acknowledgement step, so an operator marks an alert as seen and handled, which both prevents duplicate chasing and creates a record of what the building actually demanded attention for. Over months this feedback loop is what keeps an alert list lean and trusted rather than letting it silt up into noise - and a trusted alert list is worth far more than an exhaustive one.

Threaded through all of this is one principle worth stating on its own: design the twin for the person who uses it every day, not for the person you are selling it to. These are different audiences with opposite needs. The demo audience wants spectacle - a swooping 3D fly-through, dense screens full of live numbers, everything moving. The daily operator wants the opposite: calm, clarity, the few things that matter, and fast answers to real questions. Optimise for the demo and you get a twin that wins the pitch and gathers dust.

So design from the user and the task backwards. Ask who will actually sit in front of this - a facilities manager, an energy analyst, a tenant, a portfolio owner - and what decisions they make, because each needs a different view. A facilities manager needs faults and locations; an energy manager needs consumption and trends; an executive needs a few portfolio KPIs; a tenant needs simple comfort and control. One-size-fits-all dashboards serve none of them well; role-based views serve each.

And test it the only way that counts: can a real user answer their real question, quickly, without a guide standing next to them? If not, it is a demo, not a tool - however impressive it looks. The whole course has built toward a twin that serves a decision; the interface is where that promise is kept or broken. A modest dashboard that operators actually use beats a dazzling twin they quietly abandon.