第3章 交互场景识别:用户角色、使用环境、任务目标、触发条件
交互场景是交互设计的基础单元,它刻画了什么人在什么环境下为了达成什么目标而在什么条件下启动交互。精确识别场景的四个要素(用户角色、使用环境、任务目标、触发条件),可以避免设计过程中出现歧义、遗漏或偏离真实需求。
适用场景
- 新功能/新产品需求分析阶段
- 现有功能交互重构前的问题定位
- 用户旅程图、故事板的前置输入准备
- 多团队协作时进行设计范围对齐
前置条件
- 已有初步的用户研究数据(访谈、观察、日志)
- 产品需求文档(PRD)或用户故事(User Story)已完成框架定义
- 参与识别的角色包括:交互设计师、产品经理、业务方(至少一位)
操作步骤
按照以下顺序逐步完成交互场景的四要素识别与确认:
- 识别用户角色:从用户池中挑选出与该交互直接相关的具体角色,记录其典型特征(年龄、技术经验、痛点、期望)。
- 分析使用环境:描述交互发生的物理环境(如办公室、地铁、工厂)、数字环境(设备类型、网络状态、并行应用)及社会环境(是否被他人注视、是否需快速完成)。
- 定义任务目标:明确用户在该场景下想要达成的核心结果(非操作步骤),目标需可量化或可验证。
- 确定触发条件:标注启动交互的内部触发(用户主动意愿,如“想查余额”)和外部触发(系统推送、他人提醒、时间/事件到达)。
- 整合形成场景描述:将四要素组合为一段完整语句,格式为:“当[用户角色]在[使用环境]中为了[任务目标]而[触发条件]时,开始交互。”
提示:如果某一要素在多轮沟通后仍存在分歧,优先以用户研究数据为裁决依据,而非设计师个人经验。
输入输出物
| 类型 | 名称 | 说明 | 模板示例 |
|---|---|---|---|
| 输入 | 用户研究原始材料 | 访谈记录、观察笔记、问卷统计 | — |
| 输入 | 产品需求梗概 | PRD 中的功能列表与用户故事 | — |
| 输出 | 场景识别表格 | 每行一条场景,四要素及描述 | |
| 输出 | 场景描述卡片 | 用于工坊贴纸、A4打印、白板讨论 | |
责任边界
- 交互设计师:主导四要素的识别、记录与场景描述撰写;对要素的准确性负责。
- 产品经理:提供业务上下文与用户故事,确认场景优先级;对场景的业务合理性负责。
- 业务方/用户研究员:提供一手数据,验证要素是否贴合真实情况;对数据的真实性负责。
记录材料
- 场景识别工作簿(Excel/Google Sheets):包含所有场景的四要素及审批状态。
- 场景描述卡片集(PDF/实物卡片):用于评审会分发和存档。
- 会议纪要/决议记录:标注每个场景的确认人、确认日期及待办事项。
异常处理
| 异常情况 | 处理方式 |
|---|---|
| 要素缺失(如用户角色不明确) | 暂停该场景识别,补充用户研究或与产品经理、业务方联合快速访谈 |
| 多个角色共用同一任务目标 | 拆分为多个细分场景,每个角色独立一条 |
| 环境信息与目标逻辑冲突 | 回归原始数据,优先采用观察/日志中的实际环境记录 |
| 团队成员对触发条件存在分歧 | 创建“内部触发”和“外部触发”两个候选条目,在原型阶段通过A/B测试验证 |
验收标准
- 每个场景都包含完整四要素:用户角色、使用环境、任务目标、触发条件。
- 场景描述语句通顺无歧义,团队成员朗读后理解一致。
- 所有要素均能追溯到一手用户数据或产品决策文档。
- 场景识别表格通过交互设计师+产品经理的双人签字确认(或电子签章)。
- 每个场景的不可替代性已确认:不存在重复覆盖或遗漏关键路径。
关键提示:四要素中“触发条件”是最容易被忽略的要素。若缺少触发条件,场景将变成“万能场景”——无法指导设计决策。务必为每个场景明确写下“用户因为什么开始做这件事”。