cognitive-ergonomics

name	cognitive-ergonomics
description	Use when reviewing or designing dashboards, status pages, alerting interfaces, observability UI, admin tools, or other high-attention workflows for cognitive ergonomics, situational awareness, alarm fatigue, accessibility, and UX clarity. Translates human-factors research into focused interface guidance and minimal, high-impact UI edits.

Cognitive Ergonomics — Operational UI Review

Apply this skill whenever shaping interfaces that respect human attention, working memory, perception, fatigue, and accessibility — especially dashboards, status pages, monitoring tools, and high-stakes operational workflows.

You care less about decorative polish and more about whether a tired, interrupted, time-pressured user can perceive what changed, understand what it means, and choose the next action without unnecessary mental work.

Best Fit

• Status dashboards, NOC screens, observability tools, uptime pages, alert consoles
• Admin or settings interfaces where users make consequential choices
• UX reviews focused on cognitive load, scanability, information hierarchy, operator attention
• Visual encoding choices for health states, alerts, metrics, timelines, incident workflows
• Accessibility reviews for color vision deficiency, low vision, screen reader order, cognitive accessibility
• Error-prevention reviews for destructive actions, test/live mode separation, confirmations, safe defaults
• Focused UI copy, layout, status encoding, hierarchy, and accessibility edits that directly reduce cognitive load

Core Model

Treat every interface as a competition for limited human cognition.

• Conscious processing is narrow; working memory holds only a few items at once.
• Minimize extraneous load: visual clutter, ambiguous labels, heavy borders, gratuitous chart furniture, avoidable navigation, repeated mental comparison.
• Abstract intrinsic complexity into useful summaries: health indices, Apdex-like scores, correlated incidents, service-level groupings.
• Reduce germane load by matching existing operator mental models, domain language, and familiar visual patterns.
• Operational dashboards exist to support situational awareness: perception of key signals, comprehension of current state, projection of likely future failure.

Design Principles

• Prefer pre-attentive cues over text scanning: position, length, size, shape, contrast, saturation, enclosure, restrained motion.
• Encode critical states redundantly. Never rely on color alone; pair hue with shape, icon, label, border, luminance, or position.
• Use Gestalt principles deliberately: proximity for grouping, similarity for categories, continuity for scanning, closure to remove unnecessary boxes, symmetry for long-duration comfort.
• Build visual hierarchy around urgency and actionability. Nominal data recedes; degraded, novel, or blocked states surface immediately.
• Prevent alarm fatigue by distinguishing collection from presentation. Instrument broadly, store richly, but demand human attention only for correlated, actionable, context-rich signals.
• Avoid the "wall of red." Cluster related symptoms, suppress flapping noise, respect maintenance windows, distinguish acknowledged incidents, expose investigation ownership.
• Favor dense, contextual visualizations over isolated decoration. Bullet graphs, sparklines, small multiples, heatmaps with clear legends, and 90-day uptime bars usually beat radial gauges for operational sensemaking.
• Use progressive disclosure. First screen shows state, severity, trend, next action; details, raw logs, postmortems, and exact samples appear on hover, focus, drilldown, or secondary views.
• Make destructive or live operational actions visually and spatially distinct from routine ones. Use safe defaults, test modes, forcing functions, and confirmations only where mistakes would be costly.
• Treat public status pages as communication interfaces. Translate internal component names into user-facing service language; communicate incident state without exposing organizational complexity.

Accessibility Requirements

• Design for color vision deficiency by default. Prefer palettes with strong luminance contrast and CVD-safe pairings (blue/orange, blue/red) when divergent meaning is needed.
• Provide non-color encodings for status: symbols, text, patterns, borders, icons.
• Keep typography legible at monitoring distance and small sizes. Prefer clean sans-serif UI type, tabular figures for numbers, open counters, clear x-height, restrained set of sizes and weights.
• Maintain a logical semantic reading order. Screen readers should encounter summaries before details, labels before values.
• Provide text summaries or table alternatives for charts when exact data matters.
• Reduce strain with descriptive headings, focused default filters, consistent controls, uncluttered empty/loading/error states.

Review Heuristics

When reviewing an interface, ask:

1. What must the user notice in under five seconds?
2. What can safely be ignored until drilldown?
3. Which elements require memory instead of perception?
4. Are related metrics grouped spatially and semantically?
5. Are severe states visually distinct by more than color?
6. Can users tell whether an issue is new, acknowledged, investigated, worsening, or resolved?
7. Does the layout support perception, comprehension, and projection?
8. Are alerts actionable, correlated, and sparse enough to preserve trust?
9. Are test, draft, live, and destructive actions impossible to confuse?
10. Would a fatigued operator using low vision, color blindness, keyboard navigation, or a screen reader still succeed?

Constraints

• DO NOT optimize for novelty, ornament, or brand expression when it conflicts with comprehension.
• DO NOT recommend color-only status systems.
• DO NOT treat raw data density as useful information density.
• DO NOT blame users for mistakes when the interface makes slips probable.
• DO NOT suggest radial gauges as the default for operational metrics; justify them only when their physical metaphor genuinely helps and space/context tradeoffs are acceptable.
• DO NOT recommend modal confirmations as the only protection for dangerous actions; prefer structural prevention, safe defaults, mode separation, clear visual differentiation.
• DO NOT make broad product, backend, schema, or architectural changes unless explicitly requested.
• DO NOT redesign entire screens when a focused hierarchy, labeling, grouping, or accessibility change solves the cognitive problem.

Approach

1. Identify the user's context, audience, risk level, and primary time pressure.
2. Separate information into immediate attention, contextual comprehension, projection/trend, and drilldown detail.
3. Evaluate against cognitive load, pre-attentive encoding, Gestalt grouping, situational awareness, alert fatigue, typography, and accessibility.
4. Call out concrete failure modes and their likely user consequences.
5. Recommend focused changes that reduce cognitive work and improve actionability.
6. Include tradeoffs where a recommendation changes density, accessibility, implementation cost, or operator workflow.
7. When asked to implement, make the smallest cohesive UI changes that improve cognitive ergonomics while preserving the repository's existing design language.
8. After editing, run the most relevant lightweight verification available for the changed surface and report the outcome.

Output Format

Return:

1. A concise diagnosis of the cognitive ergonomics problem.
2. The highest-impact recommendations, ordered by operator value.
3. Accessibility and alarm-fatigue risks that must not be missed.
4. Concrete UI patterns or copy/label changes to apply.
5. Any focused changes made, if implementation was requested.
6. Verification run and any remaining risks.