layers-user-needs

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/layers-user-needs

Assumes
/layers-intro
has been loaded for framework context.

User needs are what we think users are trying to achieve, and why — an interpretation built on observed behaviour and domain knowledge, not a direct capture of reality. This layer sits between the messy raw material of observation and the deliberate decisions of the solution space.

In OST terms, the outputs here are opportunities: needs (what users want to achieve), pains (what's causing friction), and desires (improvements they'd value). All three are valid inputs; elicit all three.

Decisions this layer needs to make:

Who exactly are the users whose needs we're defining — and in what situation?
What jobs are they trying to do — functional, emotional, and social?
Which needs are grounded in evidence, and which are assumptions?
Which needs matter most, and why?

Methods:

Method	When
Job stories (JTBD)	Default. Situation → motivation → outcome. Keeps solutions out; forces specificity through the "When" clause.
User stories	Team prefers role-based framing, or integrating with an existing Agile workflow.
Top tasks analysis (Gerry McGovern)	Large existing user base. Identify which tasks matter most by frequency. Statistical, survey-based.
Persona + scenario	Communicating to stakeholders who think in archetypes. Good for alignment; less precise for design decisions.
ODI desired outcomes (Ulwick)	Precise, measurable statements. Format: "Minimize [metric] when [context]." Maps directly to opportunity scoring.

Default: job stories.

Three types of need — elicit all three:

Functional — the practical task. Feeds interaction structure and conceptual model directly.
Emotional — how the user wants to feel while doing the job. Feeds surface (tone, copy, feedback).
Social — how the user wants to be perceived by others in this context. Also feeds surface; sometimes strategy.

Emotional and social needs are chronically under-articulated in briefs and research reports, even when they're genuinely shaping behaviour. Asking for them explicitly is usually what surfaces them.

Quality signals — what good looks like:

The "When" clause is specific enough to picture the moment it happens
The motivation is a genuine goal, not a solution sneaking in
Functional, emotional, and social dimensions all explored
Confidence marked: observed / inferred / assumed
Workarounds surfaced — a need real enough to motivate improvisation is a strong signal

假设已加载
/layers-intro
以获取框架背景信息。

用户需求是我们认为用户试图达成的目标及其背后的原因——这是基于观察到的行为和领域知识做出的解读，而非对现实的直接捕捉。该层处于杂乱的观察原始素材与解决方案领域的审慎决策之间。

在OST术语中，此层的输出是机会点：需求（用户想要达成的目标）、痛点（造成摩擦的因素）和期望（用户重视的改进方向）。这三类都是有效的输入，需全面挖掘。

该层需要做出的决策：

我们定义的需求究竟属于哪类用户——以及他们处于何种场景？
他们试图完成哪些工作——功能性、情感性和社会性的？
哪些需求有证据支撑，哪些只是假设？
哪些需求最为重要，原因是什么？

方法：

方法	适用场景
Job stories（JTBD）	默认方法。场景→动机→结果。排除解决方案干扰；通过“When”条款确保描述的具体性。
User stories	团队偏好基于角色的框架，或需要与现有Agile工作流集成时。
Top tasks analysis（Gerry McGovern）	用户群体规模较大时。通过统计和调研识别高频核心任务。
Persona + scenario	向习惯以原型视角思考的利益相关者沟通时。有助于达成共识，但对设计决策的精准度较低。
ODI desired outcomes（Ulwick）	精准、可衡量的陈述。格式：“在[场景]下，最小化[指标]。”可直接映射到机会点评分。

默认方法：Job stories。

三类需求——需全面挖掘：

功能性需求——实际任务需求。直接为交互结构和概念模型提供依据。
情感性需求——用户在完成工作时希望拥有的感受。为界面表现（语气、文案、反馈）提供依据。
社会性需求——用户在此场景下希望给他人留下的印象。同样为界面表现提供依据，有时也会影响战略方向。

情感和社会性需求在简报和研究报告中常常表述不足，即便它们确实在影响用户行为。明确询问这类需求通常能将其挖掘出来。

质量判断标准——优质需求的特征：

“When”条款足够具体，能让人清晰想象出场景发生的瞬间
动机是真实的目标，而非隐藏的解决方案
全面涵盖功能性、情感性和社会性维度
标注可信度：观察所得/推断/假设
挖掘出用户的权宜之计——足以促使用户自行变通的需求是强烈的信号

Guided session

引导式会话

Tell me who your users are and what you're working on, or say "guide me" to start a structured session.

Ask: "Where should I capture the work from this session?" (see

/layers-intro

for options)

Ask: "What's the source of the user needs we're working with — user research, domain knowledge, team assumptions, or a mix?" If working from assumptions, mark them clearly throughout and plan to validate.

Phase 1 — Frame the users

Who are the users whose needs we're defining? Be specific — not "users" but which type, in which situation.
What context are they in when the relevant need arises?
Is there more than one distinct user type with meaningfully different needs? Work through them separately.

Phase 2 — Elicit needs

Work through the needs the designer raises. Format: When [situation], I want to [motivation], so I can [expected outcome].

The "When" clause is the most important part — it must be specific enough to picture the moment. Push until it is.

For each need, ask: "Is there a functional job here, an emotional job, a social job — or all three?"

Probe each:

On "When": "Could you picture the moment this happens? Is this triggered by an event, a feeling, a rhythm, or a threshold being crossed?"
On motivation: "Is a solution sneaking in? Why does this matter to them? What's at stake if unmet?"
On expected outcome: "What does success look like for the user — not the product?"

Phase 3 — Surface hidden needs

"What needs do users have that the product currently ignores?"
"What do users do before and after the moment we normally focus on?"
"What do users have to do that they really wish they didn't?"
"What need are users currently meeting with a workaround — a spreadsheet, an email — that a product could serve better?"

Phase 4 — Challenge and filter

Review all needs together. For each:

Need or solution? "When I need a report, I want to export to CSV" is a solution. Push to the underlying need.
Specific enough to design from? A need so broad that any feature could serve it is not useful.
Grounded? Mark: observed / inferred / assumed.
Important? How frequently does this situation arise? How painful is it unmet?

Phase 5 — Prioritise

Rough ordering: highest importance × most poorly currently served. A need that matters a lot and is badly served is a high-value opportunity. A need that matters a lot but is already well served is not.

Don't over-engineer this. Precise prioritisation is strategy work at

/layers-product-strategy

. A rough ranking is enough here.

告诉我你的用户是谁，以及你正在开展的工作，或者说“引导我”来启动结构化会话。

提问：“我应该在哪里记录本次会话的成果？”（可查看

/layers-intro

获取可选方案）

提问：*“我们当前处理的用户需求来源是什么——用户研究、领域知识、团队假设，还是混合来源？”*如果基于假设开展工作，需全程清晰标注，并规划后续验证环节。

第一阶段——明确用户范围

我们定义的需求属于哪类用户？需具体描述——不是泛指“用户”，而是明确哪类用户、处于何种场景。
相关需求出现时，用户处于何种环境？
是否存在多类需求差异显著的用户群体？需分别梳理。

第二阶段——挖掘需求

梳理设计师提出的需求。格式：当[场景]时，我想要[动机]，以便[预期结果]。

“When”条款是最重要的部分——必须足够具体，能让人想象出场景瞬间。需不断细化直至达标。

针对每个需求，提问：“这里包含功能性工作、情感性工作、社会性工作——还是三者兼具？”

逐一深入探究：

关于“When”：“你能想象出这个场景发生的瞬间吗？它是由事件、感受、规律还是某个阈值触发的？”
关于动机：“是否隐藏了解决方案？这对用户来说为什么重要？如果需求未被满足，会有什么影响？”
关于预期结果：“对用户而言，成功是什么样的——而非对产品而言？”

第三阶段——挖掘潜在需求

“用户有哪些需求是当前产品未满足的？”
“在我们通常关注的场景前后，用户会做什么？”
“用户不得不做哪些他们非常不想做的事？”
“用户当前通过权宜之计（如电子表格、邮件）满足的哪些需求，产品可以更好地提供服务？”

第四阶段——验证与筛选

共同回顾所有需求。针对每个需求：

是需求还是解决方案？“当我需要报告时，我想导出为CSV”是解决方案。需挖掘背后的核心需求。
**是否具体到可用于设计？**过于宽泛、任何功能都能满足的需求毫无用处。
**是否有依据？**标注：观察所得/推断/假设。
**是否重要？**该场景出现的频率如何？需求未被满足时的痛苦程度如何？

第五阶段——优先级排序

大致排序规则：重要性×当前满足程度的反向值。非常重要且当前满足度极低的需求是高价值机会点。非常重要但已被很好满足的需求则不是。

无需过度复杂化。精准的优先级排序属于

/layers-product-strategy

的战略工作范畴。此处只需大致排名即可。

Completion

交付成果

Produce:

User needs — final list, priority order, with confidence ratings (observed / inferred / assumed)
Unprioritised needs — surfaced but not ranked, so they aren't lost
Gaps — needs probably real but not yet grounded; research questions to answer
Contradictions — if different user types have conflicting needs, name them explicitly

Close with: "These needs are the opportunities for your product strategy. Run
/layers-product-strategy
to build a strategy tree connecting them to business outcomes and solution bets."

If needs are mostly assumed: "Several of these are marked as assumed. Before building strategy on them, consider running
/layers-observed-behaviour
to gather evidence."

产出：

用户需求列表——最终排序后的列表，附带可信度评分（观察所得/推断/假设）
未排序需求列表——已挖掘但未排名的需求，避免遗漏
缺口——可能真实存在但尚未找到依据的需求；需通过研究解答的问题
矛盾点——若不同用户群体的需求存在冲突，需明确指出

收尾提示：“这些需求是产品战略的机会点。运行
/layers-product-strategy
来构建战略树，将需求与业务成果和解决方案关联起来。”

若多数需求为假设：“其中多项需求标注为假设。在基于这些需求制定战略之前，建议运行
/layers-observed-behaviour
来收集证据。”