第2章 目标用户画像构建：用户角色分层、核心痛点提炼、使用场景假设
用户画像是需求分析的原点。IoT产品往往同时服务于多个角色，每个角色对产品的期望、使用深度、决策权重完全不同。本章提供一套从角色分层到场景假设的可操作方法，让你在项目启动阶段就能精准锁定目标用户。
2.1 用户角色分层法
IoT产品的使用者不是单一用户，而是一个角色网络。分层时按照决策权重和使用频率两个维度切割，得到四个典型角色层。
| 角色层级 | 典型角色 | 核心关注点 | 决策权重 | 使用频率 |
|---|---|---|---|---|
| 决策层 | CEO / CTO / CIO | ROI、数据安全、战略对齐 | 高 | 低（月/季） |
| 管理层 | 运营经理 / 项目经理 | 效率提升、KPI达成、团队协作 | 中高 | 中（日/周） |
| 执行层 | 一线操作员 / 安装工程师 | 易用性、稳定性、响应速度 | 中 | 高（每日） |
| 受益层 | 终端用户 / 合作伙伴 | 体验流畅、价值可见、成本节约 | 低（影响高） | 不定 |
实操要点：每个项目至少识别 4–6 个具体角色。不要只写“用户”，要写出角色姓名+职责，例如“工厂设备管理员张工——负责每日巡检和异常上报”。
2.2 核心痛点提炼
痛点是需求的燃料。每个角色层的痛点可以从效率、成本、体验、数据四个维度展开。使用下表进行结构化收集：
| 痛点维度 | 决策层 | 管理层 | 执行层 | 受益层 |
|---|---|---|---|---|
| 效率 | 战略落地慢 | 跨部门协同低效 | 重复操作耗时长 | 服务响应延迟 |
| 成本 | TCO不透明 | 运维人力超支 | 工具损耗高 | 使用成本难控 |
| 体验 | 汇报数据不可视 | 系统操作复杂 | 界面信息过载 | 交互反馈弱 |
| 数据 | 缺乏决策支撑 | 多源数据孤岛 | 现场数据难采集 | 数据不可见 |
痛点优先级矩阵：将采集到的痛点按“影响范围 × 发生频率”打分，得分最高的 3–5 个痛点作为本轮需求分析的核心锚点。
2.3 使用场景假设
场景假设连接“谁（角色）”在“什么环境（情境）”下“做什么（任务）”。使用场景卡片模板记录每个假设：
- 场景名称：如“设备故障远程诊断”
- 参与角色：执行层（一线工程师）+ 管理层（运维主管）
- 前置条件：设备告警触发、工程师在途
- 操作流程：接收告警 → 查看诊断面板 → 定位故障 → 远程复位或派单
- 预期结果：平均修复时间缩短 40%
- 验收信号：诊断面板加载 < 2s，复位成功率 > 85%
避坑提醒：场景假设容易陷入“自己想象的需求”。每个场景必须标注验证方法（用户访谈/实地跟访/日志分析），未经验证的场景不要进入需求池。
以下三个典型场景在IoT项目中高频出现，建议优先覆盖：
| 场景类别 | 典型任务 | 涉及角色 | 验证方式 |
|---|---|---|---|
| 日常运维 | 设备监控、巡检、批量配置 | 执行层、管理层 | 现场跟访 + 操作录屏 |
| 紧急响应 | 故障告警、应急处置、远程控制 | 执行层、管理层 | 模拟演练 + 访谈 |
| 数据分析 | 趋势分析、报表生成、异常检测 | 管理层、决策层 | 原型演示 + 用户反馈 |
2.4 从画像到需求的映射
将角色、痛点、场景三者组合，输出用户故事地图和需求优先级矩阵作为本章交付物。
用户故事地图格式：
作为 <角色>
我希望 <功能/能力>
以便 <价值/收益>
[验收标准：<可量化指标>]需求优先级矩阵维度：
- 用户价值：解决核心痛点的程度（高/中/低）
- 实现成本：开发与部署资源投入（大/中/小）
- 技术风险：方案可行性不确定性（高/中/低）
- 依赖关系：是否阻塞其他需求（阻塞/并行/独立）
本章交付物模板清单：
① 用户角色分层表（含角色卡片）
② 痛点优先级矩阵（Top 5 痛点）
③ 场景假设卡片（至少 3 张）
④ 用户故事地图（V0.1 版本）
⑤ 需求优先级矩阵（评审版）
① 用户角色分层表（含角色卡片）
② 痛点优先级矩阵（Top 5 痛点）
③ 场景假设卡片（至少 3 张）
④ 用户故事地图（V0.1 版本）
⑤ 需求优先级矩阵（评审版）
完成上述四个步骤后，你将得到一份结构化的用户画像文档，它不仅是需求分析的核心输入，也是后续交互设计、技术方案评估和验收测试的参照基准。下一阶段将基于此画像开展用户访谈与需求拆解。