菜单
“Rules for operational dashboard UX/UI: actionable error states, drill-down architecture, notification design, data visualization, progressive disclosure, performance perception, and accessibility. Load when building, reviewing, or auditing any operational or monitoring dashboard.”
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Keep a live interactive chat session coming back to itself, visibly, after a usage/session cap interrupts it, never a silent background process. Invoke with /qq-cap-resume, or say “keep this session alive,” “resume yourself after the cap,” “don’t go dark on me,” any time a long interactive burn needs to survive a 5-hour session cap or ride out to a weekly reset without leaving you staring at a dead thread.
The unbounded end of the AFK spectrum: spend whatever it takes for quality, budget isn’t the constraint. Stand up a self-healing, fully-autonomous “kitchen-sink max-effort” campaign for a big multi-day initiative: resilience first, creative meta strategy, workflows spawning workflows, audit-gated quality, a phone-glanceable status surface with a proud wins list, and a long living tasklist. Invoke when you say “go HAM”, “go-ham”, “go afk ham”, “qq-go-afk-ham”, “kitchen sink”, “blow me away”, “use all the quota”, or hand it a large ambitious build to run autonomously for hours or days. For the frugal end, use `qq-go-afk-lean`; for the adaptive middle, use `qq-go-afk-smart`.
The adaptive middle of the AFK spectrum: picks the right model task by task, moment by moment, instead of committing to either extreme. Stand up a calm, self-healing, fully-autonomous overnight worker for a well-scoped punch list: the top-tier model writes strict specs and does quality control, cheap and free models do the grunt work, one bounded task per cycle, each one deployed and live-verified, a phone-glanceable status surface, and a durable done log. Invoke when you say “go afk smart”, “go-afk-smart”, “qq-go-afk-smart”, “go smart”, “bounded overnight”, “delegate and verify overnight”, or hand it a finite, well-specified backlog (a punch list, a rollout, a sweep) to grind down autonomously while you sleep, without the kitchen-sink fan-out of go HAM. For the unbounded end, use `qq-go-afk-ham`; for the frugal end, use `qq-go-afk-lean`.
The moment a real, avoidable mistake happens, name it plainly, root-cause the general class of it rather than just this one instance, and fix it at a level that prevents a repeat, not a note that gets written and forgotten. Then, before starting work that looks like it could repeat that shape, check the log first. A second occurrence of the same mistake means the note wasn’t enough, and it needs to become a real check instead of a reminder. Invoke with /ww-mistake-ledger, or say “log this mistake,” “close the loop on this,” “add this to the mistake log,” “check the mistake log first,” right after a preventable error, or right before starting work that resembles one already logged.
Ask what would make this fail before you build it, not after. A one-question design-time gate, imagine it’s already broken three months from now, work backward to the most likely cause, and let the answer change the plan instead of just getting noted and ignored. Works on code, an automation, a process, or a decision. Invoke with /ww-premortem, or say “what breaks this in three months,” “pre-mortem this,” “why would this fail,” “before I build this,” at the moment you’re about to commit to an approach, not after you’ve already started.
Before filling a gap in what you know with a guess, check whether the guess is load-bearing. If getting it wrong would mean redoing real work, or building on a false premise, ask a real question with concrete options instead of assuming silently. If it’s genuinely low-stakes, state the assumption out loud and keep moving rather than stalling on it. Works on any ambiguous request, with or without an AI agent involved. Invoke with /ww-questioning, or say “wait, let me ask first,” “is this load-bearing,” “check before I guess,” “clarify before building,” whenever a request has more than one reasonable reading and you’re about to just pick one.
| name | ww-dashboard-ux |
| description | “Rules for operational dashboard UX/UI: actionable error states, drill-down architecture, notification design, data visualization, progressive disclosure, performance perception, and accessibility. Load when building, reviewing, or auditing any operational or monitoring dashboard.” |
Part of Claude Code operator skills: a collection of skills for running a real Claude Code setup.
An operational dashboard is different from a marketing page or a settings screen: someone reaches for it specifically because something might be wrong, often while stressed, often mid-incident. The rules below exist because dashboards built without them fail in the same handful of predictable ways: errors with no path to resolution, status dots nobody colorblind can read, metrics with no idea how stale they are, buttons that silently do nothing.
These rules were produced through an adversarial synthesis process: several proposer passes generated candidate principles against a real production dashboard, then a dedicated skeptic pass challenged every one of them. What survived below is only what passed three bars: unconditional, falsifiable, and enforceable at build or review time. Everything that was situational, subjective, or unenforceable got cut, so what’s left is meant to be applied without “it depends.”
| Mode | Trigger | What it does |
|---|---|---|
| 1: Full audit | No args, “full audit”, “review everything” | Runs all 10 frameworks against the target, serial with proposed fixes |
| 2: Focused area | Framework name or area (fuzzy matched) | Runs one framework; shows 2–3 matches if ambiguous |
| 3: Checklist | “checklist”, “pre-launch”, “quick check” | Runs the 40-item checklist against the target |
| 4: Patterns reference | “patterns”, “how do I…”, “what’s the right way to…” | Returns relevant pattern(s) without running an audit |
Default: If invoked without args and no target is provided, ask which mode is wanted and what dashboard to audit.
These are unconditional. No exceptions. No “it depends.” A dashboard that violates any of these is incomplete regardless of everything else it does well.
Every error state and every alert must contain:
Enforcement: Code review checklist. Screenshot review: does the error message answer all three? If “Error: null” appears anywhere in production, this law is violated.
Positive example: a crash notification for a background job: “Price-feed scanner crashed (exit 1). This stops live data collection. [Restart] [View logs].” All three parts present.
Anti-pattern: One metrics panel shows a spinner indefinitely with no error state at all. The user has no idea what happened, why, or what to do.
Scope: all error states: API failures, timeout, rate limit, permission denied, empty state (zero results), and partial failure (some data loaded, some failed). Transient errors (auto-resolving in under 3 seconds) may omit parts 2 and 3, but must still name part 1.
Every status indicator must use at minimum two independent encodings. Color alone is insufficient. Required combinations:
Enforcement: Automated test: convert screenshots to grayscale. All status distinctions must remain readable in grayscale. Any status indistinguishable without color fails.
Positive example: Grafana alert states: an “Alerting” badge uses red background + text label + bell icon. A colorblind user has two other signals.
Anti-pattern: Agent status dots using green/red with no label. A colorblind user loses all status information.
Standard: WCAG 2.1 AA minimum. 4.5:1 contrast ratio for text on colored backgrounds. 3:1 for large text.
Any metric that could be stale must show how old it is. “Stale” is defined as: data older than 5 minutes, OR data from a batch job with a known freshness window.
Required display:
Enforcement: code audit: grep for metric display components without an associated timestamp. Data age must be machine-readable (ISO timestamp in the data layer), not just displayable.
Positive example: a two-phase load pattern: cached data shows immediately with a subtle “updating…” indicator, then gets replaced with fresh data. The age of the cached data stays visible throughout.
Anti-pattern: Summary dashboards that show aggregate values with no indication of the aggregation window (is this last-5-minutes or last-24-hours?). Identical numbers could mean very different things.
State age vs. refresh age are different. “Data updated 2 hours ago” is not the same claim as “dashboard last refreshed 30 seconds ago.” Both must be visible. Refreshing a stale cache tells the user the dashboard is working, not that the data is fresh.
Operational dashboards are accountability surfaces. Every action taken from the UI must be recorded:
| Field | Required | Example |
|---|---|---|
| Actor | Who | “jane@example.com” |
| Timestamp | When (UTC ISO 8601) | “2026-04-06T19:23:45Z” |
| Action | What | “restarted price-feed scanner” |
| Outcome | Success or fail | “success” / “error: exit 1” |
Constraints: Logs are immutable (append-only). Queryable by all four fields. Retained a minimum of 90 days. Available in-dashboard (no separate log tool required). Machine-readable (JSON) and human-readable (summary view).
Enforcement: Schema-level: insert-only table, no UPDATE or DELETE on log rows. Integration test: take an action, query the log, verify all four fields are present.
Anti-pattern: Dashboards with “restart” buttons that have no audit trail. When something breaks after a restart, there’s no way to determine who restarted it, when, or whether it succeeded. The action surface becomes a liability.
Every modal (overlay, drawer, dialog, popover) must close via:
Never auto-close on timeout. The user may be reading. Auto-closing while a user is acting is a data-loss risk.
Dismissibility is gated by urgency:
Enforcement: e2e test: open modal, press Escape, modal closes. Open modal, wait 30 seconds, modal still open. Open a P0 alert, verify no dismiss button exists, only action buttons.
Positive example: a notification snooze with 1h / 4h / Tomorrow / Dismiss options: P1-level gating with clear choices.
Anti-pattern: modal libraries left with click-outside-to-close enabled and no static backdrop: clicking outside closes the modal during form fill.
Urgency and severity are different things. A low-severity bug that blocks the user right now is P0. A high-severity outage affecting 1,000 users that can’t be fixed right now is P1.
Urgency taxonomy (single shared definition across the UI):
| Level | Window | Surface | Dismissibility |
|---|---|---|---|
| P0 | Immediate block | Full-width banner + optional modal | Non-dismissible |
| P1 | Within 1 hour | Toast notification | Snooze (1h / 4h / Tomorrow / Dismiss) |
| P2 | Within 1 day | Notification center sidebar | Dismiss |
| P3 | Informational | Notification center only | Dismiss immediately |
Distribution constraint: P0 alerts must be ≤5% of all alerts in any 24-hour window. If P0 volume exceeds 10%, that’s a signal P0 is being over-used (urgency inflation), not that everything is truly critical.
Enforcement: Design system enforces surface by urgency (a P0 component maps to the full-width banner template, not a generic alert). Code review: any priority="P0" must be justified in a comment.
Every view that reveals more detail must:
Never auto-navigate. A click on a metric should always do one thing (drill in, or navigate to a new page) and be visually differentiated (a drill-in affordance is not the same as a link). The user must know before clicking what will happen.
Enforcement: Count nesting depth in code (depth parameter or router stack). e2e test: navigate to depth 4, verify no further drill-down option exists. Screenshot test: every nested view has a visible breadcrumb and close button.
Positive example: A detail overlay that opens over the main view, has an explicit close button, and returns to the exact previous scroll position on close.
Anti-pattern: Notification action links pointing to dead hash anchors (#logs/{label}) that don’t correspond to any real element on the page. The drill-down exists in intent (the notification references logs) but the path is actually broken.
A button or link that does not work is worse than no button at all. A broken action teaches the user that actions on this dashboard don’t work, which destroys trust in every other action too.
Every interactive element in an action surface (restart, dismiss, retry, view, export) must:
Enforcement: Integration tests on all action endpoints. No CLI commands displayed as copyable text (this is not an action, it is documentation). If the action requires a CLI command, wrap it in a button that executes the command and shows the result.
Anti-pattern: An offline banner that shows a raw CLI command (e.g. launchctl start com.example.price-scanner) as a code block. This is documentation masquerading as an affordance. The user has to copy it, open a terminal, and paste it: three steps instead of one click.
Ten expert lenses for auditing operational dashboards. Each maps to a body section below. Run all 10 for Mode 1 (full audit); run one or two for Mode 2 (focused area).
| # | Framework | Key question | Section |
|---|---|---|---|
| 1 | Error state patterns | Can every error be diagnosed AND fixed from the UI? | §Error states |
| 2 | Notification design | Is each alert actionable, triage-appropriate, and plain-language? | §Notification design |
| 3 | Drill-down architecture | Can every metric be traced to raw data? | §Drill-down architecture |
| 4 | Data visualization | Does chart type match data type? Is encoding accessible? | §Data visualization |
| 5 | Actionability | Is every action surface real, accessible, and audited? | §Actionability |
| 6 | Performance perception | What does the user see while data loads? | §Performance perception |
| 7 | Accessibility | Does the dashboard work without color? Without a mouse? | §Accessibility |
| 8 | Temporal patterns | Does the user know how fresh each metric is? | §Temporal patterns |
| 9 | Navigation & wayfinding | Can the user always find their way back? | §Navigation |
| 10 | Data provenance | Can the user tell real data from cached, batch, or demo data? | §Data provenance |
references/error-and-notification-patterns.md when auditing or building error states, empty states, or notification/alert UI.references/drilldown-and-navigation-patterns.md when auditing or building drill-down hierarchies, breadcrumbs, or overlay close behavior.references/dataviz-and-provenance-patterns.md when choosing a chart type, displaying data age, or distinguishing real, batch, or demo data.references/actionability-and-performance-patterns.md when designing action buttons, destructive-action confirmation, or loading/skeleton states.references/accessibility-and-layout-patterns.md when auditing accessibility, multi-role views, data-table typography, or mobile/responsive layout.references/pre-audit-interview.md when running Mode 1 (full audit) and the pre-audit questions aren’t already answered by inspection.references/grounding-examples-and-learnings.md for worked examples from a real production dashboard build, plus the full 40-item pre-launch checklist (Mode 3).This skill pairs well with a broader UX audit process if you run one separately (for instance a general-purpose UX audit skill, if you have one installed). This skill’s frameworks are dashboard-specific and don’t try to replace a general UX pass.