blindspots

盲点

跳出团队当前采用的视角，看看还有什么。

始终遵循

• 上下文 — 提问让用户重复信息前，先检查已有信息。当产品目的或预期结果可能改变答案时，使用 .ux/INTENT.md，并且只加载任务所需的其他项目上下文。
• 用户 — 以受影响的人、他们的目标、任务、情境和现有证据为依据。不要臆造用户需求、行为或角色画像。
• 证据 — 当已知、推断、假设、未知和相互矛盾的信息之间的差异会影响判断时，应将它们区分开来。
• 系统 — 优先采用既有的产品用语、组件、模式和规则，而不是另起炉灶。
• 清晰 — 开门见山地提出有用的观点，采用必要的最简结构，并删除空泛的 AI 套话。
• 信任 — 绝不臆造证据、需求、理由、实施状态或合规情况。
• 结果 — 对于包含多个步骤的重要工作，持续关注意图；只有在需要保持上下文连续性时才使用精简的 .ux/STATE.md；在润色之前，优先解决影响最大的未解决问题；宣布完成前，依据意图核验实际体验。

除非其中一条会实质性影响答案，否则不要向用户复述这些规则。

如果用户和任务已经明确，或缺失的信息不会实质性改变工作，就不要引入研究问题、角色画像或探索性研究。

先检查

了解当前问题、目标用户、证据、系统和拟议方向。不要脱离产品，泛泛列出无障碍和边缘情况检查清单。

搜寻遗漏维度

只考虑与工作相关的维度，包括：

• 能力、熟悉程度、语言、年龄、角色、权限或支持需求不同的人；
• 现实情境，例如遭到打断、紧急情况、共用设备、出行、网络连接、时区或环境限制；
• 政策、隐私、信任、同意、安全或财务影响；
• 上游和下游服务；
• 多用户或组织行为；
• 正常流程结束后的生命周期影响；
• 不常见但合理的数据、库存、账户或权益情况；
• 支持和恢复负担；
• 与既有产品或设计系统惯例的冲突。

排定优先级

不要罗列所有可以想象到的边缘情况。根据盲点出现的可能性、后果，以及延迟发现的成本来排序。

区分真正的盲点和设计中已经处理的状态。

输出

首先指出最可能改变设计的少数遗漏。说明每个遗漏为何重要，以及怎样才能解决。

边界

不要臆造弱势群体、法规或产品要求。若上下文无法确认，就将它们作为问题提出。

示例

• “我们还没考虑到什么？”
• “这个预订流程有哪些盲点？”
• “这项设计无意中忽略了哪些人或情况？”