3. 识别关键用户场景：场景来源、场景分类、场景描述模板

3.1 为什么用户场景是原型验证的起点

用户场景是连接真实需求与原型设计的“翻译层”。没有经过结构化梳理的场景清单，Figma 原型容易陷入“自嗨式设计”——看起来美观，却无法回答“用户到底会不会这么用”。场景识别为后续用户访谈提纲、需求拆解、验收标准提供了可追溯的上下文，是课程 30 章中承上启下的关键节点。

3.2 三大场景来源

用户场景不是凭空推测的，它们来自三条可执行的采集渠道。下表对比了每个来源的典型方法、产出物和可信度等级。

3.3 四种场景分类

从来源中提取的原始场景需要按使用频率和业务影响进行分类，以便在原型验证中分配优先级。以下分类覆盖了日常迭代中 95% 以上的场景类型。

3.4 场景描述模板

为了让每个场景可直接输入 Figma 原型画板，我们使用统一的“六字段”模板。模板保持字段级颗粒度，避免长篇叙事。

场景名称： [动宾结构，例如“查看订单物流状态”]
用户角色： [谁] 
触发条件： [在什么情境下/因为什么原因开始]
用户目标： [用户真正想完成的事，用“为了…”句式]
操作流程： 
 1. [原子步骤1]
 2. [原子步骤2]  
 3. [原子步骤3] （不超过 7 步）
预期结果： [系统响应 / 用户感知到的变化]
优先级：   [P0 / P1 / P2]

填写示例（用于 Figma 原型验证）：

场景名称： 提交售后工单
用户角色： 已登录的普通买家
触发条件： 收到商品存在质量问题，在订单详情页点击“申请售后”
用户目标： 用最少操作提交包含图片证据的售后请求
操作流程： 
 1. 选择售后类型（退货/换货/维修）
 2. 上传 1-3 张问题照片
 3. 填写简短问题描述（可选）
 4. 点击提交按钮
预期结果： 系统显示“提交成功”页面，并在 2 分钟内发送确认短信
优先级： P0

3.5 用户场景识别框架

下图将场景来源、分类汇聚与模板输出整合为一条可执行的识别链路，每个环节都对应本章讲解的技术要点。

3.6 从场景到原型：实践步骤

将本章方法落地到 Figma 原型验证中，建议按以下四步操作：

1. 采集与分类：从 3 个来源收集原始场景，使用 4 分类表格打标签，输出“场景清单”。
2. 优先级排布：按 P0 → P1 → P2 排序，单次迭代只取 Top 5 场景进入原型设计。
3. 模板填充：为每个高优场景填写六字段模板，确保字段完整、步骤粒度一致。
4. 映射画板：在 Figma 中为每个场景创建独立的画板（Frame），画板命名与“场景名称”字段严格对应。

3.7 常见误区与校准检查

• 场景过粗：“用户下单”不是合格场景——必须拆解到“选择收货地址→选择支付方式→确认订单→支付”这样的原子步骤。
• 分类混淆：把“用户忘记密码”归为边缘场景，实际上它是异常场景，需要设计明确的容错路径。
• 来源单一：只依赖竞品观察做场景假设，容易漏掉真实用户的关键痛点。
• 模板跳过：直接画原型不写场景描述，导致方案评审时反复返工。