第三章：用户研究与场景分析
好，咱们进入第三章。这一章我特别想跟你聊聊，因为很多车载HMI翻车，说白了就是栽在「不了解用户」和「没想清楚场景」上。
我个人习惯，做任何界面之前，先花一周时间泡在用户研究里。你想想看，连开车的人是谁、在什么情况下用你的屏幕都不知道，那设计出来的东西不就是闭门造车吗？
3.1 目标用户画像
先说说用户画像。这不是什么玄学，就是给典型用户画个像。我在项目中遇到过最典型的三种车主：
| 用户类型 | 年龄 | 驾驶经验 | 技术接受度 | 核心需求 |
|---|---|---|---|---|
| 新手小白 | 22-30岁 | 1-3年 | 高（习惯触屏） | 安全、引导清晰、别让我分心 |
| 老司机 | 35-50岁 | 10年以上 | 中低（习惯物理按键） | 效率、盲操作、别搞花里胡哨的 |
| 科技发烧友 | 25-35岁 | 3-8年 | 极高（追求新功能） | 可玩性、自定义、OTA升级 |
关键点：新手最怕信息过载，老司机最怕操作延迟，科技控最怕功能太少。这三类人的需求经常打架，你得学会做取舍。
我记得有一次做用户访谈，一个开了20年车的老司机跟我说：「小伙子，我开车的时候眼睛只看路，手只摸方向盘。你这屏幕再好看，我也不会低头看。」这句话对我触动很大。从那以后，我设计任何界面都会问自己一句：这个信息，用户不看屏幕能知道吗？
3.2 驾驶场景分类
场景分析，说白了就是搞清楚「车在什么状态下，人在干什么」。我一般把驾驶场景分成三大类：
3.2.1 停车场景
这是用户最放松的时候。车停稳了，P档挂上，手刹拉好。这时候用户有充足的时间去操作屏幕。
- 典型行为：设置导航、调整座椅、连接蓝牙、刷视频
- 交互特点：可以接受多层级菜单、长文本输入、复杂设置
- 避坑指南：我曾经见过一个设计，停车时把空调界面藏到三级菜单里。用户找半天找不到，最后直接语音吼「开空调」——嗯，这其实是个好设计，但用户不这么想。
我的建议：停车场景下，可以适当增加视觉动效和反馈。比如调整座椅时，屏幕上显示座椅的3D模型实时变化。用户会觉得「哇，这车好智能」。
3.2.2 低速场景
堵车、倒车、找车位。车速低于30km/h。这时候用户处于「半放松」状态。
- 典型行为：切换音乐、查看360影像、接听电话、快速调整空调
- 交互特点：单手操作、视线离开路面不超过2秒、大按钮优先
- 注意：这时候千万别搞什么「长按3秒确认」的操作。你想想看，堵车时前车动了，你还在那长按屏幕，不追尾才怪。
3.2.3 高速场景
车速80km/h以上。这是最危险的场景。用户注意力几乎100%在路面上。
- 典型行为：几乎不操作屏幕，最多看一眼导航或车速
- 交互特点：语音控制为主、HUD抬头显示、物理按键盲操作
- 核心原则：能不看就不看，能不动就不动
警告：高速场景下，任何需要用户视线离开路面超过1.5秒的操作都是不合格的。我见过有些车厂把导航搜索框放在首页，用户一上高速就开始打字搜索目的地——这简直是谋杀。
3.3 任务流分析
任务流分析，就是拆解用户「想完成一件事」的完整路径。我习惯用「用户故事」的方式来梳理。
举个例子，用户想「设置一个去机场的导航」：
- 用户说「导航去机场」
- 系统识别语音，显示三个机场选项（浦东、虹桥、禄口）
- 用户说「浦东机场」
- 系统计算路线，显示三条推荐路径
- 用户选择「最快路线」
- 导航开始
看起来很简单对吧？但实际开发中，每个步骤都可能出问题。我曾经遇到过一个案例：
真实踩坑：语音识别把「浦东机场」识别成了「普通机场」。系统找不到这个地点，直接报错。用户一脸懵逼，只能靠边停车手动输入。后来我们加了一个「模糊匹配+确认」的机制，才解决这个问题。
任务流分析的核心，就是找出这些「断点」。我一般会用流程图把每个步骤画出来，然后问自己三个问题：
- 这个步骤用户需要看屏幕吗？
- 这个步骤用户需要动手吗？
- 如果出错，用户能轻松恢复吗？
嗯，这三个问题问完，80%的设计缺陷都能暴露出来。
3.4 用户研究与场景分析的落地方法
最后说说怎么落地。我个人的工作流是这样的：
| 阶段 | 方法 | 产出物 |
|---|---|---|
| 用户研究 | 访谈、问卷、日志分析 | 用户画像、需求列表 |
| 场景分析 | 实地跟车、视频录制 | 场景分类表、痛点清单 |
| 任务流分析 | 流程图、用户故事 | 任务流文档、交互原型 |
一个小技巧：做用户研究时，别光听用户「说」什么，要看他「做」什么。用户嘴上说「我想要更多功能」，实际开车时连空调都懒得调。相信我，行为比语言更诚实。
好了，这一章就到这里。下一章咱们聊聊信息架构——说白了就是「屏幕上的东西怎么摆」。到时候我会分享一些我踩过的坑，保证让你少走弯路。