写用户使用场景时，角色、目标、触发条件和任务流程是四项基本内容。角色决定从谁的视角看问题，目标决定流程在哪里结束，触发条件决定场景从哪里开始，任务流程把三者串成一段可验证的连续过程。缺少任何一项，场景描述就容易退化成功能清单或用户画像。下面按要素、写法、拆解方法和完整示例逐项说明。
要点总览（TL;DR）
- 一份可用的用户使用场景至少写清四项：角色、触发条件、目标、任务流程；输入产出与异常处理作为流程补充。
- 场景角色要写到“这一步谁负责、谁确认”，与用户画像区分：画像描述人群特征，角色承担具体动作和判断。
- 目标写成可观察的完成状态，触发条件写清事件、时间或状态变化，两者共同界定场景的起点和终点。
- 任务流程按角色动作拆步骤，每步写清输入、动作、产出，在交接点标注上下游与确认方式，并为每步补异常回退分支。
- 常见偏差包括把功能列表当场景、只写主流程、角色写成抽象群体、目标写成主观感受，可用“读给同事听能否说出起止”自查。
用户使用场景由哪几个要素构成
一份可用的场景描述，至少要回答四个问题：谁在什么情况下进入场景、他想达成什么结果、他从哪一步走到哪一步、每一步的输入和产出是什么。前三个问题分别对应角色、触发条件和目标，第四个问题对应任务流程。四项要素齐全，场景才具备被评审、被拆成需求、被验证的条件。
| 要素 | 一句话定义 | 在场景中的作用 |
|---|---|---|
| 角色 | 在该流程中承担具体动作和判断的人或系统 | 决定视角：场景从谁的需求出发，谁对结果负责 |
| 触发条件 | 让角色进入该场景的事件、时间点或状态变化 | 决定起点：界定场景从哪一刻开始 |
| 目标 | 角色希望达成的、可观察的完成状态 | 决定终点：流程走到什么程度算完成 |
| 任务流程 | 角色从触发到目标之间经过的连续步骤 | 串联三者：把起点、动作和终点连成可验证的过程 |
| 输入与产出 | 每一步开始前需要的信息、结束后留下的结果 | 补充流程：让步骤可交接、可检查 |
| 异常处理 | 步骤无法按主流程推进时的分支与回退方式 | 补充流程：让场景覆盖真实发生的偏差 |
这些要素之间存在依赖关系。角色换了，目标往往随之变化；触发条件变了，流程的第一步也会不同；目标写得含糊，流程就没有明确的结束标志。因此梳理场景时，建议先定角色和触发条件，再写目标，最后拆流程，顺序反过来容易写成功能罗列。
角色怎么写：从用户画像到场景内角色
用户画像描述一类人的背景特征，例如岗位、经验、使用频率；场景角色描述的是在这条流程里做具体动作、做具体判断的那个人或系统。画像回答“这类人是谁”，场景角色回答“这一步谁来做、谁确认、谁承担结果”。把画像直接搬进场景，常见结果是写了一个群体，却找不到每一步的责任人。
一个场景通常写一个主要角色，再写若干协作角色。主要角色是场景目标的直接受益者，也是流程的起点；协作角色在交接点上出现，提供输入、做审批或接收产出。角色数量以流程实际涉及的交接为准，不必为了完整而罗列所有相关部门。
| 字段 | 写什么 | 示例（演示情景） |
|---|---|---|
| 身份 | 角色在组织中的位置或系统身份 | 提交报销的员工 |
| 职责 | 在该场景中承担的动作和判断 | 填写报销单、上传凭证、回应退回意见 |
| 权限 | 能查看、修改或审批的范围 | 只能编辑本人单据，提交后不可修改金额 |
| 关注结果 | 该角色判断场景是否完成的标准 | 报销款到账、单据状态显示已打款 |
角色描述写到“能判断这一步由谁负责”即可。如果某个角色在流程中只出现一次且不承担判断，可以合并进相邻角色，避免角色表膨胀。
目标与触发条件：场景的起点和终点
目标要写成可观察的完成状态，让评审者能判断“达成了”还是“没达成”。“提升报销效率”无法验证；“员工提交报销单后，在三个工作日内收到打款通知，且单据状态变为已打款”可以验证。写法上可以把目标拆成结果对象、完成标志和可接受的条件范围三部分。
触发条件界定场景的起点，常见有三类：事件触发，如员工出差结束；时间触发，如每月固定结算日；状态触发，如单据被审批人退回。触发条件写得越具体，场景边界越清楚，也越容易判断哪些情况属于本场景、哪些属于另一个场景。
- 目标示例：审批人完成审批后，员工能在单据详情中看到审批结论和下一环节负责人。
- 事件触发示例：员工完成一次出差并产生可报销票据时进入场景。
- 状态触发示例：单据被退回后，员工进入修改并重新提交的场景。
目标之间可能冲突，例如员工希望尽快到账，财务希望凭证齐全后再付款。取舍时以场景的主要角色和主要目标为准，把另一方的诉求写成流程中的约束条件或协作角色的确认动作，而不是并列成两个互相拉扯的目标。
任务流程怎么拆：步骤、交接与异常
流程按角色动作拆步骤，每一步写清三件事：开始前需要什么输入、这个角色做什么动作、结束后留下什么产出。步骤之间的衔接就是交接点，交接点要标注上下游角色和确认方式，例如“员工提交后，系统生成待审批任务，审批人在待办中确认”。
拆解时可以按下面的顺序推进：
- 从触发条件出发，写出主要角色的第一个动作。
- 每完成一个动作，问一句“接下来谁需要看到这个产出”，据此确定下一个角色和步骤。
- 在角色切换处标注交接物和确认方式。
- 对每个步骤追问“如果这一步没做成会怎样”，补出异常与回退分支。
- 检查流程是否走到目标定义的完成状态，未走到则补步骤或修正目标。
异常分支的写法与主流程一致，同样写清触发原因、处理角色和回退到哪一步。例如凭证不清晰时，审批人退回并注明原因，员工补充凭证后重新提交，流程回到审批环节。粒度控制的标准是“可验证”：每一步都能被观察到是否完成，就停止继续细分；如果某一步内部还有多个角色交接，则继续拆开。
完整示例：一次报销场景的角色、目标与流程
以下为演示情景，用于说明写法，不代表任何真实业务数据。
场景名称：员工出差后提交报销并完成打款。
角色：主要角色为提交报销的员工；协作角色为直属审批人和财务出纳。
触发条件：员工出差结束并取得可报销票据，进入报销场景。
目标：员工提交的单据通过审批并完成打款，单据状态显示已打款，员工收到到账通知。
| 步骤 | 角色 | 输入 | 动作 | 产出 |
|---|---|---|---|---|
| 1 | 员工 | 出差票据、出差审批记录 | 填写报销单并上传凭证 | 待提交的报销单 |
| 2 | 员工 | 待提交的报销单 | 确认金额与科目后提交 | 待审批单据，进入审批人待办 |
| 3 | 直属审批人 | 待审批单据及凭证 | 核对事由与金额，做出通过或退回判断 | 审批结论 |
| 4 | 财务出纳 | 已通过审批的单据 | 核对凭证合规性并安排打款 | 打款记录，单据状态更新 |
| 5 | 员工 | 打款记录 | 查看到账通知并确认 | 场景完成 |
异常分支有两处：步骤3中审批人发现凭证不清晰，退回并注明原因，员工补充凭证后从步骤2重新提交；步骤4中出纳发现收款账户信息有误，退回员工修改账户信息，流程回到步骤2。两处异常都写明了触发原因、处理角色和回退位置。
这个示例可迁移的写法规律是：先写主要角色的起点动作，再沿交接物推进到协作角色，最后回到主要角色的完成确认；每个交接点都对应一个产出物，每个产出物都能被下一个角色检查。
常见误解：场景描述容易写偏的地方
| 常见写法 | 问题 | 修正建议 |
|---|---|---|
| 把功能列表当场景，逐条列出系统能做什么 | 缺少角色视角和起止边界，无法判断流程是否走通 | 改为从触发条件出发，按角色动作组织步骤 |
| 只写主流程，不写异常和回退 | 真实使用中的退回、补充、重试无处安放 | 对每个步骤补一条“没做成怎么办”的分支 |
| 角色写成“用户”“业务方”等抽象群体 | 每一步找不到责任人，交接无法确认 | 写成承担具体动作和判断的岗位或系统角色 |
| 目标写成“体验更好”“效率更高” | 无法判断场景是否完成，也无法验收 | 改写为可观察的完成状态和完成标志 |
| 把用户画像的人口统计特征当作场景角色 | 描述了人群，却没有描述谁在哪一步做什么 | 保留画像作为背景，另写场景角色字段表 |
自查时可以用一句话检验：把场景读给没参与梳理的同事听，他能否说出谁在什么情况下开始、经过哪几步、什么状态算结束。说不出来，通常是四项要素中有一项缺失或写得含糊。
场景梳理结果如何在团队中沉淀和复用
场景描述完成后，需要作为需求输入进入团队协作流程，否则容易停留在个人文档里。常见做法是把场景文档与需求条目建立对应关系：一个场景对应一组需求条目，每个流程步骤对应一条或多条需求，异常分支单独标注，便于后续排期和验收时回溯。
评审环节可以围绕四项要素逐项确认：角色是否覆盖了所有交接点，触发条件是否明确，目标是否可验证，流程步骤和异常是否完整。评审通过后，场景文档进入版本维护，当业务流程、角色权限或触发条件发生变化时，同步更新对应章节，并在需求条目中记录变更原因，避免文档与实现脱节。
这类沉淀工作涉及文档编写、评审流转和需求关联，可以在ONES中承载：场景文档作为需求的前置输入与需求条目关联，评审意见和版本变更在文档与工作项中留痕，方便后续按场景回溯需求来源。具体使用方式可结合团队现有的需求管理流程确定，不必另建一套独立体系。
常见问题
一个场景里需要写几个角色？协作角色要不要全部列出来？
通常写一个主要角色，再写流程实际涉及的协作角色。主要角色是场景目标的直接受益者，也是流程起点；协作角色在交接点上出现，提供输入、做审批或接收产出。角色数量以交接点为准，只出现一次且不承担判断的角色可以合并进相邻角色，避免角色表膨胀到没人看得完。
触发条件写得比较宽泛，会带来什么问题？
触发条件决定场景从哪里开始。写得宽泛，例如只写“员工有报销需求时”，场景边界就会模糊，评审时难以判断哪些情况属于本场景、哪些应另立场景。建议写成具体的事件、时间点或状态变化，例如“出差结束并取得可报销票据”或“单据被审批人退回”，这样流程第一步和异常分支也更容易确定。
任务流程拆到多细才算合适？拆得太细会不会反而难维护？
粒度标准是“可验证”：每一步都能被观察到是否完成，就可以停止细分；如果某一步内部还有多个角色交接，则继续拆开。拆得过细会把操作细节混进流程，增加维护成本。实际操作中可以先按角色动作拆到交接点，再对关键步骤补充输入、产出和异常分支，非关键步骤保持在一句话能说清的程度。
目标之间出现冲突时，场景描述应该怎么处理？
以场景的主要角色和主要目标为准，把另一方的诉求写成流程中的约束条件或协作角色的确认动作，而不是并列成两个互相拉扯的目标。例如员工希望尽快到账、财务要求凭证齐全，可以把“凭证齐全”写成审批环节的确认条件，把“到账”保留为场景的完成标志。这样目标仍然可验证，冲突也有了处理位置。
场景文档写完以后，怎么保证它和后续需求不脱节？
可以把场景文档与需求条目建立对应关系：一个场景对应一组需求，每个流程步骤对应一条或多条需求，异常分支单独标注。当业务流程、角色权限或触发条件变化时，同步更新场景文档对应章节，并在需求条目中记录变更原因。评审时围绕角色、触发条件、目标、流程四项逐项确认，能让文档和实现保持同步。
