实践清单与判断清单
附：实践清单与判断清单
一、从业者实践清单
1.1 项目启动清单
开始任何 UX 工作前，先用这几个问题校准方向（参见第1、7章）：
- 我是否能用一句话说清用户想完成什么？ - 我是否知道用户在什么情境下完成任务？ - 我是否找到了关键任务，而不是只列功能？ - 这个项目的起点是问题还是已经带着方案的请求？ - 这个输入来自哪里——用户、客户、销售、数据、客服、还是老板？ - 它是一个问题、一个目标、一个方案，还是一个功能请求？
如果前四个问题答不上来，后面的设计很可能只是猜测。
1.2 问题定义清单
从模糊需求走向可操作的问题陈述（参见第7章）：
- 谁在什么情境下遇到了这个问题？ - 用户原本想完成什么任务？ - 当前阻碍是什么：找不到、看不懂、步骤太长、反馈没用、规则不透明？ - 阻碍造成了什么后果——退出、出错、求助、投诉、返工、流失？ - 有哪些证据支持这个判断（研究、数据、客服工单、投诉）？ - 有没有相反证据或解释不通的地方？ - 根因可能是什么，是否需要继续研究？ - 这个问题同时带来用户价值和业务价值吗？
实用习惯：在开始画方案前先写一句问题陈述。如果写不清，不是文案能力问题——是团队还没有真正理解问题。
1.3 需求理解清单
区分"用户说要什么"和"用户真正需要什么"（参见第7章）：
- 这是一个问题、一个目标、一个方案，还是一个功能请求？ - 如果是功能请求（"加导出""重做首页""加 AI"），背后隐含着什么任务缺口？ - 当前资源和技术条件是否允许解决？ - 如果必须排序，影响范围、严重度、证据强度、成本和风险分别如何？ - 成功标准是什么？哪些假设需要先验证？
1.4 用户研究清单
研究不是"找几个人聊聊"，而是为决策提供可验证的证据（参见第6章）：
- 这次研究要支持什么决策？ - 研究目的属于探索、验证、评估，还是监测？ - 研究问题是否具体到用户、情境、行为和不确定点？ - 方法选择是否匹配目的，而不是沿用团队习惯？ - 是否需要定性和定量结合？ - 样本是否覆盖关键用户类型和使用情境？招募来源是否可能造成偏差？ - 访谈问题、任务脚本或问卷题目是否存在诱导？ - 是否取得告知同意并说明数据用途？ - 输出是否包含证据、洞察、限制、建议和待验证假设？ - 研究结果是否进入产品决策，而不是只停留在报告里？
如果研究报告不能说明"它改变了团队哪个判断"，它的价值还没有真正发生。
1.5 访谈执行清单
访谈不是问用户要答案，而是追溯真实经历（参见第6章）：
- 访谈前是否已看过可用的行为日志或客服数据，让访谈更有针对性？ - 提问是否聚焦具体经历（"上次遇到这个问题是什么时候？你先做了什么？"）而非抽象偏好（"你觉得好用吗？"）？ - 是否记录了行为线索（犹豫、绕路、叹气）而不仅仅记录用户原话？ - 是否避免在用户操作时主动解释或打断？
1.6 问卷设计清单
问卷帮你判断问题的规模，前提是题目本身不把用户带偏（参见第6章）：
- 题目是否足够具体？"你觉得好用吗"不如"过去 30 天内，你是否因为找不到报销状态而联系过财务？" - 是否避免了含糊词（"通常""一般""比较"）？ - 是否避免了诱导性题干（"你是否喜欢我们全新升级的便捷功能"）？ - 是否避免了双重问题（"你觉得搜索功能和帮助中心好不好用"）？
1.7 可用性测试清单
测试是观察用户在真实任务中的行为，不是收集评价（参见第18章）：
- 测试目标是什么——发现常见问题还是量化基准？ - 测试任务是否来自真实用户目标，而非系统功能描述？ - 任务脚本是否把答案埋进去了？（"请用搜索找到报销页面"不是好任务） - 是否准备了 3 个以上任务——从简单到复杂，让用户先建立信心再暴露短板？ - 执行中是否只观察不打断？（错误时刻是最有价值的信号） - 记录是否区分了"用户做了什么"和"观察者认为这意味什么"？ - 结果分析是否先找失败模式（所有失败集中在哪一个环节）而非逐个修问题？
1.8 用户画像与旅程地图清单
建模不是为了贴墙——是为了帮团队做出比之前更明确的设计决策（参见第8章）：
- 这个模型要帮助团队做什么决定？ - 用的是画像、分群、场景、任务分析、旅程图，还是服务蓝图？ - 模型是否有研究证据支撑，而不是团队想象？ - 画像是否包含目标、行为、限制和设计影响？（照片和年龄不重要） - 场景是否包含触发条件、环境、时间压力和风险？ - 任务分析是否从用户目标出发，而不是照搬系统功能？ - 旅程图是否包含阶段、触点、行为、感受、痛点、证据和机会？ - 服务蓝图是否清楚区分前台触点、后台动作和支持系统？ - 模型是否标注了证据来源和不确定性？ - 模型是否转化为了设计机会、优先级或验证计划？
如果团队看完模型只觉得"做得很完整"但不知道下一步改什么，这个模型还没有完成工作。
1.9 信息架构设计清单
结构比界面更早决定用户能不能找到路（参见第10章）：
- 用户要完成哪些关键任务？ - 当前信息和功能有哪些，是否做过盘点？ - 现有结构是按用户任务、业务部门、技术模块，还是历史堆叠形成的？ - 分类原则是否稳定——同一层级不能一会儿按部门一会儿按任务一会儿按产品线？ - 标签是否贴近用户语言而非内部术语？ - 是否用了卡片分类理解用户心智模型，树测试验证可找性？ - IA 改动后准备观察哪些指标（搜索日志、任务成功率、客服工单中的"找不到"类关键词）？
1.10 任务流程设计清单
交互设计从任务开始，不从页面开始（参见第11章）：
- 关键任务的用户目标是什么？ - 用户流（用户视角）、任务流（步骤和决策）和系统流（后台处理和异常）是否分别画清楚？ - 是否只设计了正常路径，还是包含了异常和权限不足的路径？ - 每一步用户是否知道系统状态——正在保存、已提交、等待审核？ - 高风险动作（删除、支付、授权）是否有确认、预览或撤销机制？
1.11 交互设计清单
交互的质量不看理想路径，看用户出错后多快能恢复（参见第11章）：
- 错误是否能被提前预防——合理默认值、输入约束、即时校验、风险提示？ - 错误发生后是否说明了原因、影响和下一步——不只是"操作失败"，而是具体到字段和修正方式？ - 用户输入是否被保留，避免重复劳动？ - 空状态、加载中、失败、无权限、过期、冲突、部分完成——这些"边界状态"是否都有设计？ - 批量操作是否处理了范围、预览、部分失败和日志？ - 移动端和桌面端是否按任务差异而非屏幕尺寸做了调整？
1.12 表单设计清单
表单是交互中最细碎、最容易暴露设计短板的地方（参见第11章）：
- 字段命名是否清楚？必填项是否提前说明？ - 输入格式是否给出示例？即时校验是否在用户提交前给出反馈？ - 提交失败是否保留已填内容？错误提示是否定位到具体字段？ - 提交后，用户是否知道结果、下一步和预计时间？
1.13 复杂后台设计清单
企业产品体验的难点不在功能少，在角色、权限和异常多（参见第29章）：
- 当前场景涉及几个角色？是同一人在做还是多人在接力？ - 每个角色的成功标准一样吗——是"更快填完"还是"更快判断对错"？ - 权限变更后，用户能否看到变更影响，还是需要自己去猜？ - 批量操作有没有预览、部分失败明细和日志留痕？ - 工作流中的"卡住"点——退回、超时、撤回、转交——是否都被设计过了？
1.14 移动端体验设计清单
移动端不是桌面端缩小版（参见第28章）：
- 用户使用场景是什么——路上、排队、床上？网络是否可能不稳定？ - 输入成本——键盘弹出后会不会遮挡关键信息？ - 按钮尺寸是否适合拇指触控？手势是否可替代？ - 关键信息是否在首屏可见（不需要滚动）？ - 加载和失败状态的反馈是否足够清楚？
1.15 视觉一致性清单
视觉设计不是好不好看，是层级是否让用户一眼找到该做的事（参见第15章）：
- 去色后，信息层级是否仍然成立？ - 字体统一换为系统默认后，可读性是否仍然保持？ - 缩小到 320px 宽度后，最先崩的是什么？ - 关键操作按钮是否和导航链接有足够的视觉区分？ - 颜色是否被用来传递独立的信息（不只是装饰），如果是，是否配套了文字说明？
1.16 内容体验清单
用户看文字不只是阅读——是在做下一步操作之前找方向（参见第13章）：
- 用户此刻要完成什么任务？在这一刻缺哪条信息就会停下来？ - 哪些信息必须提前出现，哪些可以延后？ - 术语是否统一？同一个东西三个页面三种叫法，用户会以为是三个不同的功能。 - 按钮是否说明了动作和对象——不只是"保存"，而是"保存草稿，剩余信息可稍后补充"？ - 错误信息是否回答了三个问题——发生了什么、为什么、现在可以做什么？ - 空状态是否给了下一步——不是"暂无数据"，而是"创建第一个项目，可以从模板开始"？
1.17 无障碍体验清单
可访问性不是上线前的最后一道检查——是产品在任何感官通道下都能被使用的能力（参见第19章）：
- 关掉显示器，用屏幕阅读器走一遍核心流程。你在第几步卡住了？ - 表单是否有关联的标签（label），而不仅仅依靠 placeholder 占位文字？ - 颜色是否不是唯一的信息区分方式——错误提示是否同时有颜色变化和文字说明？ - 焦点顺序是否符合视觉布局——Tab 键跳转有没有跳过关键控件？ - 验证码是否提供了语音替代方式，时限是否足够？
1.18 设计评审与走查清单
评审不是审美投票，是风险检查（参见第22章）：
- 评审前是否准备了可检查的标准——任务是否完成、关键状态是否覆盖、是否符合设计系统？ - 是否在每个关键流程中加入了反向问题："如果用户事后投诉，我们最可能被质疑什么？" - 是否记录了为什么选择这个方案、放弃了哪些方案？
1.19 上线验证清单
上线不是终点——是观察真正的开始（参见第1、22章）：
- 是否为改进方案预设了验证指标？ - 是否计划在上线后继续观察任务成功率、错误率、客服工单、投诉内容？ - 失败场景——网络断、支付失败、权限不够——是否在产品进入真实用户手中后被触发过？
1.20 项目复盘清单
迭代的终点不是"已上线"——是"下一次再做类似决定时，我们比这次更清楚"（参见第22章）：
- 这个项目当初的核心假设是什么？被验证了还是被推翻了？ - 哪些设计决策是凭直觉做的——事后证明对了吗？ - 是否有经验被沉淀为设计原则、组件规范、内容规则或服务流程，而不仅仅是口头的"下次注意"？
---
二、管理者判断清单
2.1 UX 投入必要性判断清单
不是每个待办事项都需要专门的 UX 投入——但每个待办事项在审批前，都需要回答它解决的是用户问题还是内部假设（参见第1、3章）：
- 当前被提出的"体验问题"，是否具体到了某个用户任务和触点——或是笼统的"体验不好"？ - 这个问题是否有什么证据——用户研究、数据异常、客服工单集中趋势、投诉聚类？ - 如果暂不投入，代价是什么——流失、返工、客服成本、合规风险？ - 如果要投入，先确认的是"用户行为的哪一步卡住了"，而不是"什么时候能画设计稿"。
2.2 UX 项目立项判断清单
立项不是批准一个设计项目，是批准一个解决问题的路径（参见第3、5章）：
- 团队是否先澄清了问题，而不是马上承诺做某个功能或页面？ - 发现阶段是否有真实用户证据，而不只是内部讨论？ - 方案选择是否说明了标准——用户影响、业务价值、技术可行性和风险？ - 是否区分了短期交付物和长期组织学习？ - 是否有上线后的度量和复盘计划？
2.3 UX 优先级判断清单
在多个"都对"的项目中选择先做哪一个（参见第7、21章）：
- 这个问题影响的是核心用户还是边缘用户？ - 影响的严重程度：是轻微不便、重复劳动、经济损失，还是安全或合规风险？ - 有多来源证据还是一两条内部意见？ - 修复的风险是什么——会不会撬动已有工作流？ - 如果只做一件，"不做后果最严重"的那件是什么？
2.4 UX 团队专业度判断清单
判断团队专业不专业，不看作品集封面，看他们回答问题的能力（参见第1、2章）：
- 他们说的 UX 问题，具体发生在哪个用户任务或客户触点中？ - 这是界面呈现问题，还是流程、规则、内容、后台交付、组织协作问题？ - 如果只改 UI，哪些问题仍然不会改变？ - 专业的团队不会把所有问题包装成"做 UX 就能解决"——会告诉你哪些是界面问题、流程问题、服务交付问题、策略问题。
2.5 UX 研究质量判断清单
研究不是装饰材料——应该帮组织做出更清楚、更负责任的选择（参见第6章）：
- 团队是否先说明了研究要回答什么问题，而不是直接报价"几场访谈"？ - 样本是否匹配目标用户，而不是找方便的人？ - 研究方法是否能回答当前决策问题？ - 团队是否区分了用户原话、观察事实和研究解释？ - 是否说明了样本限制和研究边界？ - 是否有研究伦理安排——告知同意、隐私保护、退出机制？ - 研究结论是否转化为设计机会、优先级或验证计划？ - 警惕一种研究：报告很厚、引用很多用户原话，但没有回答任何一个决策问题。
2.6 UX 方案质量判断清单
设计方案的质量不看画了多少页面——看提出了多少可追问的判断（参见第5、10、11章）：
- 方案是否说明了"为什么是这个方案，不是另外两个"？ - 设计师是只画了正常路径，还是覆盖了空状态、失败、权限不足、批量处理、离线场景？ - 关键操作的反馈是否被设计——不只是"操作成功"，而是用户知道成功意味着什么、下一步可以做什么？
2.7 UX 指标与商业价值判断清单
不是所有 UX 项目都需要算 ROI——但每个都需要说明影响了什么、怎么判断（参见第3、20、21章）：
- 团队说明了体验问题具体发生在哪个用户任务中吗？ - 他们区分了用户行为指标、产品指标和业务结果吗？ - 是否说明了价格、促销、流量、销售等其他可能影响结果的变量？ - 是否同时考虑了增长、成本、风险和信任四个维度？ - 如果用了 ROI 数字，投入、收益、周期和归因假设是否透明？ - 如果没有足够数据，团队是否承认只能做方向性估算？
值得信任的 UX 团队不会只给你一个激动人心的 ROI 数字——会给一条能被检查的价值链。
2.8 UX 成本收益判断清单
UX 不是免费的工作——需要判断在什么条件下该投入，什么条件下不该（参见第3、21章）：
- 研究、设计、开发、测试、培训、变更管理各要花多少人和多少时间？ - 回报路径是收入增加、成本节省、风险降低，还是长期能力建设？不同回报路径用不同的证据强度。 - 如果不做，代价是否算得清——投诉、流失、返工、品牌损耗？ - 机会成本：这笔投入如果不花在 UX 上，花在哪里回报更高？
2.9 设计系统投入判断清单
判断设计系统是一笔合理的投资还是跟风（参见第16章）：
- 你的设计系统是组件库，还是包含了模式、内容、可访问性和治理？ - 有人维护吗——如果维护的人离职了，系统还能活多久？ - 三个产品线的开发团队都在用吗——如果不是，你还没有系统，你只有文档。 - 你删过组件吗？如果从来没有删过，系统正在变成垃圾场。 - 可访问性检查是内建在组件里的吗——还是"设计师记得时检查一下"？
2.10 外部设计供应商判断清单
评估外部团队或设计服务时（参见第1、3章）：
- 他们是否先澄清了问题，而不是马上承诺做某个功能或页面？ - 交付物是否只有界面稿，还是包含问题定义、验证和指标？ - 他们是否避免了承诺无法归因的 ROI？ - 他们是否能解释设计方案为什么是这样、如何验证、哪些地方还不确定？
2.11 组织体验成熟度判断清单
判断组织是否具备可持续的体验能力，而不只在单个项目中做出好作品（参见第23、25章）：
- 体验问题有没有统一入口，还是客服、销售、产品、设计各自记录？ - 是否有优先级规则——还是只有领导偏好决定先做什么？ - 是否有责任人和闭环状态——每个关键问题都知道谁负责、下一步是什么、何时复盘？ - 是否能沉淀为组织知识——反复出现的问题是否转成了原则、规范、组件和培训？ - 设计评审是按风险分层还是按页面层层审批？
治理的目标不是多一层签字——是让关键判断不靠临场记忆。
2.12 管理者常见误判清单
管理者最容易在以下地方误判 UX 投入与产出（参见第3、4、25章）：
- 把体验质量等同于 NPS 分数。——NPS 可以观察推荐意愿，但不能定位具体体验问题。 - 把客服量下降误认为体验变好。——也可能说明客服入口被隐藏了。 - 把转化率上升当成"UX 做对了"。——也可能是因为折扣更大、流量更精准。 - 认为"用户体验是设计团队的事"。——费用说明、退款规则、权限模型、客服脚本都在影响体验。 - 认为伦理是法务的事。——取消入口的位置、默认选项的勾选、风险提示的字号，不是法务能逐项审查的。 - 奖励短期转化和拦截率，却惩罚"因为加了确认步骤导致转化略降"的设计。——推动长期信任的设计会被短期指标惩罚。
2.13 UX 决策会议提问清单
在关键决策会上，用这些问题让讨论从"好不好看"转向"有没有解决问题"（参见第21、22、25章）：
- 我们今天要决定的，到底是什么问题？ - 这个问题有什么证据——不是"谁觉得"，是"谁在哪一步卡住了"？ - 如果不做这个方案，不做后果最严重的是什么？ - 方案上线后，我们看哪两个指标来判断它是否有效？ - 有没有保护指标——转化上升时，有没有同时看投诉和退款？ - 这个方案有没有退出信号——什么条件下我们会承认它行不通？