Back to Details

user-grounding

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

User Grounding

用户锚定

Answer two questions: who is this for, and what do we actually know about them?
回答两个问题：这是为谁设计的？我们对他们实际了解多少？

Always

必须遵循的原则

  • Context — inspect what is already known before asking the user to repeat it. Use 
    .ux/INTENT.md
    when product purpose or outcome can change the answer, and load only the additional project context the task needs.
  • User — ground the work in the people affected, their goal, task, context, and available evidence. Do not invent user needs, behaviors, or personas.
  • Evidence — keep known, inferred, assumed, unknown, and conflicted information distinct when the difference matters.
  • System — prefer established product language, components, patterns, and rules before inventing new ones.
  • Clear — lead with the useful point, use the minimum structure needed, and remove generic AI filler.
  • Trust — never invent evidence, requirements, rationale, implementation status, or compliance.
  • Outcome — for substantial multi-step work, keep intent active, use a small 
    .ux/STATE.md
    only when continuity needs it, prioritize the highest-impact unresolved gap before polishing, and verify the actual experience against intent before declaring completion.
Do not recite these rules to the user unless one of them materially affects the answer.
Do not introduce research questions, personas, or discovery work when the user and task are already clear or the missing information would not materially change the work.
  • 背景信息 — 在要求用户重复信息前，先核查已有的已知内容。当产品目标或结果会影响答案时，使用
    .ux/INTENT.md
    ，仅加载任务所需的额外项目背景信息。
  • 用户导向 — 让工作基于受影响的用户群体、他们的目标、任务、使用场景以及可用证据展开。不得凭空捏造用户需求、行为或personas。
  • 证据区分 — 当差异至关重要时，需明确区分已知信息、推断信息、假设信息、未知信息以及存在冲突的信息。
  • 系统复用 — 优先使用已确立的产品语言、组件、模式和规则，而非创造新内容。
  • 简洁清晰 — 直接给出有用信息，使用最少必要的结构，删除通用AI生成的冗余内容。
  • 诚信可靠 — 不得捏造证据、需求、理由、实施状态或合规相关内容。
  • 结果导向 — 对于复杂的多步骤工作，保持目标明确；仅当需要维持工作连续性时，使用小型的
    .ux/STATE.md
    文件；在优化细节前，优先处理影响最大的未解决差距；在宣布完成前，验证实际体验是否符合预期目标。
除非这些原则会对答案产生实质性影响，否则不要向用户罗列这些规则。
当用户群体和任务已明确，或缺失的信息不会对工作产生实质性改变时，不要引入研究问题、personas或探索性工作。

Stay out of the way

避免过度干预

Do not turn ordinary design work into a discovery exercise.
If the people affected, their task, and the relevant context are already clear enough to make the decision, proceed with the work. A small content, layout, state, or component change does not need a persona or research plan merely because one could be created.
Only dig deeper when uncertainty about the user could materially change the problem, design direction, priority, risk, or validation approach.
不要将常规设计工作转化为探索性任务。
若受影响的用户群体、他们的任务以及相关背景信息已足够明确，可支撑决策，则直接推进工作。仅因可以创建personas或研究计划，就对小型的内容、布局、状态或组件变更要求这些内容是不必要的。
只有当对用户的不确定性可能会实质性改变问题、设计方向、优先级、风险或验证方法时，才需要深入挖掘。

Inspect evidence before asking

先核查现有证据再提问

Look for the smallest relevant set of existing research, interview notes, usability findings, analytics, support or sales evidence, field observations, prior decisions, product documentation, and meaningful behavioral segments.
Do not ask the designer to summarize research the agent can inspect directly.
When useful, distinguish:
  • Observed — behavior seen directly in research or use;
  • Reported — what people said in interviews, surveys, support, or feedback;
  • Behavioral evidence — analytics or other product-use evidence;
  • Assumed — what the team currently believes without supporting evidence;
  • Unknown — information that could change the design but is not established.
Use the existing UX Skills evidence language when a simpler Known / Inferred / Assumed / Unknown / Conflict distinction is sufficient.
查找最相关的最小范围现有研究资料，包括访谈记录、可用性测试结果、分析数据、客服或销售反馈、实地观察记录、过往决策、产品文档以及有意义的行为细分数据。
不要要求设计师总结Agent可直接查阅的研究内容。
必要时，区分以下类型：
  • 观察到的 — 在研究或实际使用中直接看到的行为；
  • 用户自述的 — 用户在访谈、调研、客服沟通或反馈中提到的内容；
  • 行为证据 — 分析数据或其他产品使用相关证据；
  • 假设的 — 团队当前持有的无证据支撑的观点；
  • 未知的 — 可能会改变设计但尚未明确的信息。
如果简单的“已知/推断/假设/未知/冲突”区分足够，可使用现有的UX Skills证据分类方式。

Build only the user picture the work needs

仅构建工作所需的用户画像

Focus on relevant differences, such as:
  • the actor or user group;
  • the goal or job they are trying to accomplish;
  • the task and surrounding context;
  • frequency, familiarity, urgency, interruption, environment, or device when they matter;
  • roles, permissions, accessibility needs, language, or domain expertise when they affect behavior;
  • meaningful differences between groups that require different design behavior;
  • evidence supporting those differences.
Do not add demographic detail unless it is relevant and evidenced.
聚焦于相关差异，例如：
  • 参与者或用户群体；
  • 他们试图达成的目标或工作任务；
  • 具体任务及周边场景；
  • 频率、熟悉度、紧迫性、干扰因素、环境或设备（当这些因素产生影响时）；
  • 角色、权限、无障碍需求、语言或领域专业知识（当这些因素影响行为时）；
  • 群体间的显著差异，这些差异需要不同的设计方案；
  • 支撑这些差异的证据。
除非相关且有证据支撑，否则不要添加人口统计细节。

Treat personas as optional

将personas视为可选工具

Never fabricate named personas, demographics, motivations, quotes, or pain points to make the work feel complete.
Use personas only when research supports durable differences in behavior, goals, context, or needs and the artifact would help the team make decisions. If a short user-group description, scenario, journey, or list of behavioral differences is enough, use that instead.
If existing personas are unsupported, say what is documented versus assumed rather than polishing them into credibility.
切勿编造命名personas、人口统计信息、动机、引用或痛点来让工作看起来更完整。
仅当研究证实用户在行为、目标、场景或需求上存在持久差异，且该工具能帮助团队做出决策时，才使用personas。若简短的用户群体描述、场景、用户旅程或行为差异列表已足够，则优先使用这些内容。
若现有personas无证据支撑，需说明文档记录内容与假设内容的区别，而非刻意包装使其看起来可信。

Recommend research only when it reduces meaningful uncertainty

仅当能减少重大不确定性时才推荐研究

If an unknown could change the design, recommend the smallest appropriate way to learn enough. That might be reviewing existing evidence, inspecting analytics or support data, observing the task, conducting focused interviews, or testing the interaction.
Do not prescribe a research method because it is traditional UX practice. Match the method to the question.
If the available evidence is sufficient for the current decision, say so. More research is not automatically better UX.
若未知信息可能改变设计，推荐采用最恰当的最小规模方法来获取足够信息。这可能包括查阅现有证据、分析数据或客服信息、观察任务执行过程、开展针对性访谈或测试交互效果。
不要因遵循传统UX惯例而指定研究方法。需让方法匹配具体问题。
若现有证据已足够支撑当前决策，直接说明这一点。并非研究越多就代表UX工作越好。

Output

输出要求

Keep the result proportional to the question. Usually provide:
  • who the work is for;
  • what is known and what is assumed;
  • the one or two unknowns that could actually change the work;
  • the smallest next move, only if one is needed.
If no additional user work is needed, say that directly and continue.
确保结果与问题的规模相匹配。通常需提供：
  • 工作的目标用户；
  • 已知信息与假设信息；
  • 一两个可能会实质性改变工作的未知信息；
  • 仅在必要时提供最小化的下一步行动建议。
若无需额外的用户相关工作，直接说明并继续推进。

Contrast example

对比示例

Bad:
Before designing this settings change, let's create three personas, map their journeys, identify pain points, and run user interviews so we can fully understand their needs.
Good:
The settings change applies to the same signed-in account owners already documented in this product, and it does not change their task or decision. I don't see a user-knowledge gap that would affect this change. No persona or new research is needed; proceed with the design-system and accessibility review.
Why: the good response uses user-centered judgment without making UX process the price of doing simple work.
反面示例：
在设计此设置变更前，我们先创建三个personas，绘制他们的用户旅程，识别痛点，并开展用户访谈，以便充分了解他们的需求。
正面示例：
此设置变更适用于产品中已记录的同一批登录账户所有者，且不会改变他们的任务或决策逻辑。我未发现会影响此变更的用户认知缺口。无需使用personas或开展新研究；直接推进设计系统与无障碍性审查即可。
原因：正面示例采用了以用户为中心的判断方式，未将UX流程作为完成简单工作的门槛。

Examples

适用场景示例

  • "Who are we actually designing this for?"
  • "Do we know enough about these users to make this decision?"
  • "These personas feel made up. Are they useful?"
  • "What research do we actually need before designing this?"
  • "What does our existing research say about repeat bookers?"
  • “我们实际上是在为谁设计这个？”
  • “我们对这些用户的了解是否足以做出这个决策？”
  • “这些personas看起来像是编造的。它们有用吗？”
  • “在设计这个之前，我们实际需要开展哪些研究？”
  • “我们现有研究关于重复预订用户的结论是什么？”