operational-expert-tool-ui

Name: operational-expert-tool-ui
Author: dembrandt

92installs5forks

How to install operational-expert-tool-ui?

dembrandt/dembrandt-skills/operational-expert-tool-ui

$npx -y skills add dembrandt/dembrandt-skills --skill operational-expert-tool-ui

Installs into the current project.

Summary

Operational expert tools — used by domain specialists for hours every day — require a different design approach than consumer or occasional-use software. Information density, workflow linearity, and at-a-glance status take priority over whitespace and discoverability. Use when de

Files · 1

View on GitHub

SKILL.md

1	# Operational Expert Tool UI
2
3	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.
4
5	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.
6
7	---
8
9	## Primary Design Principles
10
11	### 1. Information over whitespace
12
13	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.
14
15	- Use compact row heights (28–36px) for data tables
16	- Show secondary attributes (status, type, date) inline, not on hover or in a detail panel
17	- Prefer text labels over icons alone — experts read fast, icon-only UIs slow them down at the margins
18
19	### 2. Workflow linearity
20
21	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.
22
23	```
24	[Step 1: Select items] → [Step 2: Configure] → [Step 3: Execute]
25	```
26
27	The UI should make the next step obvious at every point, without hiding it behind menus or requiring navigation away from the current context.
28
29	### 3. Persistent state
30
31	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.
32
33	Do not reset the UI on every visit — the expert has spent time configuring it to their workflow.
34
35	---
36
37	## Hierarchical Accordion Tables
38
39	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.
40
41	```
42	▶ Order #1042 ACME Corp 3 lines Pending
43	▼ Order #1089 Globex 2 lines Ready
44	├─ Line 1 Widget A Qty: 12 ✓ In stock
45	└─ Line 2 Widget B Qty: 4 ✗ No stock
46	▶ Order #1091 Initech 5 lines Pending
47	```
48
49	Why accordion over page navigation:
50	- Context is preserved — the operator can see multiple orders simultaneously
51	- Status across siblings is visible without navigating back
52	- Keyboard navigation (expand/collapse with arrow keys) keeps hands on the keyboard
53
54	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.
55
56	---
57
58	## At-a-Glance Status Indicators
59
60	Operators make decisions based on status. Status should be visible without interaction.
61
62	\| Good \| Avoid \|
63	\|---\|---\|
64	\| Coloured dot or pill always visible in the row \| Status only visible on hover or in a tooltip \|
65	\| 2–3 status states with distinct colours \| More than 5 status colours (hard to memorise) \|
66	\| Status label beside colour for accessibility \| Colour alone as the only indicator \|
67	\| Consistent colour semantics across the whole tool \| Same colou

People who liked this also viewed

6 picks

Type

operational-expert-tool-ui

92installs5forks

View on GitHub

How to install operational-expert-tool-ui?

dembrandt/dembrandt-skills/operational-expert-tool-ui

$npx -y skills add dembrandt/dembrandt-skills --skill operational-expert-tool-ui

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Operational Expert Tool UI
2
3	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.
4
5	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.
6
7	---
8
9	## Primary Design Principles
10
11	### 1. Information over whitespace
12
13	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.
14
15	- Use compact row heights (28–36px) for data tables
16	- Show secondary attributes (status, type, date) inline, not on hover or in a detail panel
17	- Prefer text labels over icons alone — experts read fast, icon-only UIs slow them down at the margins
18
19	### 2. Workflow linearity
20
21	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.
22
23	```
24	[Step 1: Select items] → [Step 2: Configure] → [Step 3: Execute]
25	```
26
27	The UI should make the next step obvious at every point, without hiding it behind menus or requiring navigation away from the current context.
28
29	### 3. Persistent state
30
31	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.
32
33	Do not reset the UI on every visit — the expert has spent time configuring it to their workflow.
34
35	---
36
37	## Hierarchical Accordion Tables
38
39	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.
40
41	```
42	▶ Order #1042 ACME Corp 3 lines Pending
43	▼ Order #1089 Globex 2 lines Ready
44	├─ Line 1 Widget A Qty: 12 ✓ In stock
45	└─ Line 2 Widget B Qty: 4 ✗ No stock
46	▶ Order #1091 Initech 5 lines Pending
47	```
48
49	Why accordion over page navigation:
50	- Context is preserved — the operator can see multiple orders simultaneously
51	- Status across siblings is visible without navigating back
52	- Keyboard navigation (expand/collapse with arrow keys) keeps hands on the keyboard
53
54	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.
55
56	---
57
58	## At-a-Glance Status Indicators
59
60	Operators make decisions based on status. Status should be visible without interaction.
61
62	\| Good \| Avoid \|
63	\|---\|---\|
64	\| Coloured dot or pill always visible in the row \| Status only visible on hover or in a tooltip \|
65	\| 2–3 status states with distinct colours \| More than 5 status colours (hard to memorise) \|
66	\| Status label beside colour for accessibility \| Colour alone as the only indicator \|
67	\| Consistent colour semantics across the whole tool \| Same colou

People who liked this also viewed

6 picks

Type