第三章：驾驶场景与用户画像
大家好，我是老张。今天咱们聊聊驾驶场景和用户画像。说实话，这两个词在车机圈都快被说烂了。但真正做明白的团队，我数了数，真不多。
为什么？因为很多人把用户画像做成了「简历」。什么年龄、性别、收入，全往上堆。但你想想看，一个30岁的程序员和一个30岁的销售，开车时想要的东西能一样吗？
所以这节课，我带你从场景出发，倒推用户到底要什么。
3.1 典型驾驶场景分析
我先问个问题：你开车时最常用的三个功能是什么？
导航、通话、娱乐。对吧？我做了这么多年HMI，这三个场景几乎覆盖了90%的中控屏操作。但每个场景的「坑」都不一样。
3.1.1 导航场景：别让用户「迷路」在操作里
导航是驾驶场景的「刚需中的刚需」。但很多车机的导航交互，我看了都想砸屏幕。
核心痛点：
- 输入目的地太慢。你想想，车都开出去两个路口了，你还在拼音键盘上戳「天安门」三个字。
- 路线选择干扰多。弹窗问「您要走高速吗？」、「避开拥堵吗？」——我开车呢，哪有空看这些？
- 语音识别不靠谱。我说「去望京SOHO」，它给我导航到「望京soho」旁边的另一个楼。
我的经验：在导航场景下，用户的操作路径应该控制在「两步以内」。第一步：说出目的地。第二步：确认。超过两步，用户就会烦躁。我在项目中遇到过，某款车机的导航流程走了五步，结果用户反馈说「还不如用手机支架」。后来我们砍掉了所有非必要的确认弹窗，用户满意度直接提升了30%。
避坑指南：我曾经犯过一个错——在导航界面放了太多信息。什么周边加油站、美食推荐、实时路况，全堆在屏幕上。结果用户根本找不到「开始导航」的按钮。后来我学乖了：导航时，核心信息只有三个——路线、剩余时间、下一个动作。其他信息，要么收起来，要么等停车再看。
3.1.2 通话场景：安全第一，功能第二
通话场景，说白了就是「如何在开车时安全地打电话」。但很多车机把通话做得跟手机一样，这就有问题了。
核心痛点：
- 通话界面遮挡导航。我正开着导航呢，一个电话进来，导航画面被盖住了。等挂了电话，我已经错过两个路口了。
- 联系人搜索太慢。开车时翻通讯录？别闹了。
- 通话质量差。车噪、风噪、胎噪，对方根本听不清你在说什么。
我的建议：通话场景下，一定要做「分屏」或「画中画」。导航画面不能丢，通话界面可以缩小到角落。另外，语音拨号必须做到「一次唤醒，直接拨出」。别让用户说「打电话给张三」，然后系统问「确认拨打张三吗？」——这不是确认，这是添乱。
避坑指南：我曾经见过一个设计，通话时把导航声音完全静音了。结果用户一边打电话一边开车，错过了导航提示，直接开上了逆行道。嗯，这个设计后来被骂惨了。正确的做法是：通话时降低导航音量，但不能完全静音。
3.1.3 娱乐场景：别让「消遣」变成「消灾」
娱乐场景，包括听音乐、播客、收音机、甚至看视频（停车时）。这个场景最容易出问题的地方是——「操作太复杂」。
核心痛点：
- 切换歌曲/节目需要多次点击。开车时想切歌，结果要回到主界面、打开音乐App、找到播放列表、点击下一首——等你切完，歌都放完了。
- 内容推荐不精准。系统推荐了一堆你不喜欢的歌，你还要手动去点「不感兴趣」。
- 音效调节太专业。什么均衡器、环绕声、低音增强——用户只想听个响，你给人家整了个录音棚。
我的经验：娱乐场景的核心是「无感操作」。用户应该能用方向盘上的按键或者语音，直接完成切歌、调音量、换频道。我在项目中做过一个设计：用户说「下一首」，系统就切歌；说「换一个风格」，系统就推荐同类型的歌。结果这个功能上线后，使用率是其他娱乐功能的3倍。
避坑指南：我曾经在娱乐界面放了太多「高级功能」，比如「创建歌单」、「分享到社交平台」、「查看歌词」。结果用户反馈说「我只是想听个歌，你让我写作业呢？」后来我们把所有非核心功能都藏到了二级菜单，主界面只保留播放/暂停、上一首/下一首、音量调节。嗯，清爽多了。
3.2 用户画像构建方法
好，场景分析完了。接下来咱们聊聊用户画像。我见过很多团队做用户画像，就是拉个Excel表格，填上年龄、性别、职业，然后说「这就是我们的用户」。这不对。
真正的用户画像，应该基于「行为」和「场景」来构建。说白了，就是「谁在什么场景下，做了什么，为什么这么做」。
3.2.1 用户画像的四个维度
我个人习惯把用户画像拆成四个维度：
| 维度 | 说明 | 示例 |
|---|---|---|
| 基础属性 | 年龄、性别、职业、收入等 | 28岁，男性，互联网从业者，月入2万+ |
| 驾驶行为 | 驾驶频率、驾驶时长、驾驶风格 | 每天通勤2小时，喜欢开快车，经常跑高速 |
| 功能偏好 | 常用功能、使用频率、操作习惯 | 导航重度用户，喜欢听播客，很少用语音 |
| 痛点需求 | 使用中遇到的问题、未被满足的需求 | 导航输入太慢，通话时导航被遮挡 |
你看，光有基础属性是不够的。一个28岁的程序员，如果他每天开车通勤2小时，那他跟一个28岁但每周只开一次车的销售，需求完全不一样。
3.2.2 构建用户画像的步骤
我一般分三步走：
- 数据收集：通过用户访谈、问卷、后台日志，收集用户的行为数据。注意，不要只问「你喜不喜欢这个功能」，要问「你上次用这个功能是什么时候？当时发生了什么？」
- 行为聚类：把相似行为的用户归为一类。比如「导航重度用户」、「娱乐轻度用户」、「语音控」等等。
- 画像输出：给每一类用户起个名字，写一段「人物小传」。比如「通勤小王：28岁，每天开车上下班，单程40分钟，喜欢听播客，导航是刚需，但讨厌复杂的操作」。
我的建议：用户画像不要超过5个。太多的话，你根本记不住，设计时也会迷失方向。我一般只做3个核心画像：一个「重度用户」、一个「轻度用户」、一个「中间用户」。这样设计时就有明确的优先级了。
3.3 场景化设计原则
最后，咱们聊聊场景化设计的原则。说白了，就是「在什么场景下，给用户什么功能，怎么给」。
3.3.1 原则一：信息分层
驾驶场景下，用户的信息处理能力是有限的。你不能把所有信息都堆在屏幕上。
我习惯把信息分成三层：
- 第一层（核心信息）：驾驶时必须看到的信息。比如导航路线、车速、剩余电量/油量。这些信息要放在最显眼的位置，字体要大。
- 第二层（辅助信息）：驾驶时可能需要的信息。比如音乐播放状态、通话状态、天气。这些信息可以放在次要位置，或者用图标表示。
- 第三层（扩展信息）：停车时才需要的信息。比如设置、应用列表、车辆状态。这些信息要藏起来，别在驾驶时干扰用户。
我的经验：我在项目中做过一个设计，把导航信息放在仪表盘上，中控屏只显示娱乐和通话。结果用户反馈说「开车时不用转头看中控了，安全多了」。这就是信息分层的价值。
3.3.2 原则二：操作极简
驾驶场景下，任何操作都应该在「两步以内」完成。超过两步，用户就会分心。
怎么做到？
- 能用语音的，就别让用户动手。但语音要「一次唤醒，连续对话」，别让用户反复喊「你好，XX」。
- 能用快捷键的，就别让用户翻菜单。方向盘上的按键、中控台的旋钮，都要充分利用。
- 能自动化的，就别让用户选择。比如导航时自动避开拥堵，别问用户「要不要避开」。
注意：操作极简不等于功能缺失。而是把「高频操作」做到极致，把「低频操作」藏起来。我曾经见过一个设计，为了「极简」，把导航的「路线偏好」功能砍掉了。结果用户想走高速，系统非要走市区。嗯，这个设计后来被用户骂成了筛子。
3.3.3 原则三：场景自适应
车机应该能「感知」当前场景，并自动调整交互方式。
举个例子：
- 车辆高速行驶时，自动禁用视频播放和复杂操作。
- 车辆低速行驶或停车时，开放更多功能。
- 夜间驾驶时，自动切换深色模式，降低屏幕亮度。
这些听起来简单，但很多车机做不到。为什么？因为「感知」需要传感器和算法的支持。但作为设计师，你至少要在设计时考虑到这些场景。
我的建议：场景自适应不是「一刀切」。比如高速行驶时禁用视频播放，但可以允许用户通过语音切换音乐。别把用户的所有操作都禁了，那样反而会激怒用户。
3.4 小结
好，这节课的内容就到这里。咱们回顾一下：
- 典型驾驶场景：导航、通话、娱乐。每个场景都有不同的痛点，设计时要「对症下药」。
- 用户画像：别只盯着基础属性，要结合行为和数据来构建。3-5个核心画像就够了。
- 场景化设计原则：信息分层、操作极简、场景自适应。记住这三点，你的车机设计就不会跑偏。
下节课，咱们聊聊「多模态交互设计」。说白了，就是怎么让用户用语音、手势、触控、旋钮等多种方式跟车机交互。嗯，这个内容很有意思，到时候我给你们讲讲我踩过的坑。
下课。