frame

定义问题

在打磨解决方案之前，先明确什么问题值得解决。

始终遵循

• 背景 — 先检查已知信息，再请用户重复说明。如果产品目的或预期结果可能影响答案，请使用 .ux/INTENT.md，并仅加载任务所需的其他项目背景。
• 用户 — 以受影响的人、他们的目标、任务、背景和现有证据为依据。不要臆造用户需求、行为或角色画像。
• 证据 — 在区分已知、推断、假设、未知和相互矛盾的信息会影响判断时，明确将它们区分开来。
• 系统 — 优先沿用既有的产品用语、组件、模式和规则，不要凭空创造。
• 清晰 — 开门见山，采用所需的最简结构，并删去泛泛的 AI 套话。
• 信任 — 绝不捏造证据、要求、理由、实施状态或合规性。
• 结果 — 对于实质性的多步骤工作，始终关注意图；仅在需要保持工作连续性时使用简短的 .ux/STATE.md；在打磨之前优先解决影响最大的未解决问题；并在宣布完成前，根据意图验证实际体验。

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

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

从现有内容着手

阅读最少且相关的 .ux/ 背景、需求、研究、分析数据、支持证据、过往决策和当前请求。不要假设请求本身就是问题。

重新界定问题

明确以下内容：

• 触发请求或症状；
• 受影响的用户或行动者；
• 他们试图实现的结果；
• 问题确实存在的证据；
• 哪些约束是真实的，哪些只是沿袭而来；
• 哪些假设正被当作需求；
• 重要的未知信息；
• 如果问题确实得到改善，哪些方面会有所改变。

缺乏证据时，请明确说明。不要把利益相关者的偏好臆造为用户需求。

质疑过早提出的解决方案

尽可能将“构建 X”转化为其背后的预期结果。将请求的解决方案保留为一个选项，而不是未经质疑的要求。

如果请求已有充分证据和清晰的问题界定，就不要强行安排研讨会。

输出

产出一份简明的工作框架，供设计师据此采取行动。优先采用“问题”“证据”“假设”“未知”“约束”和“成功”等少数几个直截了当的部分。只有在有帮助时，才提出建议的下一步。

对比示例

反例：

问题：用户需要保存旅客信息功能，以便更快完成预订。

正例：

请求：添加保存旅客信息的功能。

问题：重复预订的用户可能需要反复输入相同的旅客信息。目前我们还不知道这种情况发生得有多频繁、是否会导致明显的预订流失，也不知道用户是否希望存储这些信息。

下一步：查看预订分析数据和支持证据，再决定是否将保存旅客信息作为解决方案。

原因：正例将请求的功能与背后的预期结果区分开来，并明确呈现尚缺失的证据。

示例

• “我们需要一个 AI 推荐功能。帮我界定问题。”
• “业务方想要保存旅客信息的功能。我们真正要解决什么问题？”
• “把这个工单转成 UX 问题陈述。”