operational-expert-tool-ui
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseOperational Expert Tool UI
专业操作工具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.
专业操作工具是供受训领域专家——仓库操作员、调度员、规划师、分析师——作为主要工作界面使用的软件,他们通常会全天使用这类工具。这些用户并非初次接触产品的新手,而是将工具作为工作器械,执行既定任务的专业人员。
这与消费级软件或偶尔使用的SaaS产品的设计场景有着本质区别。设计优先级完全反转:信息密度与操作速度优先于功能可发现性与视觉空间感。
Primary Design Principles
核心设计原则
1. Information over whitespace
1. 信息优先,留白次之
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
专家用户无需留白空间来定位自身操作——他们对工具了如指掌。每一处空白像素都是展示所需操作数据的错失良机。
- 数据表采用紧凑行高(28–36px)
- 次要属性(状态、类型、日期)直接显示在行内,而非悬浮提示或详情面板中
- 优先使用文本标签而非仅用图标——专家阅读速度快,纯图标UI会在细微处拖慢他们的操作
2. Workflow linearity
2. 工作流线性化
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.
专家工具用于完成既定的任务序列,而非浏览内容。布局设计需反映工作流顺序:从左到右或从上到下,匹配任务的心智模型。
[步骤1:选择项目] → [步骤2:配置] → [步骤3:执行]UI应在任何阶段都明确显示下一步操作,无需隐藏在菜单后或要求用户离开当前上下文进行导航。
3. Persistent state
3. 持久化状态
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.
筛选条件、列宽、视图模式以及面板的开闭状态属于操作人员的工作上下文。这些设置应在页面刷新后保留,且在不同会话间保持一致,除非用户明确重置。
不要在每次访问时重置UI——专家已花费时间将其配置为符合自身工作流的状态。
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 PendingWhy 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.
许多操作领域的数据具有天然层级结构:订单包含订单行;路线包含停靠点;项目包含任务。合适的设计模式是原地折叠面板,而非跳转到单独页面进行钻取查看。
▶ 订单#1042 ACME Corp 3行 待处理
▼ 订单#1089 Globex 2行 已就绪
├─ 行1 Widget A 数量: 12 ✓ 有库存
└─ 行2 Widget B 数量: 4 ✗ 无库存
▶ 订单#1091 Initech 5行 待处理为何选择折叠面板而非页面导航:
- 保留上下文——操作人员可同时查看多个订单
- 无需返回即可查看同级项目的状态
- 键盘导航(用箭头键展开/折叠)可让用户双手保持在键盘上
每行包含切换按钮: 在规划和筹备工作流中,每行可能需要明确包含或排除在批量操作之外。使用始终可见的每行复选框或切换按钮——而非悬浮显示。
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 — green for ready/complete, amber for warning/pending, red for error/blocked, grey for inactive.
status-colors-and-errors操作人员根据状态做出决策。状态应无需交互即可查看。
| 推荐做法 | 避免做法 |
|---|---|
| 行内始终可见彩色圆点或胶囊状状态标识 | 仅在悬浮或提示框中显示状态 |
| 2–3种具有鲜明色彩区分的状态 | 超过5种状态颜色(难以记忆) |
| 颜色旁搭配状态标签以提升可访问性 | 仅用颜色作为唯一状态标识 |
| 整个工具内颜色语义保持一致 | 同一颜色在不同表格中表示不同含义 |
状态颜色规范应与保持一致——绿色表示就绪/完成,黄色表示警告/待处理,红色表示错误/阻塞,灰色表示未激活。
status-colors-and-errorsWorkflow-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 search input that can be cleared quickly.
Do not merge these into a single filter UI — the operator switches mental mode between "what scope am I working in?" and "where is that specific item?"
[Workflow scope: Today ▾] [Status: Unassigned ▾] [Stock: Available ▾]
↑ Persistent workflow-state filters
Search within scope: [___________]
↑ Transient search专家工具通常有两种不同类型的筛选器,在UI中需区别对待:
工作流状态筛选器用于将数据集缩小到操作人员当前的工作范围。这类筛选器持久存在,范围较广,代表着一项决策(例如“我正在处理今日未分配的订单”)。应将其放置在永久筛选栏或侧边栏中,始终可见。
搜索筛选器用于在当前范围内查找特定项目。这类筛选器是临时的。应放置在可快速清除的搜索输入框中。
不要将这两类筛选器合并到同一个UI中——操作人员在“我正在哪个工作范围内?”和“那个特定项目在哪里?”两种心智模式间切换。
[工作流范围:今日 ▾] [状态:未分配 ▾] [库存:可用 ▾]
↑ 持久化工作流状态筛选器
在范围内搜索:[___________]
↑ 临时搜索框Keyboard Navigation
键盘导航
Expert users learn keyboard shortcuts. They should not be required, but they dramatically increase throughput for trained users.
- Arrow keys navigate rows in a table
- Space or Enter expands an accordion row
- Escape closes an open panel or dialog
- Common actions have discoverable shortcuts (shown in tooltips: ,
Delete [Del])Include [Space]
Do not rely on right-click context menus as the only path to actions — they are not discoverable and break keyboard-only workflows.
专家用户会学习键盘快捷键。快捷键并非强制要求,但能显著提升受训用户的操作效率。
- 箭头键用于导航数据表中的行
- 空格键或回车键用于展开折叠面板行
- Esc键用于关闭打开的面板或对话框
- 常见操作配有可发现的快捷键(在提示框中显示:,
Delete [Del])Include [Space]
不要将右键上下文菜单作为操作的唯一路径——这类菜单不可发现,且会打断纯键盘操作的工作流。
Action Feedback at Scale
大规模操作反馈
When an operation affects many items (batch assign, mass status update), the feedback must be proportional:
- For fewer than ~10 items: inline confirmation is sufficient
- For 10–100 items: a toast notification with count ("42 orders updated")
- For 100+ items: a progress indicator during the operation, then a summary on completion
Never silently complete a bulk operation with no feedback — the expert needs to confirm their action took effect.
当一项操作影响多个项目(批量分配、批量状态更新)时,反馈需与操作规模匹配:
- 影响少于约10个项目:行内确认即可
- 影响10–100个项目:带有数量的提示通知(“已更新42个订单”)
- 影响100个以上项目:操作期间显示进度指示器,完成后显示汇总信息
绝不要在无反馈的情况下静默完成批量操作——专家需要确认他们的操作已生效。
Review Checklist
审查清单
- Is the information density appropriate for trained daily users (compact rows, inline status)?
- Does the layout reflect the workflow sequence (left-to-right or top-to-bottom task flow)?
- Are filters, view modes, and open panels persisted across sessions?
- Is hierarchical data shown as in-place accordions, not separate pages?
- Are per-row inclusion controls always visible, not hidden on hover?
- Are status indicators always visible without interaction?
- Are workflow-state filters separated from transient search filters?
- Are common actions accessible via keyboard?
- Does bulk operation feedback scale with the number of affected items?
- 信息密度是否适合每日使用的受训用户(紧凑行高、行内状态)?
- 布局是否反映工作流顺序(从左到右或从上到下的任务流)?
- 筛选条件、视图模式和打开的面板是否在会话间持久保留?
- 层级数据是否以原地折叠面板显示,而非单独页面?
- 每行包含控制按钮是否始终可见,而非悬浮显示?
- 状态指示器是否无需交互即可始终可见?
- 工作流状态筛选器是否与临时搜索筛选器分离?
- 常见操作是否可通过键盘访问?
- 批量操作反馈是否随受影响项目数量调整?