Aggregated views need a path down to single-robot detail

What it is

An aggregated view must keep a drill-down path to single-robot detail; the overview cannot be the only level of information a supervisor can reach. Drill-down means following a fleet anomaly, region, or task cluster all the way down to the specific robot, its raw sensor data, and an action entry point, while carrying along the filter context for why that particular robot came up — not leaving the supervisor to land on a detail page with no memory of how they got there.

Why it happens

This is a necessary complement to aggregation, not a weakening of it. Aggregation solves the problem of spotting roughly where a problem is; but the moment a supervisor needs to act on a specific robot — diagnose a fault, decide whether to recall it — they need that robot's full raw state. An aggregate value alone can only tell you how large the effect is, not who is driving the number, whether the underlying data is stale, or whether two opposing subgroups are canceling each other out inside the same average. If the aggregated view is a one-way, irreversible compression — raw data discarded, or simply no path back to it — the supervisor gets stuck at the aggregate level exactly when they most need to act, trading aggregation's efficiency for a loss of the ability to do anything about it. Bidirectional linkage between macro pattern and individual evidence is what makes aggregation serve action rather than mere browsing. One case that is easy to miss entirely: two roughly equal-sized subgroups moving in opposite directions cancel out at the aggregate level and produce a value that looks perfectly normal — half the fleet running high on battery, half running low, averaging out inside the normal range. That canceled-out split is invisible unless someone drills into the subgroup level; the aggregate alone gives no cue that there is anything to check.

Studying it

A standard test gives supervisors a task where spotting an anomaly in the overview must be followed by a concrete action, and compares no drill-down, a separate paginated list the supervisor has to search manually, and contextual drill-down — clicking directly on an aggregate chart element — on the time and number of steps from spotting the macro alert to identifying the root cause, along with how often the wrong robot gets picked and whether the original filter context survives a return to the overview. The design should measure hierarchy depth and network loading delay separately, so a pure loading-speed problem is not mistaken for a flaw in the information architecture. Test scenarios should specifically include the canceling-subgroups case described above, checking whether drill-down is the first point at which a supervisor even realizes a problem exists — that is the measure of the value drill-down actually adds in this situation.

Where it stops holding

How necessary drill-down is depends on whether the supervisory task actually requires acting on individuals: a dashboard meant only to convey overall health, with no expectation of individual-level action — a management-facing view, say — needs it less urgently; but an operational supervisory interface used to decide on interventions needs drill-down as a hard requirement, not a nice-to-have. Privacy, bandwidth, and access controls can also limit how much raw data is reachable, and not every macro-level anomaly has a single robot to blame. Drill-down should be honest about unavailable data or a shared common cause in those cases, rather than manufacturing a culprit just to close the loop.

Applying it

Make every element in the aggregate view — a colored cell, a data point — interactive, expanding directly into a contribution ranking, subgroup breakdown, single-robot state, and time-series evidence, instead of requiring the supervisor to remember an ID and go search another screen for it; keep the source filter and a return anchor on the detail page, and synchronize the selected object across levels. Verify it with an end-to-end task from spotting a problem in the overview to acting on a specific robot, recording steps, time, and how often the supervisor has to backtrack, and specifically test common-cause anomalies, missing data for some individuals, and cases where the clustering itself is wrong, to check whether drill-down traces honestly rather than inventing a plausible-looking explanation.

Related

• Same group: X7.07.1 Large numbers of robots need an aggregated overview, not a full list · X7.07.3 Outlier robots must stand out in an aggregated view, not get averaged away · X7.07.4 The level of aggregation should match the supervisory task's grain, not stay fixed
• Nearby: X7.04 Multi-robot supervision · X3.01 Visible Current State
• Search terms: drill-down interface · overview plus detail · human-swarm interaction