Dashboards & Decision Support

A dashboard is the bridge from the twin's data and simulation to a human decision, and it only works if it is built backward from the decision rather than forward from the data. The failing dashboard starts with 'here is all the data we have, let us show it'; the good one starts with 'here is the decision someone has to make, what do they need to see to make it well, and nothing more.' Everything else follows from that inversion.

The building blocks are few. A KPI - a key performance indicator - is a single number chosen because it tracks something that matters for a decision: the share of the transit network running on time, the number of wards breaching an air-quality threshold, the percentage of water pumps operating normally. A KPI is a choice, and a value-laden one: what you measure is what you manage, and what you leave unmeasured tends to be neglected, so the selection of KPIs is quietly one of the most consequential design acts in a twin. A trend shows whether a KPI is getting better or worse, which is often more decision-relevant than its current value. An alert is the dashboard reaching out to say something needs attention now - and alerts are where dashboards most often fail, either by crying wolf until everyone ignores them, or by staying silent when it matters.

Above the building blocks sits the real purpose: decision support. A good dashboard does not just display state; it helps someone decide and act. The best ones answer, for their user, three questions in order - what is happening, is it getting better or worse, and what should I do about it - and they rank by action, not by data category, so the most important thing to do is the most prominent thing on the screen. And, crucially, they tell the truth about themselves: when was this last updated, which sensors are offline, is this figure measured or modelled. A dashboard that hides its own data quality is dangerous precisely because it looks authoritative. Remember the course's boundary: a decision-support dashboard supports a decision; the accountable human, and where it is binding the authority and the law, make it. The dashboard informs the operator; it does not get to run the city on its own.

The single biggest reason dashboards fail is that they are built for no one in particular - a generic 'city dashboard' that tries to serve everyone and therefore serves no one. The same twin should produce different dashboards for different users, because a planner, an operator and a citizen are making completely different decisions on completely different horizons, and a view that fits one fits the others badly.

The operator - someone running transit, water, traffic or emergency response - is making decisions on a horizon of minutes. They need live state, clear alerts ranked by what to do, and the fastest possible path from noticing a problem to acting on it. Clutter is dangerous here; an operator's dashboard should be ruthlessly sparse, surfacing the two or three things that need action now and suppressing everything that does not. The planner - someone shaping the city over months and years - is making a different kind of decision entirely. They need trends, comparisons and scenario outcomes, not live blinking lights; their dashboard should let them see how things have moved, compare options, and weigh a decade-long choice. A real-time alert is noise to a planner; a five-year trend is noise to an operator. Same twin, opposite views.

The citizen is the audience twins most often forget and most often mistreat. A citizen is not running the city or planning it; they are trying to understand something that affects their life - is the air safe today, what is being built near me, is the bus coming - and to trust, or hold to account, the people who are running it. A citizen-facing view must be plain, honest and free of jargon, and it carries a special duty of truthfulness because it shapes public trust. It is also where equity shows up sharply: a view that assumes a fast connection, a powerful device or fluency in one language quietly excludes the people a public twin most owes a duty to. Designing for the citizen well - plain, accessible, honest - is both a communication skill and an ethical stance. Across all three users, the rule is the same: name the user and their decision first, then design the smallest view that serves it, and never imagine one dashboard can be all three at once.

Two temptations wreck dashboards, and both are about vanity rather than use. The first is dazzle: the urge to make the dashboard impressive - more charts, more live feeds, a 3D globe spinning in the corner, a video wall that looks like a spaceship. Dazzle is seductive because it photographs well and impresses visitors, and it is precisely why control-room walls fill with metrics nobody acts on. Every element that does not serve a decision is not neutral; it is clutter that hides the elements that do. The discipline of a good dashboard is mostly the discipline of leaving things out - of defending the empty space that keeps the few important things legible.

The second temptation is false precision and hidden uncertainty. A dashboard shows numbers, and numbers look certain even when they are not. A KPI built on data from half the sensors, or a figure that is really a model estimate, looks identical to a solidly measured fact unless the dashboard tells you otherwise - and a confident-looking number drives confident action, which is dangerous when the number is shaky. Honest dashboards therefore wear their limits openly: they show when data was last updated, flag when sensors are offline or a feed is stale, distinguish measured from modelled values, and where it matters show a range rather than a false point estimate. This is not pedantry; it is the difference between a tool that supports good decisions and one that manufactures false confidence - the exact peril this course keeps naming.

There is also an honesty about what the dashboard is not allowed to do. A decision-support view can rank options, surface alerts and even recommend - but the moment it is treated as the decider, the twin has overstepped. The accountable human must stay in the loop, able to see the reasoning, override the recommendation, and be answerable for the choice; and where the decision is binding - a planning approval, an emergency order, an infrastructure commitment - it belongs to the authority and the law, with the dashboard as input, never as the authority. A well-designed dashboard makes this relationship clear: it supports, it informs, it does not pretend to decide. Insight and honesty, not dazzle and false confidence - that is the whole craft, and it is far harder and far rarer than making something that merely looks impressive on a wall.

The most common fate of a twin's dashboard is the saddest: it gets built, it gets demonstrated, it goes on a wall or a webpage, and then nobody acts on it. Understanding why this happens is the best protection against it, because the causes are predictable and mostly avoidable.

Sometimes it is the inversion failure from the first section - the dashboard was built forward from the data instead of backward from a decision, so there is no decision it actually serves. Sometimes it is the generic-user failure - it was built for everyone and fits no one's real workflow, so the operator keeps using their old tools and the planner keeps using their spreadsheets. Sometimes the alerts cried wolf until people muted them, or the data quality was so poor that users learned not to trust the numbers, and a dashboard nobody trusts is a dashboard nobody uses. Sometimes it is organisational: the dashboard shows a problem but nobody has the authority, budget or mandate to act, so the insight just sits there blinking. And sometimes it is simply that acting on the dashboard was never wired into how the organisation actually makes decisions - the dashboard lives on a screen and the decisions happen in meetings that never look at it.

The cure is to design the dashboard as part of a decision process, not as an artefact. Ask, before building: whose decision, made how, and how will this view actually enter that decision? If the answer is vague, the dashboard will join the graveyard regardless of how good it looks. Wire it to a real workflow, give it to the actual user and watch whether they use it, prune relentlessly to what drives action, keep the data trustworthy and honest about its gaps, and make sure someone has both the information and the authority to act on what it shows. A dashboard that changes one real decision for the better is worth more than a hundred-metric video wall that changes nothing.

This closes the loop the whole course has been tracing: a model becomes a twin only when there is a feedback loop into decisions, and the dashboard is usually where that loop is won or lost. All the ingestion, modelling, simulation and visualisation upstream produce value only if, at this last step, a real person makes a better decision because of what they see - and acts on it. Get this step wrong and the most sophisticated twin in the world is an expensive screen. Get it right and even a modest twin earns its keep. The figures, thresholds and capabilities on any real dashboard are illustrative and context-dependent, and the binding decisions stay with the accountable humans, the authorities and the law - but the craft of turning the twin into an honest, acted-upon decision is what makes the whole enterprise worthwhile.