Operational UI Design
Operational UI Design
Design the interface as an operational tool, not a marketing experience. Apply aerospace-style design discipline — clarity, visible state, unambiguous action — without copying cockpit aesthetics.
Before: A form has a button labeled "Submit," a header that just says "Dashboard," and a red-bordered input with no message.
After (corrections):
- "Submit" → "Submit Invoice #4521" (states exactly what action will occur)
- "Dashboard" → "Invoice #4521 — Draft" (states current context)
- Red border → red border + inline text: "Amount must be greater than $0"
Same layout, zero redesign — just removed ambiguity about context, action, and failure.
- Make context, system state, and the primary task immediately clear.
- Keep normal conditions visually calm; reserve emphasis for meaningful state or priority.
- Make warnings, failures, and required actions unmistakable.
- Prefer predictable placement and explicit labels over clever interactions.
- Show users what happened, what was affected, and what they can do next.
- Remove elements that don't communicate hierarchy, grouping, state, affordance, or feedback.
Progress:
- [ ] Step 1: Identify the single primary task this screen serves
- [ ] Step 2: Identify current context and current system state to surface
- [ ] Step 3: Apply screen order: context → state → primary action → problems → supporting details → recovery options
- [ ] Step 4: Draft a plain-text wireframe
- [ ] Step 5: Apply interaction rules (see below) to every control and label
- [ ] Step 6: Define explicit loading, empty, success, and failure states
- [ ] Step 7: Remove decoration that doesn't encode hierarchy, state, or affordance
Interaction rules to apply in Step 5:
Prefer: specific action labels, visible controls, stable tables/forms, inline validation, explicit state displays, keyboard-accessible interactions, progressive disclosure of detail.
Avoid: decorative dashboards, hidden hover-only actions, unexplained icons/abbreviations, multiple equally prominent actions, generic errors, excessive cards/shadows/animation/color, dark styling with no functional reason.
Progress:
- [ ] Step 1: Identify the primary user task for this screen
- [ ] Step 2: Check whether context and system state are visible
- [ ] Step 3: Check whether the next action is obvious and singular
- [ ] Step 4: Find missing loading, empty, success, failure, or recovery states
- [ ] Step 5: Identify inconsistent placement, vague labels, unnecessary complexity
- [ ] Step 6: Check keyboard use, focus visibility, labeling, contrast, non-color status cues
- [ ] Step 7: Draft findings using the severity/problem/impact/correction format
- [ ] Step 8: Select the three highest-value changes and note what should stay unchanged
Report each finding as:
- Severity: Critical, significant, or minor
- Problem: Specific observable issue
- Impact: Effect on comprehension, task completion, or error risk
- Correction: Simplest practical improvement
Conclude with: the three highest-value changes, elements that should remain unchanged, and any missing information or assumptions made.
Example 1: Label correction Input: Button labeled "Submit" on an invoice form. Output: Relabel to "Submit Invoice #4521." Removes ambiguity about what object the action affects — no layout change needed.
Example 2: Status visibility Input: A sync feature shows a spinning icon in the corner with no text, and no indication of success or failure afterward. Output:
- Severity: Significant
- Problem: Sync state is only visible via an unlabeled spinner; no success or failure state is shown.
- Impact: Users cannot confirm whether data was saved, leading to duplicate submissions or data loss.
- Correction: Add inline text state: "Syncing…" → "Saved at 3:42 PM" or "Sync failed — retry."
Example 3: Full mini-review Input: A settings page has 5 buttons styled identically ("Save," "Cancel," "Reset," "Delete Account," "Export"), no page title, and a red "Delete Account" button with no confirmation step. Output:
- Severity: Critical — Problem: "Delete Account" has equal visual weight to "Save" and no confirmation. Impact: High risk of irreversible accidental action. Correction: Demote visually, require explicit confirmation step.
- Severity: Minor — Problem: No page title. Impact: User context unclear if navigated to directly. Correction: Add "Account Settings" header.
- Three highest-value changes: (1) confirm destructive action, (2) establish visual hierarchy among the 5 buttons, (3) add page title.
- Unchanged: overall single-column layout is fine as-is.
- Default to the smallest change that resolves the issue — a label or state fix before a layout change, a layout change before a full redesign.
- Treat visible state and unambiguous next action as non-negotiable; treat color/spacing/density choices as negotiable unless they actively obscure state or hierarchy.
- When proposing a new screen, include a concise plain-text wireframe only if it clarifies placement — don't wireframe trivial changes.
- Justify every removal or addition by which principle it serves (state, action, context, hierarchy, feedback).
- Don't flag subjective stylistic choices (font, color palette, spacing preference) as critical issues unless they obscure state, hierarchy, or action.
- Don't recommend a full redesign when a label, state message, or spacing fix solves the problem.
- Don't apply "cockpit" aesthetics literally — dark backgrounds, monospace fonts, or gauges are not required; the inspiration is behavioral discipline, not visual theme.
- Don't treat every icon, animation, or card as a violation — only those that are unexplained, decorative, or add no functional signal.
- Don't skip the "elements that should remain unchanged" step — over-recommending erodes trust and obscures the highest-priority fixes.