ConnectX: Building Energy Management / 0 to 1 AI Product UX

01 / THE DILEMMA

A vision, a deadline, and no product structure

ConnectX wanted an AI-first product for managing energy across commercial buildings. It arrived with personas, KPIs, feature ideas and AI-generated concepts of a dashboard and digital twin. The ambition was clear. The product model was not. Facility, finance and sustainability teams needed different answers from the same energy system, but the interface could not permanently show every possible view.

• One interface per role, or one adaptive workspace?
• How does a request become specific data, modules and actions?
• When does the digital twin explain something useful?

02 / THE REAL QUESTION

Does AI sit inside the dashboard, or decide what it shows?

Two directions were credible. A dashboard with an AI assistant was familiar and predictable. AI helped users operate an interface whose structure remained fixed. An intent-led dashboard allowed the request to determine which KPIs, assets, charts and twin views appeared. Neither was sufficient alone. A fixed dashboard could not adapt across roles. A chat response could not provide persistent context and direct control.

03 / THE DECISION

Conversation determines intent. The dashboard remains the workspace.

Conversation established what the user wanted to understand. The product then assembled a persistent workspace around that intent. Users could continue in natural language or work directly with the controls, charts and twin.

THE PRODUCT DECISION

The product did not replace the dashboard with chat. It used conversation to construct the right dashboard for the situation.

04 / MAKING IT IMPLEMENTABLE

Eight scenarios, not infinite freedom

An adaptive interface becomes credible only when its freedom has boundaries.

The team defined eight representative situations covering system status, forecasting, asset performance and operational conditions. Each one specified the request and detected intent, the data and modules required, and the twin behaviour and next action.

An LLM used tools and API calls to connect detected intent to defined data and interface behaviour. The model could adapt the workspace without inventing it freely.

System flow: User Intent → LLM Reasoning Layer → Intent Classification → Tool / API Calls → Data + Modules → Adaptive Dashboard + Digital Twin.

05 / THE TWIN'S JOB

A digital twin that explains, rather than replicates

Early concepts explored detailed 3D, live mapping and realistic building models. More fidelity did not automatically create more understanding.

The useful questions were simpler: which assets are connected, where are they, what state are they in, and which one matters now?

The twin became an abstract 2.5D model. Assets could be highlighted, dimmed or brought into focus according to the request.

THE TWIN'S JOB: The twin needed to explain the energy system, not count the building's windows.

06 / WHERE IT STANDS

A demonstrated model, not a shipped outcome

Design and development ran together because the interaction model depended on what could actually be rendered, loaded and called. The demonstration used an interim data layer while preserving a path to ConnectX's eventual APIs.

The work demonstrated defined scenarios connecting conversation, dashboard modules and the digital twin. It did not demonstrate live telemetry, adoption, operational savings or commercial outcomes.

WHAT THIS PROVES

Adding a conversational assistant improves access to information. It does not make the product AI-native.

AI becomes part of the product model when intent changes what appears, how it is organised and what the user can do next.