用户场景与痛点捕获：从现场到关键需求
在IoT产品定义中，场景不是想象出来的，而是从真实物理环境中“剥”出来的。本章聚焦于如何系统化绘制场景地图、观察用户行为、并从噪声中筛选出真正值得解决的痛点。
3.1 IoT场景地图：让“现场”结构化
场景地图（Scenario Map）是对用户、设备、环境三者交互关系的可视化抽象。它帮助团队在同一张图上对齐对“现场”的理解。
核心原则：一张场景地图必须回答三个问题——谁（用户/角色）、在哪（物理/数字环境）、做什么（任务/事件序列）。
3.2 场景地图的组成要素
| 要素 | 描述 | IoT示例 |
|---|---|---|
| 角色 | 执行任务的实体（人、设备、系统） | 巡检员、温湿度传感器、云端告警系统 |
| 物理触点 | 用户与设备发生交互的物理位置 | 配电柜面板、手持终端、设备标签 |
| 任务流 | 连续的动作序列，包含决策点/异常分支 | 扫码→查看参数→判断阈值→上报异常 |
| 环境变量 | 影响任务执行的外部条件 | 光照、噪声、网络信号强度、温度 |
| 边界条件 | 任务开始/结束的触发事件 | 设备告警触发、交接班完成、数据上传成功 |
3.3 场景地图绘制步骤
- 界定边界：选择一条完整的任务主线，例如“从发现设备异常到完成检修上报”。
- 列出所有参与者：包括人、设备、后台系统、外部接口。
- 按时间线排布事件：从触发事件开始，到终止事件结束。
- 标注每个节点的环境状态：网络带宽、响应时间、空间位置等。
- 识别分支路径：正常流、异常流、延迟流、取消流。
实战建议：使用便签纸/白板绘制前，先对现场进行至少2小时的“影子跟踪”，记录真实事件序列而非预设流程。
3.4 用户行为观察方法
行为观察不是“假装自己是用户”，而是使用结构化方法论捕获真实交互。以下为三种适用于IoT场景的观察方法。
| 方法 | 适用阶段 | 产出物 | 注意事项 |
|---|---|---|---|
| 影子跟踪 | 初始探索 | 时间轴 + 异常事件表 | 不干预、不提问、录音辅助 |
| 任务分析 | 场景细化 | 子任务分解表 + 痛点标记 | 区分“系统任务”和“用户任务” |
| 行为日志分析 | 已有设备 | 操作频次热力图 + 异常路径 | 排查噪声点（网关断电、死机重连） |
常见陷阱：只观察“典型日”容易遗漏低频但关键的事件。建议至少覆盖：正常工作流、故障恢复流、交接班流、紧急变更流。
3.5 高频痛点 vs. 低频但关键需求
并非每个痛点都值得在MVP中解决。判断优先级的关键在于：发生频率 × 影响度。
| 分类 | 特征 | MVP处理策略 | IoT案例 |
|---|---|---|---|
| 高频痛点 | 每日/每周发生；用户主动抱怨；影响操作效率 | 核心功能覆盖，优先解决 | 巡检手工录入数据耗时（每日多站） |
| 低频但关键 | 偶发但后果严重；用户可能忽略未谈 | MVP做异常降级处理，但不做核心路径 | 冷链断连导致药物失温（一年2次） |
| 低频且不影响 | 偶发且影响可接受 | 暂不处理，记录至迭代池 | 非换班时段的告警弹窗重复 |
| 高频但无感 | 高频但用户已习惯适应 | 从效率成本维度评估机会点 | 设备每日自动重启告警已屏蔽 |
3.6 关键需求转化公式
关键需求 = (痛点频率 × 用户感知强度 × 业务影响系数) - (当前替代方案效用)
频率：每日=5 每周=3 每月=1
感知强度：强烈抱怨=5 偶尔提及=3 从未提起=1
业务影响：安全/合规=5 产值=4 效率=3 体验=2
替代方案效用：无=0 很弱=1 中等=3 可接受=5
筛选规则：
- 乘积 ≥ 50 → 必须纳入MVP
- 30 ~ 49 → 视资源决定
- < 30 → 放入后版本