user-grounding

用户依据

回答两个问题：这是为谁设计的？我们实际上对他们了解多少？

始终遵循

• 上下文 — 询问用户重复说明之前，先检查已有信息。如果产品目的或预期结果可能改变答案，请使用 .ux/INTENT.md，并且只加载任务所需的其他项目上下文。
• 用户 — 以受影响的人、他们的目标、任务、情境和现有证据为依据开展工作。不要臆造用户需求、行为或人物画像。
• 证据 — 在区分具有实际意义时，明确区分已知、推断、假设、未知和相互冲突的信息。
• 系统 — 优先沿用已有的产品语言、组件、模式和规则，而不是另创新的内容。
• 清晰 — 先说明有用的要点，只采用必要的结构，并删去泛泛的 AI 填充内容。
• 信任 — 绝不捏造证据、需求、理由、实施状态或合规情况。
• 结果 — 对于涉及多个步骤的重要工作，持续关注意图；只有在需要保持上下文连续时才维护简短的 .ux/STATE.md；先解决影响最大的未解决问题，再做润色；在宣布完成前，根据意图验证实际体验。

除非这些规则对答案有实质影响，否则不要向用户复述。

不要妨碍工作

不要把普通设计工作变成一场探索研究。

如果受影响的人、他们的任务和相关情境已经足够明确，可以据此做出决定，就直接开展工作。小型内容、布局、状态或组件调整，不会仅仅因为可以创建人物画像或研究计划，就需要这样做。

只有当对用户的认知存在不确定性，且这种不确定性可能实质改变问题、设计方向、优先级、风险或验证方法时，才深入探究。

提问前先检查证据

查找最精简且相关的一组现有资料，例如研究、访谈记录、可用性测试结果、分析数据、支持或销售证据、实地观察、既有决策、产品文档以及有意义的行为细分。

不要要求设计师总结 Agent 可以直接检查的研究资料。

适用时，区分：

• 观察到的 — 在研究或实际使用中直接看到的行为；
• 反馈的 — 人们在访谈、问卷、支持沟通或反馈中表达的内容；
• 行为证据 — 分析数据或其他产品使用证据；
• 假设的 — 团队当前相信但缺乏证据支持的内容；
• 未知的 — 可能影响设计但尚未明确的信息。

如果采用更简单的“已知 / 推断 / 假设 / 未知 / 冲突”区分已经足够，就使用现有 UX Skills 的证据术语。

只构建工作所需的用户认知

关注相关差异，例如：

• 参与者或用户群体；
• 他们想要实现的目标或完成的工作；
• 任务及其周边情境；
• 频率、熟悉程度、紧迫性、中断情况、环境或设备（仅在相关时考虑）；
• 会影响行为的角色、权限、无障碍需求、语言或领域专业知识；
• 需要采用不同设计行为的显著群体差异；
• 支持这些差异的证据。

除非人口统计信息与工作相关且有证据支持，否则不要加入这类细节。

将人物画像视为可选项

绝不要为了让工作显得完整而捏造姓名、人口统计信息、动机、引语或痛点。

只有当研究证实人们在行为、目标、情境或需求方面存在持久差异，且该材料有助于团队做出决策时，才使用人物画像。如果简短的用户群体说明、场景、旅程或行为差异列表已经足够，就采用这些形式。

如果现有人物画像缺乏依据，应说明哪些内容有记录，哪些只是假设，而不是把它们润色得仿佛可信。

仅在研究能减少实质性的不确定性时才建议开展研究

如果某个未知因素可能改变设计，就建议采用最精简、恰当的方式来获取足够的信息。可以查阅现有证据、检查分析或支持数据、观察任务、开展有针对性的访谈，或测试交互。

不要仅仅因为某种研究方法是传统的 UX 做法，就推荐它。应根据问题选择方法。

如果现有证据足以支持当前决策，就直接说明。更多研究并不总能带来更好的 UX。

输出

让结果与问题相称。通常应说明：

• 工作面向谁；
• 已知信息和假设；
• 一两个真正可能改变工作方向的未知因素；
• 仅在有必要时，说明最精简的下一步。

如果不需要开展额外的用户研究，就直接说明并继续。

对比示例

不佳：

在设计这项设置变更之前，我们先创建三个用户画像、绘制他们的旅程、找出痛点，并开展用户访谈，以便充分了解他们的需求。

良好：

这项设置变更面向的，是产品中已有文档记录的同一批已登录账户所有者，而且不会改变他们的任务或决策。我看不出有什么用户认知上的空白会影响这项变更。无需创建用户画像或开展新研究；继续进行设计系统和无障碍审查即可。

原因：良好的回应体现了以用户为中心的判断，却不会把 UX 流程变成简单工作的前置条件。

示例

• “我们实际是在为谁设计？”
• “我们对这些用户的了解足以支持这项决策吗？”
• “这些用户画像感觉是编出来的。它们有用吗？”
• “设计之前，我们实际需要做哪些研究？”
• “现有研究对重复预订的用户有哪些发现？”