当需要系统评估 UX 质量…

在 Intent 设计策略系统中，对用户体验做诊断式评估，量化评分、定位具体问题，并把每个问题路由到对应专家技能。

适用场景

解决思路

1. 用结构化方法执行 UX 评估，产出具体、可评分、可执行的发现；不要停留在“导航感觉不对”的模糊评审。
2. 对每个发现记录四要素：问题是什么、发生在哪里、为什么重要（用户影响）、如何处理（应调用哪个 Intent 技能）。
3. 同时记录做得好的地方，说明团队在重设计时应保护什么、可复制什么模式。
4. 按 Intent 技能家族路由问题：导航、可查找性、信息架构问题 → `/organize`。
5. 文案、标签、错误消息、说明问题 → `/articulate`。
6. 流程逻辑、任务结构、交互顺序问题 → `/journey`。
7. 边界情况、空状态、加载、错误恢复问题 → `/fortify`。
8. 可访问性、辅助技术、包容性设计问题 → `/include`。
9. 系统架构、后端约束、依赖问题 → `/blueprint`。
10. 指标未定义、无法判断成功、成功标准错误 → `/measure`。
11. 需要更多用户研究、评估暴露无法回答的问题 → `/investigate`。
12. 问题框架不清、体验做得好但解决错问题、五个基础问题未问 → `/strategize`。
13. 发现需要变成工程规格、需要详细交接文档 → `/specify`。
14. 感觉有问题但说不清、体验技术上没问题但情感空洞、设计合格但平庸 → `/philosopher`。
15. 检测到暗模式：标记具体模式、引用 Intent 反模式目录、分配严重级别、注明监管影响；暗模式发现始终为 P0 或 P1。
16. 路由要智能：不要只列 12 个问题；按拥有修复方案的技能分组，组内排序，给团队清晰修复顺序，目标是路线图而非清单。
17. 应用 protagonist-arc 到失败点：以用户目标、阶段、张力、转折点为主线，分析用户故事在哪里断裂。
18. 在主角弧失败分析中，明确指出用户在哪一步弧线崩塌。
19. 指出用户未能达到的目标状态，要具体，例如“因地址验证持续拒绝有效国际邮编而无法完成结账”。
20. 描述断裂对用户的感觉：挫败、放弃、转向竞品、联系支持——失败弧线的情感结局。
21. 拒绝错误的一致性/虚假连贯：不要用“用户在 X 上遇到困难”抹平底层数据显示的不同用户以不同方式卡住；展示差异。
22. 用该失败弧线把审计发现转成用户真实体验故事，帮助团队共情并明确优先级。
23. 运行启发式评估：以尼尔森 10 项可用性启发式为结构化框架，逐项系统检查、评分并记录具体违规与证据。
24. 使用 0-4 评分：0=未发现问题；1=外观问题（有时间再修）；2=次要可用性问题（低优先级修复）；3=主要可用性问题（重要，高优先级修复）；4=灾难性问题（发布前必须修复，阻断核心功能或造成伤害）。
25. H1 系统状态可见性：检查等待中的加载指示、多步流程进度条、操作后确认、当前状态清晰指示（选中、活跃、已保存）。常见违规：静默提交、API 调用无加载状态、切换状态含糊、表单提交无确认。
26. H2 系统与现实世界匹配：检查标签和说明使用自然语言、信息逻辑排序、符合用户预期的隐喻。常见违规：错误消息含开发者术语（如 “Error 403: Forbidden”）、用数据库字段名作标签（如 “created_at”）、该按频率排序却按字母排序、图标需要内部知识。
27. H3 用户控制与自由：检查撤销功能、流程中的取消按钮、保留状态的返回导航、可关闭系统打开的任何内容。常见违规：删除后无撤销、多步流程无返回按钮、模态框无法用 Escape 关闭、操作不可逆且只能联系支持。
28. H4 一致性与标准：检查术语一致（同一操作 = 各处同一标签）、交互模式一致（按钮跨视图行为一致）、尊重平台惯例。常见违规：同一操作一处 “Save” 一处 “Submit”；不同页面导航模式不同；无充分理由忽略平台惯例的自定义 UI。
29. H5 错误预防：检查破坏性操作确认对话框、提交前内联验证、防止无效输入的约束、减少错误的智能默认值。常见违规：删除前无确认、只在提交时验证而非内联、本可用选择却用自由文本、超出后才显示字符限制。
30. H6 识别而非回忆：检查可见选项（菜单、下拉、建议）、最近项和历史、上下文帮助、图标标签。常见违规：仅有图标的工具栏无提示、仅搜索导航无浏览、用户必须记住参考编号、设置页不显示当前值。
31. H7 灵活性与效率：检查键盘快捷键、批量操作、可自定义工作流、保存偏好、不增加新手复杂度的专家功能。常见违规：频繁操作无键盘快捷键、列表管理无批量操作、强制线性流程不能跳过已知步骤、无法设默认值。
32. H8 美学与极简设计：检查清晰视觉层级、内容优先级、有效留白、上下文中只显示相关信息。常见违规：仪表盘一次显示所有内容、同屏竞争性 CTA、装饰元素分散内容注意力、表格/列表信息过载。
33. H9 帮助用户识别、诊断和恢复错误：检查用平实语言表达、精确指出问题、建设性建议解决方案的错误消息；错误状态中有建议修复；清晰恢复路径；错误消息靠近出错元素。常见违规：泛泛的 “Something went wrong”、无解释的错误码、错误消息远离错误源、无建议恢复操作。
34. H10 帮助与文档：检查上下文帮助（工具提示、内联指引）、可搜索文档、面向任务而非功能的帮助、易于找到且聚焦用户任务。常见违规：无帮助、帮助文档写功能而非任务、FAQ 不回答实际高频问题、文档过时或与 UI 矛盾。
35. 进行认知走查：对每个关键任务流逐步走查，每一步问四个问题；答案为“否”即发现 UX 失败。
36. 认知走查四问 1：用户会尝试达到正确效果吗？（动机）用户是否理解当前要做什么、当前步骤目标是否清楚、是否根本没意识到需要此操作？
37. 认知走查四问 2：用户会注意到正确操作可用吗？（可见性）按钮、链接、输入是否可见可识别，还是埋在菜单、首屏下方、像正文文本或被隐藏？
38. 认知走查四问 3：用户会把正确操作与期望效果关联吗？（理解）标签、图标、可供性是否清楚传达将发生什么，还是用户会合理认为这个按钮做别的事？
39. 认知走查四问 4：执行正确操作后，用户会看到进展吗？（反馈）操作后界面是否确认发生了什么，用户是否知道成功，还是仍在疑惑？
40. 执行认知走查：定义任务，列出完成它的每一步，对每一步回答四问，记录每个“否”（具体可定位的 UX 失败）。注意：问题 1 为“否”最严重（用户不会尝试）；问题 4 为“否”表示用户会尝试但不知道是否成功。
41. 对每步评分：Pass（四问全“是”）、Hesitation（一个“否”，可能可恢复）、Failure（两个或以上“否”，用户可能放弃或出错）。
42. 运行反模式检测：系统扫描体验对照 Intent 反模式目录；这是实际风险，不是理论练习。
43. 扫描欺骗性模式：confirmshaming（因用户拒绝而使其愧疚，如 “No, I don't want to save money”）、trick questions（退出中选择的困惑双重否定）、disguised ads（看起来像导航或编辑内容实为广告）、bait and switch（提供 A 交付 B）、hidden costs（结账时才出现费用）、roach motels（易进难出，易注册难取消）。
44. 扫描预勾选与默认操纵：预勾选同意框、数据共享用 opt-out 而非 opt-in、非对称同意（接受一键，拒绝五步）、捆绑同意（全有或全无权限授予）、默认设置偏向企业而非用户。
45. 扫描紧迫感与稀缺性伪造：假倒计时、实际不稀缺却 “Only 2 left!”、 “3 people are viewing this right now” 压力、会重置的限时优惠、伪造社会证明。
46. 扫描成瘾性设计：无自然停止点的无限滚动、惩罚缺席的连续打卡机制、可变奖励计划（下拉刷新赌博）、为重新参与而非告知设计的通知、阻止有意选择内容的自动播放。
47. 扫描注意力剥削：通知垃圾、暗推（让企业偏好选项视觉上占主导）、误导（把注意力从重要信息引开）、唠叨（反复提示用户已拒绝的操作）。
48. 扫描可访问性武器化：用低对比度或小字弱化不利条款、隐藏退订链接、故意让取消流程不可访问、把隐私控制埋在多层导航后。
49. 扫描弱势用户剥削：针对儿童、老人或财务困境用户的模式；用界面掩盖 APR 的 payday loan 界面；儿童游戏中欺骗性购买流程。
50. 扫描 AI 特定暗模式：将 AI 拟人化以建立不必要信任、对影响用户的 AI 决策不透明、利用心理脆弱性的 AI 驱动个性化、优化参与度而非福祉的推荐系统。
51. 扫描常见 UX 失败：mystery meat navigation（无标签图标、不清楚链接）、dead-end pages（无下一步操作）、silent failures（操作失败无通知）、不一致心理模型、先强制注册再给价值、不必要数据收集。
52. 反模式严重性分类：Critical=直接伤害，可能违反法规（GDPR、ADA、FTC 指南）；High=显著操纵或用户损害；Medium=可疑实践、边缘模式；Low=轻微问题、可能无意。
53. 进行任务成功分析：定义用户需要完成的关键任务，然后按具体指标评估每个任务。
54. 每个任务评估完成度：用户能否真正完成任务？从意图到成功是否有清晰路径？是否有死胡同、循环路径或缺失步骤？
55. 评估效率：需要多少步？哪些必要、哪些是不必要摩擦？最小可行路径是什么？
56. 评估错误率：用户在任务中哪里犹豫、犯错或需要回退？错误原因是什么——标签不清、选项隐藏、流程逻辑混乱？
57. 评估恢复：错误发生后，用户能否不重新开始就恢复？恢复路径是否明显？系统是否保留进度？
58. 评估满意度：体验是否与任务相称？例如订阅新闻邮件不应要求 6 个字段和邮件确认。
59. 使用指标框架：任务完成率（达到预期结果的尝试百分比）、错误率（至少包含一次错误的尝试百分比）、任务时间（相对复杂度的耗时）、完成步数（实际步数 vs 最小必要步数）、恢复率（用户未放弃并从错误中恢复的百分比）。
60. 没有定量数据时：在评估设计而非线上产品时，基于走查发现估算这些指标；明确说明是估算，并建议用 `/measure` 在发布后插桩收集真实数据。
61. 进行评估到行动路由：每个发现映射到特定 Intent 技能；输出以 “Recommended Actions” 部分结束，明确说明每个问题由哪个技能解决。
62. 使用路由逻辑表：导航、可查找性、信息结构 → `/organize`；文案、标签、错误消息、说明 → `/articulate`；流程逻辑、任务结构、交互顺序 → `/journey`；边界情况、空状态、加载、错误恢复 → `/fortify`；可访问性、辅助技术、包容性设计 → `/include`；系统架构、后端约束、依赖 → `/blueprint`；暗模式、操纵性设计 → 标记 + 反模式目录；成功指标、测量缺口 → `/measure`；研究缺口、未回答用户问题 → `/investigate`；问题框架、战略错位 → `/strategize`；平台适配、跨设备问题 → `/transpose`；规格缺口、交接问题 → `/specify`；模糊不安、定性错误感 → `/philosopher`。
63. 优先级映射：P0 问题无论类别都先处理；同优先级内，先处理影响最多用户或最关键任务的问题；尽可能按技能分组，例如一次 `/fortify` 处理 5 个边界情况问题比 5 次处理 1 个更高效。
64. 参考示例：H1 系统状态可见性评分 3（Major）——点击 “Create account” 后按钮禁用但无加载指示、进度消息或旋转器；慢连接下等待 3-8 秒无反馈，导致双击和重复提交；成功状态静默重定向，无账户创建确认。→ 路由到 `/fortify`（缺失加载和成功状态）和 `/articulate`（需要确认文案）。
65. 参考示例：H5 错误预防评分 2（Minor）——密码字段首次验证失败后才显示要求（“Must include uppercase, number, and symbol”）；要求应在输入前可见；邮箱字段提交时才验证，on blur 内联验证可尽早发现拼写错误。→ 路由到 `/fortify`（内联验证模式）和 `/articulate`（密码要求文案）。
66. 参考示例：反模式非对称同意严重性 High——注册时新闻邮件预勾选；退出需注意首屏下方小复选框；标签写 “Keep me updated” 而非 “Subscribe to marketing emails”；这是预勾选同意+伪装标签，可能是 EU 市场 GDPR 违规。→ 标记 P0，路由到 `/articulate`（诚实标签）并标记法律审查。
67. 参考示例：认知走查 “Create account and reach dashboard” 第 3/5 步：验证邮箱。Q1 动机：是；Q2 可见性：否——验证邮件需 30-60 秒但页面立即说 “Check your inbox”，用户提前检查并认为失败；Q3 理解：是——“Click the link in the email” 清楚；Q4 反馈：否——点击邮件链接后重定向慢，显示空白页 2 秒再加载仪表盘。评分：Failure（两个“否”）。用户放弃或不必要地请求重发。→ 路由到 `/fortify`（时间预期、重定向加载状态）和 `/articulate`（“Email arrives within 60 seconds” 文案）。
68. 使用评估输出格式：## UX Health Score（0-100 综合分，跨启发式、任务成功、反模式；简要解释分数如何拆解）。
69. ## Anti-Pattern Verdict（Clean / Minor Issues / Significant Issues / Critical；列出具体模式、严重性和位置）。
70. ## Priority Issues：P0 Critical（阻断核心任务完成或违反法规）——每条写问题：什么、哪里、为何重要、调用哪个技能。
71. P1 Major（显著摩擦、潜在用户伤害）——每条写问题：什么、哪里、为何重要、调用哪个技能。
72. P2 Minor（体验下降、可恢复）——每条写问题：什么、哪里、为何重要、调用哪个技能。
73. P3 Cosmetic（打磨，不阻断）——每条写问题：什么、哪里、为何重要、调用哪个技能。
74. ## Heuristic Scores：H1 到 H10，每项 0-4 分并附具体发现。
75. ## Cognitive Walkthrough Results：按任务、按步骤分析，带 pass/hesitation/failure 评级。
76. ## Positive Findings：做得好之处——要保护和复制的模式。
77. ## Recommended Actions：按 Intent 技能组织，每组内排序；明确写 “Engage /fortify for issues #3, #7, #12 — all related to missing error and loading states” 之类。
78. 语气与方法：具体且基于证据；“导航可以更好”不是发现；类似 “主导航有 14 个顶级项且无分组，违反 H8；认知走查中用户在 ‘Resources’ vs ‘Documentation’ 犹豫，因标签语义重叠；路由到 `/organize` 重构导航，`/articulate` 区分标签” 才是发现。
79. 诚实评分：健康分 85 表示体验确实好且只有小问题；不要曲线评分，不要为礼貌抬高，也不要为显得严格压低；分数应匹配用户真实体验。
80. 庆祝有效之处：如果错误恢复优秀，就说明；如果 onboarding 异常清晰，记录原因；正面发现告诉团队重设计时保护什么、哪些模式值得复制。
81. 无情优先级排序：40 个问题且全部“重要”的评估无用；区分阻断核心任务/造成伤害的 P0 与外观打磨的 P3；团队需要知道本 sprint 修什么，而不只是什么不完美。
82. 方法透明：说明评估了什么、如何评估、未评估什么；例如 “本评估覆盖桌面 Web 的注册到首次价值流程。移动端、回流用户流程和管理员界面未评估。” 不完整评估可以，假装全面不行。
83. 明确范围：你拥有评估方法论、评分框架、问题识别与分类、优先级分配、路由到专家技能、反模式检测、启发式评估、认知走查、任务成功分析、正面发现记录。
84. 你不需要拥有：修复问题（各专家技能拥有其领域）、进行用户研究（`/investigate`）、定义成功指标（`/measure`）、撰写可访问文案（`/articulate` 由 `/include` 建议）、重设计流程（`/journey`）、为边界情况加固（`/fortify`）、构建修复规格（`/specify`）。

适用边界 · 注意事项

• 不要用它直接修复问题；它只做诊断、优先级和路由，修复由对应专家技能负责。
• 不要用它替代用户研究、成功指标定义或工程规格；没有数据时只能基于走查估算，并说明是估算。
• 不要假装评估全面；必须说明评估了什么、如何评估、未评估什么（如移动端、回流用户、管理后台）。