第二章：用户研究与需求分析
好，咱们进入第二章。用户研究与需求分析，说白了就是搞清楚「谁在用、在哪儿用、用啥功能」。我见过太多团队，一上来就画界面、写代码，结果做出来的东西用户根本不用。嗯，这章咱们就把这事掰扯清楚。
2.1 目标用户画像
用户画像不是拍脑袋想出来的。我个人习惯，先做实地调研，再提炼共性。你想想看，开车的用户群体差异太大了——年轻人和老年人对屏幕的依赖程度完全不同。
2.1.1 画像维度
- 年龄与驾驶经验：新手司机更依赖导航和辅助功能，老司机可能更关注仪表盘信息
- 技术接受度：有人喜欢语音控制，有人就爱物理按键
- 使用场景：通勤、长途、接送孩子，每个场景的需求都不一样
核心观点：用户画像要具体到「张三，35岁，驾龄8年，每天通勤40分钟，喜欢用CarPlay听播客」这种程度。越具体，设计越有方向。
2.1.2 画像构建方法
我在项目中遇到过，有些团队直接拿竞品报告里的画像来用。这其实是个坑。我建议你这样做：
- 招募真实用户：至少10-15人，覆盖不同年龄段
- 深度访谈：问他们开车时最烦什么、最想要什么
- 观察驾驶行为：有条件的话，跟车记录他们的操作习惯
小技巧：做访谈时别问「你想要什么功能」，要问「你上次开车时遇到什么麻烦」。后者能挖出真实需求。
2.2 驾驶场景分析
驾驶场景分析，说白了就是搞清楚用户「在什么情况下用你的功能」。我曾经犯过一个错——在实验室里测试导航功能，结果用户在实际高速路上根本不敢分心看屏幕。
2.2.1 场景分类
| 场景类型 | 典型情况 | 设计要点 |
|---|---|---|
| 静态场景 | 停车、等红灯 | 可以接受较复杂的交互 |
| 低速场景 | 拥堵路段、倒车 | 需要简化操作层级 |
| 高速场景 | 高速巡航、变道 | 尽量用语音或HUD，减少视觉占用 |
| 紧急场景 | 急刹车、避让 | 功能应自动触发，无需用户操作 |
2.2.2 场景优先级
你想想看，一个功能在高速场景下好不好用，比在停车场景下重要得多。我一般这样排优先级：
- 高频场景：每天都会遇到的，比如导航、音乐切换
- 安全关键场景：虽然不常发生，但一旦出错后果严重，比如紧急制动提示
- 低频但重要场景：比如长途旅行中的充电站规划
注意：别把所有场景都当成重点。我曾经见过一个项目，把「夜间模式」的动画效果做得极其复杂，结果用户反馈「我开车时谁有空看动画？」。优先级搞反了。
2.3 任务优先级排序
任务优先级排序，说白了就是「哪些功能必须做好，哪些可以凑合」。我习惯用Kano模型来分类。
2.3.1 Kano模型应用
| 类别 | 定义 | 例子 |
|---|---|---|
| 基本型需求 | 没有会出问题，有了用户觉得理所当然 | 仪表盘显示车速、油量 |
| 期望型需求 | 用户明确想要的，做得越好满意度越高 | 导航路线规划、语音控制 |
| 兴奋型需求 | 用户没想到的，但有了会惊喜 | 疲劳驾驶提醒、自动泊车 |
2.3.2 排序方法
我个人习惯用「频率×重要性」矩阵。举个例子：
功能：导航目的地输入
频率：每天2-3次
重要性：高（分心风险大）
优先级：P0（必须优化）
功能：座椅按摩调节
频率：每周1次
重要性：低
优先级：P2（有空再优化）
关键原则：安全相关的功能永远是P0。我曾经在项目里把「语音唤醒」排到P1，结果用户反馈「开车时手动点屏幕太危险了」。后来赶紧调回P0。
2.4 避坑指南
嗯，这里我要多说几句。做用户研究，有几个坑特别容易踩：
- 样本偏差：只找年轻人做测试，结果老年人用户完全不会用。我建议覆盖18-65岁。
- 过度依赖问卷：问卷只能反映「用户说他们想要什么」，实际行为可能完全不同。一定要结合观察。
- 忽略环境因素：白天和夜晚、晴天和雨天，用户的操作习惯差异很大。我建议至少做3种不同环境下的测试。
我的经验：做用户研究时，多问「为什么」。用户说「这个按钮不好找」，你要追问「你觉得它应该在哪？」。很多时候，用户自己都不知道真正的问题在哪。
好了，第二章就这些。记住：用户研究不是一次性工作，而是贯穿整个开发周期的。下一章咱们聊「交互设计原则」，到时候见。