梳理用户使用场景，先确定一个具体角色在什么触发条件下要完成什么目标，再把达成目标的动作按顺序拆成任务流程，记录每一步的输入、动作、输出和卡点，最后用统一字段写成可评审的场景描述。一份可用的场景描述至少包含角色、目标、触发条件、任务流程四个核心字段，并补充前置条件、环境、异常分支和完成标志。本文给出字段结构、梳理步骤、分工方式、完整示例和检查清单，帮助你把模糊的用户需求整理成团队可以复现和评审的文档。
要点总览（TL;DR）
- 一份可用的场景描述至少包含角色、目标、触发条件、任务流程四个核心字段，再按复杂度补充前置条件、环境与设备、异常分支和完成标志。
- 梳理顺序从选定具体角色开始，把模糊需求转成可观察的目标，再从事件、时间、状态变化中识别触发条件，最后按动作顺序拆分任务流程。
- 任务流程的粒度以“一个动作对应一个可观察的操作或决策”为宜，每一步写清输入、动作和输出，异常分支优先覆盖高频和阻断性情况。
- 用户研究人员提供访谈与观察素材，产品经理归纳场景并组织撰写，设计与研发评审流程可行性，素材要能追溯到原始记录。
- 判断场景描述是否合格，最有效的检验是请未参与梳理的同事只读文档复述角色、目标、流程和卡点，复述偏差通常指向字段过虚或流程跳步。
一份可用的场景描述包含哪些字段
场景描述的价值在于让没有参与访谈的人也能读懂“谁在什么情况下要做什么、做到什么程度算完成”。字段固定下来，不同人写出的场景才能横向比较，也才能在评审时逐项核对。下表给出建议的字段结构，前四项为核心字段，缺一项场景就不完整；后四项为补充字段，按场景复杂度取舍。
| 字段名 | 定义 | 填写要点 | 示例值 |
|---|---|---|---|
| 角色 | 执行该场景的具体用户身份 | 写到岗位、职责或使用身份，避免“用户”“员工”这类过宽表述 | 需要每月提交差旅报销的一线销售 |
| 目标 | 角色希望通过该场景达成的结果 | 用可观察的结果描述，能判断是否达成 | 在报销截止日前完成本月差旅费用提交并进入审批 |
| 触发条件 | 促使角色开始执行场景的事件、时间或状态变化 | 写明具体事件或状态，避免“有需要时” | 出差结束返回公司后，收到财务的月度报销提醒 |
| 任务流程 | 角色达成目标所经历的动作序列 | 按动作顺序拆分，每步写清输入、动作、输出 | 整理票据→填写报销单→上传凭证→提交审批 |
| 前置条件 | 场景开始前必须已具备的条件 | 区分“必须有”和“通常有”，缺失会导致流程中断的写进必须有 | 已开通报销系统账号，差旅申请已审批通过 |
| 环境与设备 | 角色执行场景时所处的物理与工具环境 | 写明设备、网络、场所等影响操作方式的条件 | 办公室电脑端为主，出差途中用手机补拍票据 |
| 异常分支 | 正常流程之外可能出现的偏离路径 | 列出高频异常及角色的应对动作 | 票据缺失时先提交说明，后续补传 |
| 完成标志 | 判断场景成功结束的可观察信号 | 写成系统状态或业务结果，避免“感觉完成了” | 报销单状态变为“审批中”，且收到提交成功通知 |
填写时有两个常见口径问题。角色字段容易写成人群标签，例如“年轻用户”，这类描述无法指导流程设计，应改为带有具体任务身份的角色。目标字段容易写成愿望，例如“提升报销体验”，应改为角色要达成的业务结果。触发条件则要落到可识别的事件或状态，时间驱动、事件驱动、状态变化驱动三类来源都可以，关键是写明具体是什么。
从角色和目标出发梳理场景的步骤
梳理顺序建议从角色开始，逐步收敛到流程，每一步都有明确的输入和产出，避免一开始就陷入功能细节。以下五步可以按序执行，也可以在第4步发现角色或目标不成立时回到前面修正。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 选定角色 | 访谈记录、观察笔记、客服工单 | 按任务身份归类用户，选出一个在目标场景中承担主要动作的角色 | 一句话角色定义 | 角色能对应到具体岗位或使用身份，且不与其他角色混用 |
| 2. 明确目标 | 角色定义、用户原话 | 把模糊需求转写为角色要达成的结果，确认该结果可观察 | 一条可判断是否达成的目标陈述 | 能用“是否达成”回答，且不依赖主观感受 |
| 3. 识别触发条件 | 角色工作节奏、系统状态、业务规则 | 从事件、时间、状态变化三类来源中找出场景启动的信号 | 一条或一组触发条件 | 触发条件具体到事件或状态，他人可据此判断场景何时开始 |
| 4. 拆分任务流程 | 目标、触发条件、实际操作观察 | 按动作顺序拆分步骤，每步记录输入、动作、输出 | 编号的任务流程 | 流程从触发条件开始，到完成标志结束，中间无跳步 |
| 5. 补充异常与替代路径 | 任务流程、访谈中的失败经历 | 列出高频异常、角色应对动作和替代路径 | 异常分支清单 | 关键异常均有对应处理动作，且标明对完成标志的影响 |
角色过宽是第一步最常见的偏差。判断标准是：如果两个用户在同一场景中的动作序列明显不同，就应拆成两个角色分别描述。例如“提交报销的人”和“审批报销的人”动作完全不同，混在一个角色里会让流程描述失去指导意义。
任务流程的粒度控制以“一个动作对应一个可观察的操作或决策”为宜。拆得过粗，例如只写“完成报销”，无法暴露卡点；拆得过细，例如把每次点击都列出来，文档会失去可读性。一个实用的判断方法是：每一步都应该能回答“这一步的输入从哪来、产出交给谁”。如果某一步说不清输出，通常说明粒度或边界有问题。
异常分支不必穷举，优先补充访谈和观察中出现频率高、或一旦发生就会阻断流程的情况。每条异常写清触发情形、角色应对动作，以及处理后流程回到哪一步。
角色与交付物如何分工
场景梳理通常由多人协作完成，职责不清会导致访谈素材无人整理、场景无人收敛、流程可行性无人把关。下表按角色列出动作、交付物和交接时点，团队规模较小时可以由一人兼任多个角色，但交付物仍应分开留存。
| 角色 | 主要动作 | 交付物 | 交接时点 |
|---|---|---|---|
| 用户研究人员 | 开展访谈与现场观察，记录用户原话、操作过程和失败经历，整理素材 | 访谈记录、观察笔记、用户原话摘录 | 在场景归纳开始前交付，供产品经理选用 |
| 产品经理 | 基于素材归纳角色与场景，判断场景优先级，组织场景描述撰写 | 角色清单、场景描述初稿、优先级说明 | 在流程评审前交付初稿 |
| 设计师 | 评审任务流程的完整性与操作可行性，指出流程中的交互断点 | 流程评审意见、交互问题清单 | 在场景描述定稿前参与评审 |
| 研发人员 | 评审流程在现有系统条件下的可行性，识别数据与状态依赖 | 技术可行性意见、依赖说明 | 与设计评审同步或紧随其后 |
交接的关键是素材可追溯。产品经理归纳出的每条角色和目标，应能指回具体的访谈记录或观察笔记，这样评审时出现分歧可以回到原始素材核对，而不是停留在观点争论。设计与研发的评审意见应记录在场景文档的评审区，明确哪些意见已采纳、哪些留待后续需求阶段处理。
场景描述示例：一次报销提交的完整写法
以下为演示情景，用于说明字段如何填满，不对应任何真实客户案例。
角色：需要每月提交差旅报销的一线销售。该角色常年在外拜访客户，差旅频次高，票据来源分散。
目标：在财务规定的报销截止日前，完成本月全部差旅费用的提交，使报销单进入审批状态。
触发条件：出差结束返回公司后收到财务的月度报销提醒；或角色在整理票据时发现本月费用尚未提交。
前置条件：已开通报销系统账号；对应差旅申请已审批通过；银行卡信息已维护。缺少差旅申请审批时，流程在提交环节会被拦截。
环境与设备：以办公室电脑端填写为主；出差途中用手机拍摄并暂存票据照片。
任务流程：
- 整理票据。输入：本月差旅产生的发票、行程单；动作：按出差批次归集票据，核对金额与日期；输出：按批次分组的票据清单。
- 填写报销单。输入：票据清单、差旅申请单号；动作：在系统中新建报销单，选择对应差旅申请，逐项填写费用类型与金额；输出：草稿状态的报销单。
- 上传凭证。输入：票据照片或电子发票；动作：按费用项上传凭证，核对影像清晰度；输出：凭证与费用项一一对应的报销单。
- 提交审批。输入：填写完成的报销单；动作：检查必填项后提交，选择审批流；输出：状态为“审批中”的报销单。
异常分支：票据缺失时，角色先提交报销单并在备注中说明，后续补传凭证，流程回到第3步；差旅申请未审批通过时，角色需先联系主管完成申请审批，再回到第2步；金额超出标准时，系统提示后角色需填写超标说明，否则无法提交。
完成标志：报销单状态变为“审批中”，角色收到提交成功通知，且凭证齐全无待补项。
这份示例可以直接改写为其他场景：替换角色与目标，保留字段结构；任务流程按实际动作顺序调整；异常分支从访谈中的失败经历提取。改写时注意每步都保留输入和输出，这是后续做流程优化和系统设计时最有用的信息。
场景文档的评审与完成检查
场景描述写完不等于可用，需要按统一标准逐项核对。下表可作为评审时的检查清单，每项给出通过标准和负责人，未通过的项回到对应步骤修改。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 角色是否单一且具体 | 角色对应具体岗位或使用身份，同一场景中不混入动作序列明显不同的其他角色 | 产品经理 |
| 目标是否可观察 | 目标写成业务结果，能用“是否达成”判断，不依赖主观感受 | 产品经理 |
| 触发条件是否明确 | 触发条件落到具体事件、时间或状态变化，他人可据此判断场景起点 | 产品经理 |
| 任务流程是否完整 | 流程从触发条件开始到完成标志结束，每步有输入、动作、输出，无跳步 | 产品经理、设计师 |
| 异常分支是否覆盖关键情况 | 高频异常和阻断性异常均有应对动作，并标明流程回到哪一步 | 产品经理、研发人员 |
| 字段是否齐全 | 四个核心字段完整，补充字段按场景复杂度取舍并有取舍说明 | 评审参与人 |
| 表述是否可复现 | 未参与访谈的团队成员能按文档复述场景，并指出流程中的关键卡点 | 评审参与人 |
最后一项“可复现”是最有效的整体检验。请一位没有参与梳理的同事只读文档，复述角色、目标、流程和主要卡点；如果复述出现明显偏差，通常说明某个字段写得过虚或流程存在跳步。评审意见应逐条记录处理结论，修改后的版本保留变更说明，便于后续需求阶段追溯场景的演变。
把场景文档接入日常协作流程
场景描述定稿后，需要作为需求输入进入后续环节，否则容易停留在研究文档里无人使用。常见的流转方式是：场景文档作为需求评审的输入材料，产品经理据此提出需求项，设计与研发在需求评审中引用对应场景说明设计依据；评审意见记录在文档中，修改后更新版本；每个需求项和设计任务关联到来源场景，便于回溯“这个需求服务于哪个角色和哪条流程”。
在ONES中，这类流转可以借助文档与工作项的关联来承载：场景描述作为文档沉淀字段与流程，评审意见和版本更新记录在文档内；由场景引出的需求、设计任务作为工作项与文档关联，评审结论和状态变化在工作项上体现。这样场景文档、需求项和设计任务保持同一条链路，后续调整场景时能快速定位受影响的需求。具体操作路径以团队实际使用的ONES版本和配置为准。
维护上建议约定两个习惯：场景文档随需求变更同步更新，避免文档与实现脱节；每次评审后记录版本说明，标明修改了哪个字段、依据是什么。场景数量增多后，可按角色或业务域建立索引，方便新成员从场景入手理解产品要解决的问题。
常见问题
访谈素材很多，应该先梳理哪个场景？
建议按“角色在业务中的动作频次”和“流程受阻后的影响”两个维度排序，先梳理高频且卡点明确的场景。频次高意味着流程问题影响面大，卡点明确意味着梳理后容易转化为需求。一次只推进一个角色的一条主流程，写完再扩展，避免多个场景并行导致字段口径不一致。
同一个用户在不同情况下动作不一样，要拆成几个场景？
判断依据是动作序列是否明显不同。如果触发条件不同、目标不同、步骤顺序也不同，就应拆成独立场景分别描述；如果只是同一流程中的分支，例如票据缺失后的补传，则作为异常分支写在同一场景内。拆分的目的是让每份文档都能指导一条清晰的流程，而不是按用户人数切分。
场景描述写到什么程度可以进入需求评审？
达到两个条件即可：四个核心字段完整，且未参与梳理的同事能按文档复述角色、目标、流程和主要卡点。补充字段可以按场景复杂度取舍，但取舍要有说明。异常分支不必穷举，高频异常和一旦发生就阻断流程的情况必须覆盖。满足这些条件后，场景文档就可以作为需求评审的输入材料。
场景文档定稿后，需求发生变化怎么维护？
建议把场景文档与由它引出的需求项、设计任务建立关联，需求调整时同步回看对应场景是否需要更新。每次评审后记录版本说明，标明修改了哪个字段、依据是什么。场景数量增多后可按角色或业务域建立索引，方便新成员从场景入手理解产品要解决的问题。在ONES中，这类关联可以借助文档与工作项的关联来承载，具体操作路径以团队实际使用的版本和配置为准。
团队规模小，没有专职用户研究人员怎么办？
可以由产品经理兼任访谈与素材整理，但交付物仍建议分开留存：访谈记录和观察笔记作为原始素材单独归档，场景描述作为归纳产物另行成文。这样评审出现分歧时可以回到原始素材核对，而不是停留在观点争论。设计与研发的评审环节同样保留，流程可行性和技术依赖需要有人把关。
