/operational-expert-tool-ui

name: operational-expert-tool-ui
description: Dense, linear, status-at-a-glance UI for specialists who use a tool all day. Use when designing dispatch, warehouse, logistics, scheduling or other B2B operations tools.
metadata:
  priority: 7
  pathPatterns:
    - "components/**"
    - "src/components/**"
    - "**/*.tsx"
    - "**/*.jsx"
    - "app/**"
    - "pages/**"
  promptSignals:
    phrases:
      - "dispatch"
      - "warehouse"
      - "logistics"
      - "operations"
      - "operator"
      - "workflow tool"
      - "professional tool"
      - "expert user"
      - "power user"
      - "B2B tool"
      - "scheduling"
      - "planning tool"
retrieval:
  aliases:
    - operational UI
    - expert tool
    - dispatch UI
    - warehouse management
    - logistics UI
    - professional tool
    - B2B tool
    - scheduling UI
    - planning tool
    - power user interface
  intents:
    - design a tool for expert users
    - design a dispatch or logistics interface
    - design a workflow-driven tool
    - make a dense data UI for professionals
    - design an operational planning tool
  examples:
    - this is used by warehouse staff all day
    - design a dispatch tool for logistics operators
    - design a planning UI for professional schedulers
    - how should a tool for expert users be different from a consumer app
    - the users know the domain deeply but are not developers

Operational Expert Tool UI

An operational expert tool is software used by trained domain specialists — warehouse operators, dispatchers, planners, analysts — as their primary work surface, often for the entire working day. These users are not beginners discovering a product; they are professionals executing a defined job with the tool as their instrument.

This is a fundamentally different design context from consumer software or occasional-use SaaS. The design priorities are reversed: density and speed of action take precedence over discoverability and visual spaciousness.

---

Primary Design Principles

1. Information over whitespace

An expert user does not need breathing room to orient themselves — they know the tool. Every pixel of empty space is a missed opportunity to show data they need to act on.

• Use compact row heights (28–36px) for data tables
• Show secondary attributes (status, type, date) inline, not on hover or in a detail panel
• Prefer text labels over icons alone — experts read fast, icon-only UIs slow them down at the margins

2. Workflow linearity

Expert tools are used to complete a defined task sequence, not to browse. Design the layout to reflect the workflow order: left to right, or top to bottom, matching the mental model of the task.

[Step 1: Select items]  →  [Step 2: Configure]  →  [Step 3: Execute]

The UI should make the next step obvious at every point, without hiding it behind menus or requiring navigation away from the current context.

3. Persistent state

Filters, column widths, view modes, and open/closed panels are part of the operator's work context. They should survive page reloads and be consistent between sessions unless the user explicitly resets them.

Do not reset the UI on every visit — the expert has spent time configuring it to their workflow.

---

Hierarchical Accordion Tables

Many operational domains have naturally hierarchical data: an order contains lines; a route contains stops; a project contains tasks. The right pattern is an in-place accordion, not a drill-down to a separate page.

▶ Order #1042   ACME Corp    3 lines    Pending
▼ Order #1089   Globex       2 lines    Ready
    ├─ Line 1   Widget A    Qty: 12    ✓ In stock
    └─ Line 2   Widget B    Qty:  4    ✗ No stock
▶ Order #1091   Initech      5 lines    Pending

**Why accordion over page navigation:**

• Context is preserved — the operator can see multiple orders simultaneously
• Status across siblings is visible without navigating back
• Keyboard navigation (expand/collapse with arrow keys) keeps hands on the keyboard

**Per-row inclusion toggles:** In planning and staging workflows, each row may need to be explicitly included or excluded from a batch operation. Use a checkbox or toggle per row that is always visible — not hidden on hover.

---

At-a-Glance Status Indicators

Operators make decisions based on status. Status should be visible without interaction.

| Good | Avoid | |---|---| | Coloured dot or pill always visible in the row | Status only visible on hover or in a tooltip | | 2–3 status states with distinct colours | More than 5 status colours (hard to memorise) | | Status label beside colour for accessibility | Colour alone as the only indicator | | Consistent colour semantics across the whole tool | Same colour meaning different things in different tables |

Status colour conventions should align with `status-colors-and-errors` — green for ready/complete, amber for warning/pending, red for error/blocked, grey for inactive.

---

A Shared Header Carries Only What Every Band Shares

To compare parallel resources on one axis (people, vehicles, rooms over time, or any shared scale), stack one band per resource under a single shared header. A reading that differs per resource, such as utilisation per period, goes in a row inside that resource's band. The shared header carries only what is true for every band; a value placed there is read as applying to everything below it and is wrong for all bands but one.

---

Workflow-State Filters vs. Search Filters

Expert tools often have two distinct types of filters that should be treated differently in the UI:

**Workflow-state filters** narrow the dataset to the operator's current work scope. They persist, they are broad, and they represent a decision ("I am working on today's orders that are not yet assigned"). Place these in a permanent filter bar or sidebar, always visible.

**Search filters** find a specific item within the current scope. They are transient. Place these in a s