产品用户使用场景指用户在特定环境、目标与限制条件下，为完成某项任务而使用产品的一段具体过程。它把“谁、在什么情况下、为了什么、怎样操作、得到什么结果”放在同一段描述里。本文说明场景的定义、构成要素与边界，并区分它与用户画像、用户故事、需求的关系，最后给出一个完整示例和记录交接方式。
要点总览（TL;DR）
- 产品用户使用场景描述一名具体角色在触发情境和约束条件下，为达成明确目标按一定路径使用产品并获得可观察结果的过程，判断标准是能否同时回答谁、何时、为何、怎样、结果如何。
- 场景由用户角色、触发情境与前置条件、目标与成功标准、操作路径与触点、环境与约束、结果与反馈六个要素构成，缺项会让描述退化为功能说明或愿望表达。
- 广告受众投放、通用社会调查、市场竞争格局和功能清单不属于使用场景；访谈原话和操作日志需结构化归纳后才算场景。
- 用户画像回答“谁”，场景回答“在什么情况下做什么”，用户故事是场景的简写，需求是场景分析后的解决方向，四者按角色—场景—需求衔接。
- 场景从调研素材到团队共识需经过整理成卡片、与需求建立对应并评审、用状态和责任人保持可追溯三个动作。
产品用户使用场景的准确定义
可以直接使用的一句话定义是：产品用户使用场景描述一名具体角色，在某个触发情境和既定约束下，为达成一个明确目标，按一定路径使用产品，并获得可观察结果的过程。判断一段文字是否算场景，看它能否同时回答五个问题：谁在使用、在什么情况下开始、想完成什么、经过哪些动作、最后得到什么结果。
这五个问题对应场景的五个基本成分：用户、情境、目标、动作、结果。缺少任何一项，描述都会退化成别的东西。只写“用户可以批量导出报表”，这是功能描述；补上“月末结账前，财务专员需要把当月各门店的销售明细汇总给总部，在权限允许的范围内按门店筛选后导出，并核对条数与金额”，才构成一段可用的场景。
场景的粒度落在任务级。战略级描述如“帮助中小企业实现数字化转型”覆盖范围过大，无法指导具体设计；按钮级描述如“点击导出按钮后弹出格式选择框”又过细，属于交互细节。任务级场景介于两者之间，围绕用户要完成的一件完整事情展开，通常对应一次有始有终的操作过程。粒度是否合适，可以用一个简单标准检验：这段描述能否让没参与调研的同事理解用户为什么这样做，以及做到什么程度算完成。
场景描述与功能描述的区别还体现在信息方向上。功能描述从产品出发，说明系统提供什么；场景描述从用户出发，说明用户在什么条件下需要什么。两者可以互相引用，但不能互相替代。一个功能可能服务多个场景，一个场景也可能跨越多个功能，这正是场景作为中间层描述的价值。
场景由哪些要素组成
把场景拆成可填写的要素，能让调研记录转化为结构一致的场景卡片，也便于评审时逐项检查。下表列出六个核心要素及其作用，以及缺失后容易出现的问题。
| 要素 | 要写清的内容 | 作用 | 缺失后的后果 |
|---|---|---|---|
| 用户角色 | 岗位、职责、与任务相关的经验水平；同一任务下不同角色的差异 | 确定视角，避免用“用户”笼统代替 | 描述失去立场，不同角色的诉求被混为一谈 |
| 触发情境与前置条件 | 什么事件或时间点让任务开始；开始前必须已具备的条件 | 说明场景何时发生、为何发生 | 场景变成随时可做的孤立操作，优先级难以判断 |
| 目标与成功标准 | 用户想达成的结果；怎样算完成、怎样算做好 | 提供评价依据 | 只能描述过程，无法判断方案是否解决问题 |
| 操作路径与触点 | 用户经过的主要步骤；使用的页面、设备、渠道或人工环节 | 连接用户行为与产品能力 | 场景停留在愿望层面，无法落到设计与验证 |
| 环境与约束 | 时间压力、设备与网络条件、权限范围、合规与审批要求 | 界定方案可行空间 | 方案在真实条件下不可用，或忽略关键限制 |
| 结果与反馈 | 用户最终得到什么；系统或他人给出什么反馈；异常时如何得知 | 闭合场景，支撑效果评估 | 场景有头无尾，无法验证是否达成目标 |
角色差异值得单独说明。同一个“提交报销”的任务，普通员工关心填写速度和票据上传，财务审核人员关心合规校验和批量处理，部门负责人关心审批时的预算可见性。三者处在同一业务链条的不同位置，场景应分别记录，不宜合并成一条笼统描述。
约束条件常被写得过轻。时间约束如“必须在每月最后一个工作日前完成”，权限约束如“只能查看本区域数据”，合规约束如“导出内容需留存操作记录”，这些条件直接决定方案边界。写作时把约束与对应结论放在一起，例如“因仅能查看本区域数据，筛选器默认锁定所属区域”，读者才能理解设计取舍的依据。
场景的边界：哪些内容不属于使用场景
明确排除项，能防止场景文档被写成需求池或市场分析。以下内容经常与场景同时出现，但各自属于不同工作。
- 广告受众投放与人群包运营：这类工作关注如何圈选人群、分配预算、优化投放，对象是营销触达而非产品使用过程，归广告与增长运营范畴。
- 通用社会调查与宏观用户行为统计：如某年龄段人群的整体消费习惯、行业用户规模变化，属于调查研究和市场统计，回答的是群体分布问题，不描述具体任务过程。
- 市场竞争格局与份额分析：竞品对比、市场占有率、定价策略归市场与竞品分析，场景文档可以引用其结论，但不承担这部分内容。
- 功能清单与需求列表：功能清单说明系统有什么，需求列表说明要做什么，两者是场景分析的输入或输出，本身不构成场景。
纳入场景的内容则应满足两个条件：描述的是产品被使用的过程，且聚焦到可识别的任务。按此标准，用户访谈原话、观察记录、操作日志中的行为片段可以作为素材，但需要整理成包含角色、情境、目标、路径、约束、结果的完整描述后才算场景。素材与场景的区别在于是否完成了结构化归纳。
场景与用户画像、用户故事、需求的区别
四个概念常在同一份研究文档中出现，各自回答不同问题。用同一组对象对照，可以看清它们的衔接关系。
| 概念 | 回答的问题 | 典型形式 | 在流程中的位置 |
|---|---|---|---|
| 用户画像 | 谁在使用，这类人有什么特征 | 角色档案：职责、目标、痛点、经验水平 | 提供角色基础，回答“谁” |
| 使用场景 | 在什么情况下，为了什么，怎样使用并得到什么结果 | 结构化场景卡片或段落描述 | 把角色放入具体任务，回答“在什么情况下做什么” |
| 用户故事 | 以简写方式表达一个需求视角 | “作为某角色，我希望……以便……” | 场景的压缩表达，便于进入待办列表 |
| 需求 | 要解决什么问题、做成什么样 | 需求条目、验收标准、优先级 | 场景分析后的解决方向与交付约定 |
用户画像回答“谁”，场景回答“在什么情况下做什么”，两者结合才能避免把某一类角色的偏好当成普遍需求。用户故事是场景的一种简写表达，它保留了角色、愿望和目的，省略了环境、约束和操作路径，适合进入迭代管理，但不宜作为唯一的场景记录。需求是场景分析后的解决方向，一条场景可能引出多条需求，一条需求也可能服务多个场景。
三者的衔接顺序通常是：先通过调研形成用户画像，再围绕画像中的角色整理使用场景，然后从场景中提炼用户故事和需求条目，最后用场景回验需求方案是否覆盖了真实条件。这个顺序不是硬性规定，但保持“角色—场景—需求”的对应关系，能让后续评审有据可查。
一个完整场景的例子与常见误解
下面是一个包含全部要素的示例，场景为演示用途，不对应特定产品。
场景：连锁门店督导在巡店当天完成问题上报。角色是区域督导，负责五到八家门店的日常检查，常在移动状态下工作。触发情境是到店检查发现陈列或库存问题，前置条件是督导已登录并具备该门店的检查权限。目标是当天离店前把问题连同照片提交给店长和区域经理，成功标准是问题描述清楚、责任人和整改期限明确、店长已收到通知。操作路径为：在手机端选择门店与检查项，拍摄现场照片，填写问题描述并选择整改期限，提交后查看确认状态。约束包括门店网络不稳定、拍摄时需避开顾客面部、整改期限须符合公司规定的时限。结果是店长收到待整改通知，督导在列表中看到“已提交待确认”状态，若超时未确认则收到提醒。
常见误解有三类。第一类是把场景写成功能说明，例如“支持拍照上传和问题分类”，修正方式是补上谁在什么情况下为什么使用这些功能。第二类是写得过宽，例如“提升门店管理效率”，修正方式是收敛到一次具体任务和可观察结果。第三类是忽略约束，例如只写“提交问题”，未说明网络条件、隐私要求和时限规定，修正方式是把约束与设计结论相邻写出。
| 修正前 | 问题 | 修正后 |
|---|---|---|
| 系统支持问题上报和照片上传 | 功能描述，无角色与情境 | 督导在巡店发现陈列问题时，用手机拍照并填写描述，当天提交给店长 |
| 帮助门店提升管理效率 | 过宽，无法验证 | 督导离店前完成上报，店长在当日收到待整改通知 |
| 督导提交问题后流程结束 | 缺结果与反馈 | 提交后显示待确认状态，超时未确认触发提醒 |
场景在研究流程中如何被记录和交接
场景从调研素材变成团队共识，需要经过整理、评审和状态跟踪三个动作。整理阶段，研究者把访谈记录、观察笔记和操作日志中的行为片段归纳为场景卡片，每张卡片按角色、触发情境、目标与成功标准、操作路径与触点、环境与约束、结果与反馈六项填写，并标注素材来源和调研时间。卡片数量不宜过多，同一角色同一任务合并为一张，不同角色的差异单独成卡。
评审阶段，场景卡片与需求条目建立对应关系：每条需求注明它服务哪个场景，每个场景列出已覆盖和未覆盖的需求。评审时逐项检查场景的约束是否被方案尊重，成功标准是否有对应的验收方式。评审结论记录为通过、待补充或暂缓，并指定后续动作的责任人。
跟踪阶段的关键是保持状态可追溯。场景卡片应有明确的状态，例如待整理、待评审、已确认、已转需求、已失效，每次状态变化记录时间和操作人；场景与需求的关联关系在需求变更时同步更新，避免出现需求已改而场景描述仍旧的情况。对于跨团队协作，把场景卡片、需求条目和评审记录放在同一协作空间中，用工作项承载状态流转、用文档承载场景描述，可以让研究者、产品经理和设计人员在同一个入口查看上下文。ONES 这类研发协作平台可以承载工作项状态、责任人和文档关联，具体配置方式依团队流程而定。这样做的目的不是增加文档数量，而是让“这条需求来自哪个场景、当时有哪些约束、谁确认过”在数月后仍能查到。
常见问题
一次调研产生很多用户原话，怎样判断哪些可以整理成场景？
先看素材是否描述了产品被使用的具体过程。用户原话里如果包含角色身份、事情发生的时点或事件、想完成的目标、实际操作的步骤以及最后得到的结果，就具备整理成场景的基础。只有偏好表达（如“我觉得这个功能还行”）或群体统计（如“多数用户每周使用三次”）的素材，需要补充访谈追问或观察记录后再归纳。
整理时把同一角色、同一任务的片段合并为一张场景卡片，不同角色的差异单独成卡。素材来源和调研时间一并标注，便于后续回溯。
场景卡片需要写到多细，评审时才够用？
判断标准是没参与调研的同事能否据此理解用户为什么这样做、做到什么程度算完成。达到这个程度，通常需要写清触发情境、目标与成功标准、主要操作路径、关键约束和结果反馈。交互细节如按钮位置、弹窗样式可以留到设计阶段，不必写进场景卡片。
如果评审中反复出现“用户为什么会在这个时点做这件事”的疑问，说明触发情境写得不够；如果方案讨论总在约束条件上卡住，说明环境与约束一项需要补充。
同一个任务涉及多个角色时，场景应该合并还是分开记录？
建议分开记录。同一业务链条上的不同角色，关注点和成功标准往往不同。例如提交报销，普通员工关心填写速度，审核人员关心合规校验，负责人关心预算可见性。合并成一条笼统描述，评审时容易把某一角色的诉求当成全部需求。
分开记录后，可以在场景之间标注上下游关系，说明谁的动作触发谁的后续处理，这样既保留角色差异，也不丢失业务链条的整体视角。
需求变更后，原来的场景描述要不要跟着改？
需要同步检查。场景与需求之间应保持对应关系，需求调整时确认它服务的场景是否仍然成立：如果约束条件变了，场景中的环境与约束一项要更新；如果目标变了，成功标准要重写；如果需求被拆分或合并，场景与需求的关联关系也要调整。
实际操作中，可以在需求变更时把关联场景列为检查项，由变更发起人确认场景描述是否仍然准确，避免出现需求已改而场景文档停留在旧版本的情况。
场景记录应该放在文档里还是工作项里？
两者承担不同职责，可以配合使用。场景描述包含较多叙述性内容，适合放在文档中，便于完整表达角色、情境、约束和结果；场景的状态、责任人、与需求的关联关系属于流转信息，适合用工作项承载，便于筛选和跟踪。
ONES 这类研发协作平台可以同时提供文档与工作项，并把两者关联起来，具体如何配置取决于团队现有的流程和权限设置。关键是在同一入口能查到场景描述、对应需求和评审记录。
