Insights
Not by default. Let conversation establish what someone needs to understand, and keep the dashboard as the workspace where they inspect, compare and act. Replacing the dashboard with chat is the wrong default, and AI does not make dashboards dead.
Replacing the dashboard with chat is the wrong default, and AI does not make dashboards dead. Conversation is good at establishing what someone needs to understand right now; a dashboard is good at being a persistent workspace they can inspect, compare and act in. The stronger design uses conversation to assemble the right workspace for the situation, then lets people carry on either by asking or by working the controls directly. Chat alone fits occasional, one-off questions, and a plain dashboard still fits a small set of known questions watched every day.
The middle model: intent sets the workspace, the workspace persists
The posts that rank for this question settle on a truce: chat for ad hoc questions, dashboards for monitoring. That says little about how one hands over to the other, and the hand-over is the design. It has three moves:
- Conversation establishes intent. The person says what they need to understand: "why did the east wing use more energy last night?", "which sites will miss their target this quarter?".
- The product assembles a workspace around it. The relevant measures, charts, assets and controls appear as a working view, not as a paragraph in a chat thread.
- Either path continues. The person can keep asking or work the controls directly. Both act on the same state, so a filter set by hand is visible to the next question, and the next answer updates the view rather than starting a new one.
The third move is the test. An answer that exists only as a message is lost at the next question and cannot be shared, compared or revisited tomorrow. An answer that becomes workspace state lets the conversation step aside.
The idea is older than large language models. In a 1997 debate with Ben Shneiderman, the MIT researcher Pattie Maes argued that agents and direct manipulation are not alternatives: "They are actually complementary metaphors" (Shneiderman and Maes, Interactions, 1997). Recent vendor moves fit her view. Microsoft says the Q&A experiences in Power BI go away in February 2027 and recommends Copilot instead (Microsoft Learn), and Tableau retired Ask Data in 2024 while it develops a new way to ask questions of data (Tableau help). In both cases the language feature went; the reports and dashboards stayed.
How Tcules applied it in ConnectX
ConnectX wanted an AI-first product for managing energy across commercial buildings, where facility, finance and sustainability teams needed different answers from the same energy system. Two directions were credible. A dashboard with an AI assistant was familiar, but its structure stayed fixed. An intent-led dashboard let the request decide which KPIs, assets, charts and digital-twin views appeared. Neither was enough alone: the fixed dashboard could not adapt across roles, and a chat reply could not give people lasting context or direct control.
We settled it in the ConnectX product definition by giving each surface the job it does well. Conversation set the intent; the product then built the dashboard that situation called for, and people could go on in plain language or work the controls, charts and twin by hand.
Design and development ran together, on an interim data layer with a path to ConnectX's own APIs. It is a demonstrated model, not a shipped product: it shows the interaction model can be defined and built, not that it delivers live telemetry, adoption or savings. Its lesson is narrower: an assistant beside a fixed screen makes information easier to reach, but the product changes only when a request changes what appears and what the person can do next.
What each surface does well
Deciding which jobs your users actually have is most of the decision.
| Job the person has | Dashboard | Conversation |
|---|---|---|
| Notice a change without asking | Strong: the view is there before anyone asks | Weak: nothing appears until someone asks |
| Compare the same measures over time or across assets | Strong: same view, same definitions on every visit | Weak: each answer is a new artefact that scrolls away |
| Point a colleague at the same numbers | Strong: a shared reference | Weak: two people can get different answers to the same words |
| Filter, select and drill in small, reversible steps | Strong: direct controls | Weak: every adjustment is another sentence |
| Serve many roles and questions without a permanent screen for each | Weak: crowded or fragmented | Strong: the request decides what is shown |
| Ask about something without knowing where it lives in the product | Weak: you must know the navigation | Strong: say it in your own words |
Three findings sit behind the dashboard column. In a survey of 83 dashboards, Sarikaya and colleagues found awareness dashboards read at a glance, such as those emailed to executives or shown on screens at work (IEEE TVCG, 2019). One reading: much of a dashboard's value lies in being seen without asking, and in being the same for everyone who looks. Microsoft's Copilot documentation says Copilot "doesn't always produce the exact same response, even with the same input" (Microsoft Learn), which is reasonable for an assistant and a problem for a shared reference. And Shneiderman described direct manipulation as "rapid incremental reversible operations whose effect on the object of interest is immediately visible" (IUI '97): a dashboard filter is exactly that, and a typed follow-up is not.
Conversation's weaknesses are documented too. People do not always know what they can ask, or how to phrase it so the system understands: Srinivasan and Setlur call these a lack of analytic guidance and poor discoverability of the input (Snowy, UIST 2021). And language is ambiguous: one word can match several columns or values. DataTone showed its interpretation as small widgets the person could change, and kept their corrections for later questions (Gao and colleagues, UIST 2015). In both systems the repair was something visible on screen, not more open conversation.
Bound the adaptive workspace so it can be built and trusted
An interface that can assemble anything cannot be specified, tested or trusted. Decide which situations the workspace is built for, and let the model choose among them rather than invent the screen.
For ConnectX we defined eight representative situations, covering system status, forecasting, asset performance and operational conditions. Each set out the request and the intent it signalled, the data and modules it needed, and the twin's behaviour and the next action. A language model used tools and API calls to connect a detected intent to that defined data and behaviour, so it could adapt the workspace without inventing it.
Analytics vendors build the same boundary from the data side: Power BI's "Prep data for AI" lets a model author set verified answers and AI instructions, and Databricks describes Genie Agents as environments where data teams configure trusted data, metrics and business rules. Until the model has been tested on your own data and questions, keep it choosing among defined situations.
A situation definition can be short. The first four rows are what each ConnectX situation specified; the last two are our recommendation for any new project.
| Field | What to decide |
|---|---|
| Request and intent | Example requests, and the intent they should be recognised as |
| Data | Which sources and measures answer it, with their definitions |
| Modules | Which charts, tables, maps or twin states make up the workspace |
| Next action | What the person can do from here, and with which controls |
| What persists | What stays in the workspace after the next question, and what can be shared |
| No match | What the product says when a request fits no situation, and which view it offers instead |
If the workspace lets the model act as well as show, the next decision is what it may do on someone's behalf and what has to happen before each action runs; that boundary is the subject of our AI copilot and agent UX design work. How much of the interface the model should generate is a separate question, covered in our article on AI interface design when the interface is generated.
One adaptive workspace or one dashboard per role?
One dashboard per role works while each role asks a small, stable set of questions. It strains when roles look at the same assets for different reasons, as ConnectX's three teams did: each new question crowds a dashboard or adds another, and questions that cross roles fall between them.
One adaptive workspace starts from the question, not the job title, and costs more up front: every situation has to be defined, its data agreed and its behaviour tested. Our judgement is that it earns that cost when three things are true: roles share the same underlying data, the questions vary more than a fixed set of screens can hold, and the situations recur enough to be worth defining.
Keep the parts people rely on still. In the adaptive-toolbar studies summarised in that generated-interface article, an adaptive area beside unchanged toolbars made people faster and was ranked first, while moving familiar buttons was only marginally faster. They were small studies of office software, so applying them here is our inference: keep the frame, navigation and core measures stable, with the adaptive workspace inside.
When a plain dashboard or chat alone is right
The middle model is not always worth building.
- Keep a plain dashboard when the questions are known and stable, people come back to watch the same measures, and several people need the same numbers with the same definitions: an operations wall, a weekly review, a regulated report. Conversation can help occasional users here; it should not replace the view.
- Use chat alone when questions are occasional and varied, the answer is read once, and nothing needs to be compared, kept or shared. Our B2B chatbot UX article sets out a short rule for when an assistant should be a chat window at all.
- Build the middle model when several roles share the same data but ask different questions of it, the situations recur, and an answer leads to something the person needs to inspect or do next.
If unsure, list the ten questions your users bring to the product and mark whether each answer needs to persist, be compared or be shared. Mostly yes points to a workspace; mostly no points to a conversation.