# User Experience Evaluation Playbook

修订于2026-10-18

## 一、测试视角与好体验的判断标准

### 1. 三者分别在回答什么问题

| 对比项 | SIT：系统集成测试 | 用户体验评测 | UAT：用户验收测试 |
|---|---|---|---|
| 核心问题 | 系统之间是否按约定正确协同？ | 用户能否理解、顺畅操作，并对过程和结果有把握？ | 系统能否支撑真实业务，并满足接收使用的条件？ |
| 主要观察对象 | 系统交互、接口契约、数据传递、跨系统流程及异常处理 | 人与产品交互时的认知、行为、感受，以及任务完成质量 | 业务场景、角色职责、业务规则、端到端结果及验收条件 |
| 主要判断参照 | 需求和技术规格、接口契约、系统依赖与预期结果 | 用户目标与情境、认知规律、交互原则、设计规范及用户证据 | 真实业务需要、业务流程、领域规则、合同或约定的验收标准 |
| 典型关注 | 数据是否传对、状态是否同步、失败是否按约定处理 | 是否困惑、犹豫、误解、焦虑或失去控制；是否存在额外认知和操作负担 | 关键业务能否开展、角色能否履责、业务结果是否满足实际需要 |
| 核心知识侧重 | 软件测试与软件工程、系统架构、接口协议、数据与状态机制，以及相关业务知识 | 认知心理学、人机交互、信息架构、交互与视觉设计、无障碍和用户研究，以及相关业务知识 | 业务领域知识、实际作业方式、组织与权限规则、验收和风险判断，以及测试知识 |

这里比较的是关注重心，并非互斥的职责边界。SIT、UAT属于测试层级/验收活动视角；体验评测属于可以贯穿不同阶段的质量评价视角。体验问题可以在SIT或UAT中被发现，UAT也可以包含体验验收条件。

依据：[ISTQB集成测试定义](https://glossary.istqb.org/en_US/term/integration-testing?exact_matches_first=true&term=defect)、[验收测试定义](https://glossary.istqb.org/en_US/term/acceptance-testing/1)、[可用性测试定义](https://glossary.istqb.org/en_US/term/usability-testing?exact_matches_first=true)。

### 2. 同一个审批场景，三个视角关注什么

场景：用户在机器人中完成审批，返回之前打开的H5详情，页面仍显示可审批。

- **SIT视角**：机器人、审批服务和H5之间，状态传递、读取与刷新是否符合约定？旧请求或重复请求是否得到正确处理？
- **体验视角**：用户会不会怀疑“刚才到底批没批成功”？页面为何仍邀请他再次审批？即使重复请求被后端拦截，界面是否依然造成不确定和失控感？
- **UAT视角**：这张单据是否按实际审批规则正确流转？后续角色是否能继续工作？业务是否认可当前结果及处理方式？

三个视角可以指向同一个问题，但解释它的依据和关注的后果不同。后端防重正确，并不自动代表前端体验合理；体验流畅，也不能替代业务验收。

### 3. 什么是好的体验：四个判断方向

| 判断方向 | 核心问题 | 在测试阶段更应关注什么 | 案例与规范 |
|---|---|---|---|
| 实用性：是否解决实际问题 | 功能即使可以操作，是否真正帮助用户达成目标？ | 功能是否提供了任务需要的内容和结果；用户是否仍需依靠额外工具、线下询问或重复劳动才能完成目标 | “更多申请”未提供预期新内容（#78），需要追查该入口是否提供实际任务价值，而不只检查能否打开 |
| 可用性：是否容易理解和完成 | 用户能否找到入口、理解信息，并顺畅完成任务？ | 对象、主次、操作后果和完成状态是否清楚，是否存在额外记忆、比较和修正负担 | 两个个人中心（#32）、打印被过度强调（#82）、审批后旧页面仍可操作（#12/#13），分别影响理解、选择和确认 |
| 公平性：不同用户是否得到适当支持 | 不同能力、背景和使用条件的用户，是否都有合理路径完成任务？ | 首次使用与熟练使用、键盘与触控、不同语言和设备下，是否有人被相同界面挡在任务之外；需要的支持是否可获得 | 小触控区域（#74）及无障碍、响应式、全球化规范，提醒评测者不能用自己的操作条件代表所有目标用户 |
| 愉悦性：过程带来怎样的感受 | 用户在使用过程中能否形成积极感受与信任？ | 是否感到清楚、安心、受尊重、有掌控感；积极表达是否与业务情境相称，而非增加打扰 | 及时且一致的审批状态有助于用户安心确认结果；清楚的取消与恢复路径有助于建立掌控感 |

**公平性不等于给所有人完全相同的界面。** 不同用户可能需要不同支持；合理的角色权限差异并不自动构成体验缺陷，仍需区分业务限制与能力、语言、终端造成的使用障碍。

**企业系统中的积极体验需要符合任务情境。** 安心、顺畅、信任与掌控感可以成为体验目标；有趣的动画、个性化装饰或持续吸引注意力，不是所有业务系统的必备条件。缺少惊喜不能直接判为缺陷，必要的风险提醒也不应为了“让人开心”而被弱化。

### 4. 体验工程师在观察什么：信息如何表达，操作如何展开

用户既要理解眼前的信息，也要在连续操作中不断判断下一步。界面的颜色、字号和位置会影响用户看见什么、如何理解；入口、反馈、时机和恢复路径会影响任务能否继续。可以从两个相互关联的观察面追查原因。

| 观察面 | 需要判断什么 | 对应差旅案例 |
|---|---|---|
| 信息表达 | 用户先注意到什么，怎样理解分组、名称、颜色、控件状态与操作重点；视觉强调是否服务于当前任务 | 两个个人中心（#32）、打印过度强调（#82）、单据卡片重点信息难区分（#83） |
| 连续交互 | 从入口到完成是否连贯；操作后是否知道发生了什么；遇到困难、犯错或改变主意时，是否有合理路径继续 | 审批完成后旧页仍可操作（#12/#13）、酒店超标提示过晚（#20）、变更后无法取消（#85） |

信息表达需要回到用户此刻**要看到什么、理解什么、做什么**。颜色、排版、间距、形状、图层和动效都是影响理解与行为的手段，不能只凭某个变量的外观好恶判断设计。比如打印按钮的颜色和尺寸看似是视觉细节，但它会分配用户注意力，影响审批任务的行动优先级。

连续交互需要关注四种支持：

- **路径可达**：用户知道从哪里开始、下一步如何推进，以及怎样确认任务完成；流程不在关键节点断路。
- **结果可感知**：操作后的变化、等待、成功、失败或结果未知，能被用户识别，并帮助判断接下来可做什么。
- **错误可恢复**：用户能够在业务允许的范围内修正、退出或继续；不可恢复时，决策前能理解后果，之后知道可行的处理路径。
- **遇阻有支撑**：术语、条件、限制和错误原因在需要的时刻得到解释，帮助出现在相关位置，而不是让用户带着疑问到别处寻找。

这两个观察面不是对视觉设计和交互设计的绝对划界。一次状态变化可能同时涉及文字、颜色、动效与业务结果；一个问题也可能同时影响信息理解和连续操作。

### 5. 从感受信号到专业判断

体验工程师会特别留意操作过程中细微的心理变化：

> “我该点哪个？”“这个词什么意思？”“怎么和我想的不一样？”“到底成功没有？”“为什么又让我填一次？”“我能不能反悔？”

这些疑问可能表现为困惑、犹豫、惊讶、不耐烦、焦虑和失控感，也可能仅表现为停顿、反复确认、绕路或重复操作。

体验工程师的判断路径：

**感知情绪或操作阻力 → 定位触发点 → 解释被打破的预期或增加的负担 → 对照交互原则和设计规范 → 判断影响与适用边界。**

| 用户可能出现的感受 | 需要追查的设计原因 | 相关专业知识 | 差旅案例 |
|---|---|---|---|
| 困惑：“这两个有什么区别？” | 分类、命名是否符合用户对业务的理解 | 心智模型、信息架构、概念一致性 | 两个个人中心；需求单与订单 |
| 犹豫：“我应该点哪个？” | 主次、操作范围、可用条件是否明确 | 视觉注意、信息层级、选择与决策负担 | 打印/退出登录被过度强调 |
| 意外：“怎么不是我要的？” | 控件和文案暗示的行为是否被兑现 | 意符、映射、可预测性 | 电话图标打开服务商列表 |
| 不耐烦：“还要重复多少次？” | 是否增加了不必要的记忆、输入和往返 | 工作记忆、认知负荷、识别优于回忆 | 更多申请没有新内容；入口绕行 |
| 焦虑：“成功了吗，还要再点吗？” | 过程和结果是否可感知，页面状态是否一致 | 状态可见性、反馈、不确定性与信任 | 审批完成后旧页面仍可操作 |
| 失控：“我想取消，但退不回去。” | 是否缺少退出、撤销或恢复机制 | 用户控制与自由、错误恢复 | 变更后没有取消入口 |

以上感受是根据问题现象推导的可能反应，不能代替真实用户的情绪证据。实际用户、专家走查者和产品熟练使用者的反应也可能不同。

认知与交互原则参考：[Nielsen可用性启发式](https://www.nngroup.com/articles/ten-usability-heuristics/)，其中包括系统状态可见、符合现实认知、用户控制与自由、一致性、识别优于回忆等。

情绪和操作阻力提供线索，心理学与交互知识帮助解释原因，设计规范和用户证据帮助判断问题是否成立。

情绪与体验问题并非一一对应：

- 有些问题尚未引起明显情绪，用户已在无意识中付出额外记忆、阅读或比较成本。
- 有些障碍可以由规范或专家检查直接识别，例如键盘无法到达关键操作；评测者自己未受阻，不代表目标用户不受影响。
- 不愉快不一定说明设计错误。合理的权限限制、必要的风险确认或业务制度也可能引起不满，需要继续判断是否必要、是否解释清楚、是否提供合理路径。

因此，体验工程师关注情绪，但不止于“我觉得不舒服”。专业判断必须继续回答：**谁在什么任务中产生了什么阻力，是怎样的设计造成的，是否存在合理原因，影响有多大？**

## 二、常见体验信号及其可能的设计原因

体验信号说明用户可能在哪个节点遇到阻力。判断原因时，需要同时关注用户原本期待的理解、行动支持和感受。

交互原则和适用的公司设计规范为判断提供依据。以下结合[Nielsen可用性启发式](https://www.nngroup.com/articles/ten-usability-heuristics/)，说明体验信号与潜在设计原因的联系：

| 体验信号示例 | 可用于追查原因的交互原则 |
|---|---|
| 困惑 | 系统与现实世界匹配；一致性与标准 |
| 犹豫 | 信息突出重点；操作与选项可见、便于识别 |
| 意外 | 一致性与标准；控件与预期结果的映射 |
| 不耐烦 | 识别优于回忆；使用的灵活性与效率 |
| 焦虑 | 系统状态可见；及时、清楚的反馈 |
| 失控 | 用户控制与自由；错误识别与恢复 |

同一种感受可能来自不同原因，同一个设计问题也可能引发多种感受。上述原则支持设计分析，不能证明某个用户必然产生对应情绪；情绪名称也不能单独支持缺陷结论。

### 1. 困惑：用户无法理解对象与当前位置

**设计原因与专业依据**：心智模型是用户对“系统里有什么、彼此是什么关系、操作会怎样”的理解。分类和命名如果沿用系统内部结构，用户就需要自行猜测和补全关系。

**期望获得的体验**：清楚地知道对象是什么、自己在哪里、入口有何区别，不必先学会系统内部的分类与分工。

**关注对象**：用户能否形成稳定理解——对象是什么、入口有什么区别、当前在哪里、接下来会发生什么。

**差旅案例**：两套个人中心（#32）；机票需求单与订单难区分（#33）；“查看全部”进入“发起申请”（#47）；“查看全部”和“更多申请”目的不清（#69/#78）。

**判断依据**：

- 产品内部的系统划分、数据表结构、组织分工，不应成为用户必须先学会的知识。
- 同名入口应具有可解释的一致含义；不同对象应通过命名、信息或位置表达差别。
- 页面标题、所在导航和实际内容应共同说明当前位置。
- 状态、对象类型和任务动作是不同分类维度，不宜混杂在同一层级而缺少解释。

**边界**：多个入口、多个系统或新业务术语都可以存在；问题在于是否迫使用户猜测区别、是否在不同入口产生矛盾理解。不能只因“有两个入口”判定重复，也不能未经业务确认将需求单与订单合并。

### 2. 犹豫：用户无法判断重点与下一步

**设计原因与专业依据**：视觉层级通过大小、颜色、位置和分组分配注意力。用户反复寻找或迟迟不能选择时，需要区分：是业务决策本身复杂，还是界面没有表达行动优先级。

**期望获得的体验**：迅速识别当前任务的重点，在足够信息支持下作出选择；业务本身需要权衡时，界面帮助比较，而不替用户隐去必要选项。

**关注对象**：页面让用户首先注意到的内容，是否恰好是当前需要了解和处理的内容。

**差旅案例**：首页Banner压过功能区（#66）；退出登录使用主按钮（#76）；打印被过度强调（#82）；单据卡片无法快速区分重点信息（#83）。

**判断依据**：

- 大小、颜色、位置、留白和对比度都会分配注意力，并非纯装饰。
- 先判断当前页面服务的任务，再判断哪个操作应被强调。
- 信息分组应体现业务关联；距离更近、样式相同，会暗示信息属于一组。
- 列表首先应帮助识别和比较对象，详情首先应支持理解和决策。

**边界**：不是页面越简洁越好，也不是每页都必须有一个主按钮。高频业务可能需要高信息密度；品牌展示、运营和业务处理页面的视觉重点可以不同。规范中的推荐间距不是一律判错的像素门槛。

### 3. 意外：实际结果违背操作前的预期

**设计原因与专业依据**：文字、图标和控件形态都是行为线索。用户会据此预测点击结果；这些线索与实际行为不一致，就会增加试错，并削弱对后续操作的信任。

**期望获得的体验**：操作前能合理预测结果，操作后实际行为与线索相符，逐步建立对界面的信任。

**关注对象**：用户在操作前形成的预期，能否被实际结果兑现。

**差旅案例**：电话图标打开服务商列表（#41）；查询按钮叫“因公出行”（#44）；“立即预定”返回首页（#50）；只读内容使用禁用样式（#15/#27）。

**判断依据**：

- 控件形态本身具有含义：按钮暗示动作，链接暗示到达，开关暗示即时状态切换，单选框暗示存在选择。
- 标签、图标、位置和交互状态共同构成用户对操作的预期。
- 只读、禁用、不可见对应不同含义，不能因为都“不能修改”而混用。
- 操作应有清楚的作用对象：整页、选中记录、单行、当前表单，或跳转到另一个任务。

**边界**：图标可以辅以文字消除歧义，按钮也不必全部采用实心矩形。判定依据是用户能否识别并预测动作，而不是是否使用某个固定外观。

### 4. 不耐烦：任务增加了不必要的认知与操作负担

**设计原因与专业依据**：认知负担包括记住前页信息、来回比较、辨认重复内容和重新理解规则。操作次数只是其中一部分；一次点击也可能要求用户付出很高的理解成本。

**期望获得的体验**：信息和支持在作决定时及时可用，用户可以专注任务，不必反复记忆、查找或重新开始。

**关注对象**：用户作决定所需的信息，是否在当时就能获得，并且不需要付出不必要的查找、记忆和比较成本。

**差旅案例**：酒店超标提示到详情/预订页才出现（#20）；未关联申请单便预填地点与日期（#17/#34）；审批关键字段显示不全（#82）；重复提示浮层干扰阅读（#27）；“更多申请”没有提供预期的新内容（#78）。

**判断依据**：

- 影响选择的价格、限制、风险，应在相关决策点之前可见。
- 默认值是系统给用户的建议，必须与当前对象、角色和上下文匹配。
- 重要程度和出现时机一起决定是否应该展开；“页面上能找到”不等于“及时可用”。
- 渐进呈现应降低负担，不能隐藏当前决策必需的信息。
- 判断重复输入、页面往返和中断是否必要；减少步骤不能以增加单步理解难度为代价。

**边界**：并非所有信息都要首屏展示。低频说明可以折叠或按需查看；但金额、关键限制等不能靠用户偶然展开才得知。可比较价格必须先统一日期、房型、税费等口径。

### 5. 焦虑：用户无法确认进度与结果

**设计原因与专业依据**：状态可见性帮助用户判断“系统是否收到、是否正在处理、是否已经完成”。反馈缺失或跨入口矛盾，会让用户用刷新、重复提交或向他人确认来消除不确定。

**期望获得的体验**：明确知道系统收到什么、正在处理什么、结果是否确定，以及自己接下来可以做什么，从而安心推进任务。

**差旅案例**：机器人已审批、H5仍可操作（#12/#13）；延迟响应引发重复点击（#63）。

**判断依据**：

- 执行中、已成功、已失败、结果未知是不同状态，应给出不同说明与操作机会。
- 有提示不等于有效反馈：提示是否能被看到、是否与页面状态一致、消失后是否仍有依据。
- 同一任务在机器人、H5和其他入口中的状态，应能支持一致理解。
- 等待中应让用户知道当前可做什么；结果未知时，不应暗示操作已经失败或可以放心重复提交。

**边界**：有Loading不代表等待体验已经合理；后端拒绝重复提交，也不能消除前端状态矛盾。界面变化已足以表达结果时，不必再弹一次成功提示。

### 6. 失控：用户无法停止、退出或恢复

**设计原因与专业依据**：掌控感来自对操作后果的了解，以及在必要时修正决定的能力。不可逆操作并非必然不合理，但必须在决策前说明后果，并提供与风险相称的保护。

**期望获得的体验**：理解操作后果，在允许的范围内改变决定、退出或恢复；遇到不可逆约束时，也能提前知情并找到后续处理路径。

**差旅案例**：变更后无法取消、保存后回不到原状态（#85）。

**判断依据**：

- 取消、关闭、返回、撤回、撤销具有不同的作用范围和后果，文案与结果需要一致。
- 用户已经输入的内容、作出的选择和当前上下文，应得到合理保留。
- 发生错误后，用户应能找到原因及可执行的恢复路径，而非只能重新开始。
- 高成本操作需要与后果相称的保护；确认前应能理解影响对象和不可恢复的后果。

**边界**：不能把所有操作都变成确认弹窗，也不能要求所有业务状态都可撤销。已发生实际业务后果时，应明确撤回条件、替代处理路径或无法撤销的原因。

### 共同边界：目标用户、已有经验与使用环境

上述判断都需要明确“对谁、在什么环境下成立”。熟练评测者知道操作路径，不代表首次使用者也能理解；评测者可以使用鼠标，不代表键盘用户也能完成。

- **已有经验**：同一概念、相似任务应有稳定规则。差旅中同类费用选择器交互不同（#25）、审批记录跨端排序相反（#84），都可能增加重新学习和查找成本。
- **宿主与终端**：飞书宿主与页面重复提供导航（#72），可能让用户难以判断返回的范围。跨端应延续业务语义和操作结果，同时适配控件与布局。
- **操作能力与环境**：常见问题触控区域偏小（#74），需要结合有效点击范围、相邻操作和设备判断。无障碍问题不能以评测者本人操作顺畅为依据排除。

一致性不等于PC和手机像素相同；响应式、无障碍和全球化也不只是缩放、放大字号或翻译文字。

## 三、设计规范如何回应这些体验问题

【规范明确】表示可回查的公司规范要求或建议；【案例判断】表示结合场景的专业分析。两者并列时，规范内容与推导结论应分别理解。下列分组依据用户受到的影响，同一条规则可能同时支持多个方向的判断。

回查规范时，同时关注两件事：**信息如何取舍，规则如何贯穿整个任务。** 某个组件符合规范，不代表页面重点符合用户目标；单页清楚，也不代表跨入口、跨页面的同类操作始终一致。信息理解、行为路径和系统一致性需要结合完整任务一起判断。参考：[《UI做不好的卡点在哪里？》](https://app.notion.com/p/e07eb206684883168c30019a92cca096)。

### 1. 理解对象与含义：减少困惑

分组、颜色和业务用语都在表达对象之间的关系。看似视觉或文案细节，可能改变用户对业务的理解。同一对象、状态或动作在不同页面中应能被稳定识别，不能只检查当前页是否自洽。

**1. 间距在表达归属关系。**【规范明确＋判断解释】
PC布局给出行内8、区块间16、区块内20等参考值，且明确不作强制要求。重点是同一组更紧、不同组可区分；不能脱离主题和布局只凭差2px提缺陷。移动端16px全局边距指内容距屏幕边缘，不等于每层卡片都再加16px。

**2. 状态色表达含义，不能按喜好分配。**【规范明确＋案例判断】
草稿本身不等于警告，除非伴随真正需要警示的条件。还要区分业务语义：集团可视化指南中“表现好用红、表现差用蓝”，并非简单红涨蓝跌；这也不能套到错误提示或审批状态上。颜色的作用域比色值本身更重要。

**3. “通过/不通过”和“同意/不同意”不是任意同义词。**【规范明确】
审批规范将前者用于普通审批决策，后者用于会签中的个人意见；会签是否通过由规则汇总决定。“驳回”是退回前序节点，不等于以拒绝结束流程。文字看似相近，实际改变用户对后果的理解。

### 2. 识别重点与选择动作：减少犹豫

强调方式和操作位置决定用户注意什么、先做什么。重点是行动优先级与当前任务一致。信息应区分当前必需、次要补充与无关干扰；减少干扰要以用户任务为依据，不把“元素少”当作目标。

**4. 主按钮表达的是行动优先级，不是视觉装饰。**【规范明确】
一个按钮区不超过一个主按钮；主次无法判断时，使用次按钮更安全。因此“退出登录/打印做成主按钮”的问题，是引导方向与页面任务不匹配。约束单位是按钮区，不能机械理解为任何复杂页面全页只能出现一个主按钮。

**5. 主按钮并非永远在左或永远在右。**【规范明确】
PC左对齐按钮组按重要性从左至右，右对齐组从右至左；列表页页面级操作通常在左，表单页操作通常在右。先确认页面类型、按钮组对齐与作用范围，再评价顺序。返回/上一步还具有方向性含义。

**6. 危险程度和主次级别是两个维度。**【规范明确】
危险按钮可以是主、次或文字按钮。用户明确要删除时，可用危险主按钮；不推荐删除时，可以突出取消、弱化删除。不能只因为“危险”就一律做得最醒目。

**7. 必填标记并不是越多越清楚。**【规范明确】
必填项多于非必填项时，规范建议隐藏重复的星号，转而标注非必填项。目的是让真正需要识别的差异突出。使用该方案时，仍需让用户明确默认规则。

**8. 查看审批数据与提交审批操作应有清楚分区。**【规范明确】
PC审批页至少提供“流程处理、流程图”并以Tab切换，默认流程处理；审批操作包括操作选择、处理意见、提交。移动端的操作主要在底部，相关配置在弹层中展开。符合相同业务规范不意味着两端使用相同布局。

### 3. 预测操作结果：减少意外

控件会向用户暗示能否操作、何时生效，以及如何解除限制。实现了功能还需要兑现这些暗示。

**9. 开关意味着立即生效。**【规范明确】
《数据录入》要求切换开关直接触发状态改变；需要额外确认提交的选择，建议使用单选框。判断的不只是能否保存，而是控件是否让用户误以为已经生效。

**10. 只读和禁用具有不同语义。**【案例判断】
只读是“这就是可供阅读的信息”，禁用是“这个操作当前不能用”。将审批信息统一灰化会削弱阅读与决策；将不可选择的审批顺序做成单选框，会制造可选择的错觉。这里应依据具体组件的阅读效果和行为判断，而非仅凭属性名。

**11. “没有选中数据”和“没有操作权限”不是同一种不可用。**【案例判断】
前者通常可以通过选择对象解除，后者涉及权限或角色。批量操作应说明作用对象和可用条件；无法操作的原因如果无法被理解，用户只能猜。是否隐藏还是禁用，需要兼顾可发现性、权限信息和页面负担，不宜给出单一答案。

### 4. 阅读、比较与修正：减少额外负担

信息即使全部存在，也可能要求用户反复查找、记忆或修正。规范细节用于降低完成任务所需的额外成本。用户遇到术语、条件或校验问题时，帮助应说明当下需要知道的内容，并出现在相关位置；有帮助入口，不等于任务已得到足够支持。

**12. 表单标签位置会影响阅读效率和多语言适应性。**【规范明确】
顶部标签是《PC表单》的推荐方式，尤其适用于多语言；左右布局可用于内容多、关系简单的场景。多列表单遵循行优先阅读。不能只因节省垂直空间就把全部标签放左侧，也不能将所有左右布局判错。

**13. 内容截断要由信息价值决定。**【规范明确】
金额、数量等重要信息避免截断；一般描述可省略并提供全文查看途径；多条数据优先省略重复内容。同样的省略号，对普通说明和审批金额的影响并不一样。移动端必须有可触达的查看方式。

**14. “看全”与“看懂、可比较”不是同一件事。**【规范明确＋案例判断】
规范要求表格数值便于纵向对比，通常右对齐、单位放表头；字体规范推荐数字使用等宽数字。进一步判断列表时，应关注对象识别字段和差异字段是否突出，而非只检查是否包含所有字段。

**15. 提交校验应帮助整体修正，而非逐个“挤牙膏”。**【规范明确】
《移动表单页》要求提交失败时一次性展示全部错误反馈，定位第一个错误字段，并在字段处说明原因。只有顶部一条“信息不完整”，即便校验逻辑正确，用户仍不知道如何完成。

**16. 传阅、抄送、传阅必回复会产生不同的通知与待办行为。**【规范明确】
待办通知规范中：普通传阅主要发送消息；抄送不另发消息，进入“抄送我”；传阅必回复产生对应待办。不能看到“通知相关人”就统一实现，更要避免审批邮件和信件通知Bot重复触达。

### 5. 确认结果：减少不确定

反馈的作用是让结果明确。提示数量不是反馈质量的衡量标准。

**17. 有些操作不需要额外成功提示。**【规范明确】
若界面变化已经充分表达结果，可省略冗余反馈；Message/Toast应适度使用。是否提示，取决于结果是否清楚，而不是每次动作都套“操作成功”。

### 6. 继续、退出与恢复：保留掌控感

防止错误需要与帮助用户继续任务同时考虑。按钮置灰、提示消失或退出方式不明，都可能让用户无从推进。恢复路径应形成完整闭环：用户知道出了什么问题、如何处理、哪些输入得到保留，以及处理后能否继续原任务。

**18. 复杂表单的提交按钮一直置灰，可能更难用。**【规范明确】
《移动表单页》区分两种情况：字段少、可用条件明确时，可在必填完成前置灰；复杂表单、用户不知道哪里未完成时，应保持可点击并反馈错误原因。防止错误提交和让用户知道如何完成，需要同时满足。

**19. 短暂轻提示不能承担所有错误反馈。**【规范明确】
Toast规范不建议在错误场景中使用轻提示作为主要反馈；移动表单规范同时允许通用错误Toast，但要求字段红字和错误定位。两者可以同时成立：Toast提醒“有错误”，持久的字段反馈帮助“修复错误”。仅有一闪而过的提示通常不足以支持恢复。

**20. 二次确认与一般内容弹窗有不同要求。**【规范明确】
PC对话框正文可滚动，但二次确认不允许内部滚动；决策信息不能藏在未滚到的位置。除二次确认外，不在对话框上继续叠对话框。操作文案应表达明确动作，避免含义不清的“确定”。

**21. 遮罩能否关闭，取决于组件和场景。**【规范明确】
PC模态抽屉规定通过关闭/取消退出，不允许点遮罩关闭；移动高级筛选则允许点击遮罩关闭。不能把“有遮罩”当成统一判定条件，更不能用某个开源库默认行为替代公司规范。

### 7. 使用环境与能力差异：避免遗漏受阻人群

同一界面在不同设备、语言和操作方式下，可能产生不同障碍。个人感受需要结合目标用户的条件判断。公平性要求关注目标用户是否得到适当支持，不是让不同能力、角色和终端一律使用相同呈现。

**22. 无障碍不只关注字号和颜色。**【规范明确】
焦点应可见、顺序可预测；弹层关闭后焦点应返回触发位置；颜色不能成为唯一状态信息。图标尺寸与有效触控区域要区分。不能看到图标小于44px就直接判定触控区域不够，也不能因图标够大就忽略相邻操作误触。

**23. 响应式适配允许更换交互载体。**【规范明确】
桌面对话框可映射为小屏全屏面板，下拉操作可映射为动作面板。重点是核心任务和内容完整性，不能只把PC页面等比例缩小。断点必须结合所用方案、容器和区域最小可用宽度判断。

**24. 全球化不只是把中文替换成英文。**【规范明确】
文字长度、字形高度、日期货币格式、语言选择继承与RTL方向都影响体验。RTL不能整体机械镜像：布局方向可变，邮箱、固定英文名称等仍保留其阅读顺序。应根据产品支持的语言和地区判断适用规则。

## 四、从感受线索到问题结论的判断边界

### 1. 区分观察事实、感受推断与设计原因

以审批后H5仍可操作为例：“机器人显示审批完成，旧H5页面仍显示审批按钮”是可核实的现象；“用户可能怀疑是否成功”是对心理反应的推断；“跨入口状态矛盾，无法支持结果确认”是体验层面的原因分析。没有真实用户数据时，不能把可能的焦虑表述为所有用户已发生的反应。

问题结论需要说明具体阻力，例如无法确定结果、需要额外核对、可能重复操作，而不能只停留在“不舒服”“不友好”。

### 2. 区分规则要求、场景推导与个人偏好

| 判断层级 | 可以得出什么结论 | 典型表达 |
|---|---|---|
| 明确规则 | 已确认场景适用，且规范要求明确，可以判断不符合 | “同一个按钮区出现两个主按钮，不符合按钮规范” |
| 场景推导 | 根据角色、目标、上下文和后果，解释体验阻力；改法可能不唯一 | “打印的强调超过审批操作，会干扰当前任务优先级” |
| 业务待确认 | 先明确业务对象、决策规则或权限，再评价呈现及交互 | “每日或平均差标口径需确认；无论哪种，都应让用户理解超标依据” |
| 偏好或设计探索 | 不能仅凭喜欢某种外观就定为缺陷，需要收益与证据 | “卡片改表格是否更好，取决于比较任务、字段和信息量” |

判断时需要同时核对：**当前角色与任务、可观察的阻力、设计原因、适用规范、合理例外及实际影响。**

规范中的“必须/不允许”与“推荐/建议”应分别对待；基础规则与专项规则需核对作用范围。发现文档冲突或疑似笔误时，保留原始依据并向规范维护者确认，不能自行拼出新的强制规则。

差旅记录中的“菜单放到TabBar”“另开窗口”“删除增加确认”“标签必须上下排列”等，是具体场景下的建议，不能直接推广为通用规则。例如#67公告信息被挤压，不应简单得出“所有NoticeBar都换行”；还要判断内容是否适合使用通知栏承载。

通用设计原则需要结合具体场景判断：

- **有反馈，不等于每次都弹提示。** 页面状态变化足以支持结果确认时，可以不再增加成功Toast；重点是用户是否知道结果。
- **可恢复，不等于所有业务都允许撤销或修改。** 应核对实际后果、可逆性和替代处理路径，不把通用设计愿望当成业务承诺。
- **需要防错，不等于所有删除都增加二次确认。** 保护方式要与误操作风险、损失和恢复条件相称，还需遵循适用的公司规范。
- **视觉变量传递线索，不等于颜色或形状有固定含义。** “蓝色可点击、灰色不可用”等只能结合产品主题、控件状态和文字说明判断；圆角、阴影和动效也不能单凭风格偏好判错。

### 3. 区分规范符合性与用户影响

违反适用的明确规则，可以形成规范不符合结论；问题影响多大，还需要结合任务与后果判断。反过来，符合组件规范也不保证完整任务顺畅：每个按钮都合规，入口组织仍可能让用户找不到功能。

- **影响对象**：涉及哪些角色、使用频率和使用环境；少数用户受影响不代表可以忽略，关键角色或无障碍障碍仍可能阻断任务。
- **影响后果**：是短暂停顿、反复核对与额外操作，还是误判、错误提交、任务中断或无法恢复。
- **暴露与累积**：偶发的一次绕行与每天反复发生的绕行，负担不同；多个轻微问题也可能累积为持续阻力。
- **恢复条件**：用户能否自行识别和纠正，是否需要他人介入，是否已经产生实际业务后果。

情绪强烈程度不能直接等同于问题严重程度，案例原有等级也不能直接迁移到其他项目。

### 4. 区分必要约束与额外体验负担

权限限制、审批规则和风险确认可能是必要的，但呈现方式仍可评价。例如用户不能撤回已执行的业务，不一定是体验缺陷；未提前说明不可撤回、完成后仍显示撤回入口，或不告知后续处理路径，则可能形成额外问题。

体验判断需要保留业务约束，同时追查：限制是否可理解、出现时机是否合理、后果是否可预期、可行路径是否清楚。某个改法暂时不可行，也不意味着已经发现的阻力不存在。

## 来源与口径

设计原则与评价框架：

- [什么是好的体验设计？](https://app.notion.com/p/155eb206684883df91138190895dd358)：实用性、可用性、公平性与愉悦性。
- [什么是好的界面设计？](https://app.notion.com/p/6cbeb20668488207ba2e81a0efae744e)：用户目标、信息表达与视觉变量的关系。
- [什么是好的交互设计？](https://app.notion.com/p/e54eb206684882298d8301ff9dfebfe8)：任务路径、反馈、恢复、遇阻支持，以及效率、准确性、认知负荷与感受。
- [UI做不好的卡点在哪里？](https://app.notion.com/p/e07eb206684883168c30019a92cca096)：信息取舍、行为路径、系统一致性与业务判断。

设计原则提供分析参照，场景推导解释具体阻力，公司规范界定适用要求。三者应分别理解，并结合用户任务、业务约束和实际证据形成结论。

案例取自[新差旅问题汇总](https://hisense.feishu.cn/wiki/IRRswFB7lidPxGk3ux8cUgrun5e?sheet=7ec959)，#编号为表中问题序号。案例反映记录时的问题，不代表产品当前状态；原始严重等级不能直接作为其他场景的通用标准。

公司设计规范（不含归档文档）：

- [设计语言/设计价值观](https://hisense.feishu.cn/wiki/Bq15wCmB8ims59kHWyRcL4nHnpd)
- [设计语言/设计原则](https://hisense.feishu.cn/wiki/BBbyw125viyR74kcEgzchx4Anoc)
- [视觉规范/颜色](https://hisense.feishu.cn/wiki/XOe9woQMEiJYr6kCFiEcJghCnqe)
- [视觉规范/字体](https://hisense.feishu.cn/wiki/GwL2wsw2MiX5s7klz45cCmndnOe)
- [视觉规范/响应式设计](https://hisense.feishu.cn/wiki/QdFdwpzrti4Svakhu0scGYXSn5b)
- [交互设计指南/无障碍设计指南](https://hisense.feishu.cn/wiki/ZJQKwNgJeiIHMck4SOWco1F4nyf)
- [交互设计指南/数据录入](https://hisense.feishu.cn/wiki/WzqQwGmFOiO77NkurBoc1SC5nyw)
- [交互设计指南/数据展示](https://hisense.feishu.cn/wiki/GWlBwhUIAig3dQkQWn7cwrJ2n1f)
- [交互设计指南/数据格式](https://hisense.feishu.cn/wiki/Hd7fwujAGipVYEk6ahbcr4rHnDd)
- [交互设计指南/文案规范](https://hisense.feishu.cn/wiki/GbLZwAZHCiMuQkknDlFcGaPnn0b)
- [交互设计指南/帮助与反馈](https://hisense.feishu.cn/wiki/A8dRwFb9GiUaCbkLDJEc7EP1nQf)
- [交互设计指南/内容截取](https://hisense.feishu.cn/wiki/L7rSwf3O0isNTDknL5FcGGiPnlf)
- [交互设计指南/全球化设计指南/RTL 设计规范](https://hisense.feishu.cn/wiki/FrAkwMHu0iRB2pkEPsycDGcgnHg)
- [交互设计指南/全球化设计指南/语言切换](https://hisense.feishu.cn/wiki/Nxvfw1eAYiPDXnkKMs1cPNC1nub)
- [交互设计指南/可视化设计指南/配色](https://hisense.feishu.cn/wiki/HyZXwqedDiuW0sk4aVtciE2ZnVf)
- [交互设计指南/审批场景设计指南/审批页设计指南](https://hisense.feishu.cn/wiki/ZqVdw0NZaiVNovk9HD3cQQ6cnSf)
- [交互设计指南/审批场景设计指南/待办通知发送规范](https://hisense.feishu.cn/wiki/SePtwHNtdiQoMBks9lOc2d6anBT)
- [交互设计指南/PC组件/按钮 Button](https://hisense.feishu.cn/wiki/JdnIw5xtpiO2RIk1Qo0c86zxnJd)
- [交互设计指南/PC组件/抽屉 Drawer](https://hisense.feishu.cn/wiki/IYElwpukji0PHAk1CkccZKjDnxd)
- [交互设计指南/PC组件/表单 Form](https://hisense.feishu.cn/wiki/DoSUwFjVUiH6D3kv57Ocfpqdntf)
- [交互设计指南/PC组件/全局提示 Message](https://hisense.feishu.cn/wiki/SXEqwTW2GiUnJUksa9lcTl7Kn1f)
- [交互设计指南/PC组件/对话框 Modal](https://hisense.feishu.cn/wiki/LE7hwaoGdiz0KJk53m0clst7nme)
- [交互设计指南/PC典型页面/列表页](https://hisense.feishu.cn/wiki/JHucwfH9fizR8Bk2kdycvN1jnON)
- [交互设计指南/PC典型页面/表单页](https://hisense.feishu.cn/wiki/PODvwHjrfiO7tVkzFNtc3z3Anmd)
- [交互设计指南/移动组件/操作栏 ActionBar](https://hisense.feishu.cn/wiki/JBFowAEAmiCCV6kVbvOcqcHrnLe)
- [交互设计指南/移动组件/筛选栏 Filter](https://hisense.feishu.cn/wiki/Fopzw6k9WiT0eckbuhBcx5lEnue)
- [交互设计指南/移动组件/通知栏 NoticeBar](https://hisense.feishu.cn/wiki/TFDJwiRymiyR7UkMpMIcZ0pPnw3)
- [交互设计指南/移动组件/轻提示 Toast](https://hisense.feishu.cn/wiki/ECAwwBBpYiK5Dgk0b30cmq3anVb)
- [交互设计指南/移动典型页面/布局框架](https://hisense.feishu.cn/wiki/BVNMw5wDliGYnrk2xtgc1w8hnmf)
- [交互设计指南/移动典型页面/表单页](https://hisense.feishu.cn/wiki/VjrQwpZPAi6k6HkeA1NcmRDKnXg)