The problem: An operational dashboard gets reached for at the worst possible moment: someone thinks something might be wrong, and they’re often already stressed. That’s exactly when a spinner with no error state, a status dot a colorblind person can’t read, or a metric with no idea how stale it is does the most damage, and dashboards built without a deliberate stance on these fail in the same handful of predictable ways, over and over.
Eight iron laws, unconditional, no “it depends.” They survived an adversarial process on purpose: several passes proposed principles against a real production dashboard, then a dedicated skeptic pass tried to kill each one, and only what stayed unconditional, falsifiable, and enforceable made the final eight.
| Iron law | The one-line test |
|---|---|
| Error messages | Says what happened, why it matters, what to do right now |
| Status indicators | Never color alone; at least two independent encodings |
| Metric age | Every stale-capable metric shows how old it is |
| Action logging | Who, when, what, outcome, on every user-initiated action |
| Modals | Close explicitly (button or Escape), never by timeout |
| Alert triage | Urgency, not subjective severity |
| Drill-down | Bounded depth, breadcrumbs, an explicit close |
| Action surfaces | Tested to a live destination, never assumed to work |
Ten expert-lens frameworks (error states, notification design, drill-down architecture, data visualization, actionability, performance perception, accessibility, temporal patterns, navigation, data provenance) sit behind the table for a full audit; run one framework for a focused pass, or all ten for a pre-launch check.
Part of Operator Skills, a collection of skills for running a real Claude Code setup.