4. 用户场景与任务分析

硬件产品的功能边界失控,往往源于场景定义模糊。本章以用户旅程地图为结构化工具,建立一套从“用户行为流”中提取场景类型(核心/边缘/非目标)的实战方法,确保PRD中的每一个功能都能回答“用户在什么时机、什么环境、基于什么动机使用它”。

4.1 为什么场景分类是边界控制的第一道防线

硬件产品研发中,60%以上的需求膨胀来自“伪场景”——开发团队为了兼容极少发生的使用方式而添加功能,导致开发周期延长、成本上升。场景分类的根本目的不是“记录所有可能”,而是用资源权重驱动功能取舍。

场景类型 定义 资源分配建议
核心场景(Core) 目标用户的日常高频使用路径,满足产品核心价值主张 60-70% 研发资源,必须交付并经过严格验收
边缘场景(Edge) 低频但合理的使用分支,通常由环境变化或用户异常行为触发 20-30% 资源,可通过降级方案、预设模式覆盖
非目标场景(Non-target) 产品设计明确不支持的用法,或极小概率的极端条件 0% 资源,在PRD中标注为“不 scope”并说明理由
关键原则:每一个识别出的非目标场景都是潜在的需求蔓延入口。PRD中必须显式列出“不做什么”,其重要性不亚于“做什么”。

4.2 用户旅程地图的结构化拆解

用户旅程地图不是一张随意的体验流程图,而是以“任务-触点-情绪-痛点”四要素为单元的场景网格。制作流程分三步:

  1. 划定任务区间:从“购买前”到“使用后”拆解为5-7个主要阶段,如开箱、首次配置、日常使用、故障处理、报废回收。
  2. 列出每阶段的用户任务:每个任务是一个具体的操作,例如“将电源线插入设备背面接口”。
  3. 标注场景类型:基于任务出现频率、对核心价值的影响、替代方案是否可用,判定为核心/边缘/非目标。

4.3 核心场景的识别标准

一个场景被归类为核心,需要同时满足以下三个条件:

  • 频率条件:在被调研的目标用户中,70%以上用户每月至少执行该任务一次。
  • 价值条件:该任务的失败将直接导致产品核心功能无法使用,或引起用户严重不满。
  • 不可替代条件:不存在其他可行的变通方式(如改用手机App操作)。
案例:智能锁产品的“指纹识别开门”是核心场景(高频、失败则无法入户);而“通过机械钥匙开门”虽然低频,但属于边缘场景(应对电池耗尽);“用远程App为访客生成一次性密码”若设计时未考虑蜂窝网络机型,则应标注为非目标场景,避免开发投入。

4.4 边缘场景与降级策略

边缘场景不需要和核心场景同等的稳定性和易用性,但必须规划“降级路线”。常见的降级策略包括:

边缘场景示例 降级方案 验收标准(降级后)
用户在-10°C户外操作触摸屏 强制启用实体按键导航 按键响应时间≤300ms,不要求触摸
Wi-Fi断连时同步云端数据 本地缓存数据,恢复连接后自动同步 缓存不丢失,同步延迟≤10分钟
用户反插USB-C接口 接口机械防呆 + 无通电解锁 插反时无物理损伤,不产生电气接触
避坑提示:不要将边缘场景的降级方案写成“软件更新解决”。硬件层面必须提供物理或逻辑的保底机制,否则该场景应直接归入非目标。

4.5 非目标场景的声明规则

在PRD中,非目标场景需要以“明确排除清单”形式出现,包含三条信息:场景描述、排除理由、替代方案(如果有)。

示例(来自穿戴式心率监测仪PRD):

排除场景:用户在海水中游泳时连续监测心率
排除理由:电极在水下无法保持接触阻抗稳定,测量结果无临床意义
替代方案:建议用户使用专业水下心率胸带,本产品支持数据导入接口

每一类非目标场景的排除,必须经过产品经理、硬件工程师和测试工程师三方确认,并记录在需求评审纪要中。

4.6 旅程地图场景分类实战流程

以下SVG展示了以智能净水器为例的完整场景分析框架,从用户阶段到任务、再到场景类型的映射关系。

用户旅程地图场景分类(智能净水器示例) 核心场景 边缘场景 非目标场景 安装与开箱 核心:拆包装、连接水管
边缘:安装墙面固定架
非目标:自行改造滤芯 首次配置 核心:绑定App、设置水质
边缘:手动校准TDS值
非目标:OTA失败后拆机刷固件
日常用水 核心:接水、查看水质
边缘:高温连续取水
非目标:用净水冲洗油烟机
滤芯更换 核心:App提醒后更换
边缘:断电后手动复位
非目标:非原装滤芯兼容
故障处理 非目标:漏水时自行焊接水管 场景分类决策逻辑 ① 频率筛:用户每月使用≥1次? → 是 → 进入价值筛;否 → 进入低频分支 ② 价值筛:任务失败是否导致核心功能不可用或严重投诉? → 是 → 核心场景;否 → 进入替代筛 ③ 替代筛:是否有其他可行方式完成该任务(硬件/软件变通)? → 有 → 边缘场景;无且低频 → 非目标场景

4.7 场景移交物与验收标准

完成用户旅程地图后,需要输出三份文档作为PRD的附件:

交付物 内容要求 验收标准
场景分类矩阵 包含所有识别到的任务,标注场景类型、频率、价值评估、替代方案 无遗漏,每项分类经过至少2名PO和1名硬件专家评审
核心场景交互规范 针对每个核心场景,描述界面GUI/物理按键反馈、响应时间、错误状态 原型测试中核心场景任务成功率≥95%
非目标场景排除清单 至少列出5个明确的不可用场景,附理由和替代方案说明 在需求评审会上无“这个场景为什么不做”的质疑
实战建议:在开始硬件功能设计前,组织一次“场景分类工作坊”,邀请项目经理、硬件工程师、工业设计师和测试各1人,用便利贴在白板上画用户旅程地图。整个过程控制在2小时内,产出即可直接用于PRD功能边界定义。