3、用户研究与需求分析：目标用户画像、驾驶场景分析、用户痛点挖掘与需求优先级排序方法
座舱系统UI设计不同于一般的移动端或Web端设计，其核心差异在于“驾驶任务优先”这一铁律。任何界面元素的呈现、交互逻辑的编排、信息密度的控制，都必须服从于“减少驾驶员认知负荷、缩短视线离开道路时间”这一根本目标。因此，用户研究不能停留在泛泛的“用户访谈”层面，而必须建立一套面向驾驶场景的、可量化的、可追溯的需求分析方法论。本章将围绕目标用户画像的构建、驾驶场景的层次化拆解、用户痛点的结构化挖掘以及需求优先级排序的科学方法展开，帮助学员建立从“模糊用户”到“清晰需求”的完整转化链路。
上图展示了座舱UI用户研究与需求分析的整体链路。从用户画像出发，经过场景分析、痛点挖掘，最终形成需求优先级排序，并持续通过迭代验证进行修正。下方列出了该流程的核心输出物以及座舱UI设计必须遵循的三大铁律。接下来，我们将逐一深入每个环节的具体方法与实践要点。
3.1 目标用户画像：从“泛众”到“典型”的收敛
3.1.1 核心原理：为什么座舱UI不能只做“平均用户”
座舱系统的使用者覆盖从18岁新手到70岁老司机的广泛人群，其驾驶经验、认知能力、科技接受度差异巨大。如果按照“平均用户”设计，往往会导致新手觉得信息过载、老手觉得操作繁琐、科技爱好者觉得功能缺失。用户画像的核心价值在于：将庞大的用户群体划分为若干具有显著行为差异的“典型群体”，并针对每个群体的核心诉求进行针对性设计。在座舱场景中，画像维度不仅包括传统的人口属性（年龄、性别、收入），更关键的是“驾驶行为属性”和“技术接受度属性”。
| 画像维度 | 细分项 | 对UI设计的影响 |
|---|---|---|
| 驾驶经验 | 新手（<2年）、熟练（2-10年）、专家（>10年） | 新手需要更多引导和确认，专家追求效率与快捷键 |
| 科技接受度 | 极客型、实用型、保守型 | 极客型期待OTA与自定义，保守型需要稳定且熟悉的界面 |
| 主要出行场景 | 通勤、长途、网约车、家庭出行 | 通勤关注路况效率，长途关注舒适与娱乐，网约车关注接单效率 |
| 视觉与认知能力 | 正常、老花眼、色弱 | 影响字体大小、对比度、色彩编码策略 |
3.1.2 构建方法：数据驱动的画像生成流程
画像的构建不能依赖设计团队的主观臆测，而应基于真实数据。推荐采用“定量问卷+定性访谈+行为数据”三角验证法。首先，通过线上问卷收集500份以上有效样本，覆盖年龄、驾龄、车型、手机使用习惯等基础信息。其次，筛选出12-15名具有代表性的用户进行深度访谈，重点了解其驾驶习惯、对现有车机系统的抱怨与期待。最后，如果已有量产车型或测试车辆，应提取车机日志数据，分析用户实际的功能使用频率、页面停留时长、误触率等客观指标。
实战提示：在画像卡片中，除了基本信息外，务必加入“驾驶场景快照”和“核心UI诉求”两个字段。例如：“35岁男性，驾龄8年，科技接受度中高，主要通勤单程40分钟，最无法忍受导航路线不清晰导致的分心。” 这样的描述比“中年男性，白领”要有效得多。
3.1.3 案例拆解：某合资品牌B级车的用户画像收敛
某合资品牌在开发新一代座舱系统时，最初团队内部对“目标用户”争论不休。市场部认为是“30-40岁精英男性”，设计部认为是“科技尝鲜者”，而工程部则坚持“保守稳定派”。通过上述三角验证法，团队最终收敛出三类核心画像：“效率通勤族”（占比45%，驾龄5年以上，每日通勤1小时以上，最关注导航效率与语音交互）；“家庭安全官”（占比35%，多为有孩家庭，最关注儿童安全锁、后排娱乐控制与倒车影像清晰度）；“科技极客”（占比20%，年轻，期待OTA、自定义仪表盘、手机互联）。这一收敛直接决定了后续UI设计的信息架构——效率通勤族需要首页直达导航，家庭安全官需要一键进入儿童模式，科技极客则需要开放主题商店。
3.1.4 常见误区与复盘
- 误区一：画像数量过多。超过5个画像会导致设计资源分散，建议控制在3-4个核心画像。
- 误区二：画像描述过于抽象。“追求品质生活”这类描述无法指导设计，必须转化为具体的功能诉求和操作偏好。
- 误区三：忽略“乘客”角色。副驾与后排乘客也是座舱交互的重要参与者，尤其在娱乐与空调控制方面。
3.2 驾驶场景分析：从“道路环境”到“任务链”的拆解
3.2.1 核心原理：场景是需求之母
同样的功能在不同场景下，其UI呈现方式可能截然不同。例如“调节空调温度”，在高速巡航场景下，驾驶员可以短暂扫视中控屏完成操作；但在拥堵蠕行或复杂路口，任何非驾驶相关的操作都应被限制或转为语音控制。因此，场景分析的核心是建立“场景-任务-风险”的三元关联。场景分析需要从三个层级展开：宏观场景（城市/高速/乡村/夜间/雨雪）、中观场景（通勤高峰/长途自驾/停车等人/充电等待）、微观场景（具体驾驶操作链，如变道、超车、进出匝道）。
3.2.2 操作流程：构建场景-任务矩阵
- 场景枚举：通过头脑风暴与用户日志，列出所有可能的驾驶场景，至少覆盖30个以上。
- 任务链拆解：针对每个场景，拆解用户在该场景下的核心任务序列。例如“高速长途”场景的任务链为：设定导航→调节巡航速度→播放音乐/播客→监控剩余电量/油量→应对前车急刹。
- 风险评级：对每个任务在特定场景下的“分心风险”进行评级（高/中/低）。评级依据为：任务所需视觉注意时长、操作复杂度、与驾驶任务的冲突程度。
- 机会点识别：在矩阵中标记出“高风险+高频次”的交叉点，这些就是UI设计需要重点优化的区域。
风险警示：在场景分析中，最容易犯的错误是“静态化思考”。例如，认为“导航设置”只在出发前进行。实际上，超过60%的导航修改发生在行驶途中（如临时改变目的地、躲避拥堵）。因此，UI设计必须考虑“行驶中修改导航”的低交互成本方案，而非简单地将设置入口放在深层菜单。
3.2.3 实战场景：夜间高速场景的UI设计约束
以“夜间高速”这一典型高风险场景为例。环境变量包括：光照不足、车速高（100-120km/h）、驾驶员视野收窄、对远光灯敏感。在此场景下，用户的核心任务是保持车道、监控车速、关注导航出口。对应的UI设计约束为：① 仪表盘必须采用深色背景，避免高亮度白色界面造成眩光；② 导航信息应投射到HUD或仪表盘中央，减少视线转移；③ 所有非关键通知（如天气推送、APP更新）应自动屏蔽或转为语音播报；④ 触控按键需增大热区并增加物理反馈或声音确认，因为路面振动可能导致误触。通过这种场景驱动的分析，设计团队能明确写出“夜间模式”的具体设计规范，而非仅仅提供一个“暗色主题”的简单开关。
3.2.4 总结复盘
场景分析不是一次性的工作，而应形成“场景库”并持续迭代。建议使用版本化管理场景文档，每次OTA或新功能开发时，都需对照场景库进行影响评估。同时，场景分析应邀请真实用户参与验证，通过模拟驾驶舱或实车测试，确认任务链拆解是否符合实际行为。
3.3 用户痛点挖掘：从“表面抱怨”到“深层需求”
3.3.1 核心原理：痛点=期望-体验
用户痛点并非总是直接表达为“我不喜欢这个界面”。更多时候，痛点隐藏在用户的行为妥协中。例如，用户很少说“这个音乐播放界面切换太慢”，而是表现为“我开车时基本不切歌，太麻烦了”。因此，痛点挖掘需要综合运用多种方法，将用户的隐性不满显性化。常用的方法包括：情境访谈（在实车或模拟器中观察用户操作）、日记研究（记录用户一周内的用车抱怨）、车机日志分析（查找功能使用率低、操作路径长、频繁返回的节点）、售后投诉分析（客服系统中关于“屏幕”“导航”“连接”的投诉关键词）。
3.3.2 挖掘方法：五步法
| 步骤 | 方法 | 关键产出 |
|---|---|---|
| 1. 行为观察 | 在模拟驾驶舱中布置任务，观察用户操作路径、犹豫点、错误点击 | 操作热力图、任务完成时间、错误率 |
| 2. 深度追问 | 针对观察到的异常行为进行回溯式访谈，“刚才你为什么要返回上一页？” | 用户心智模型与界面逻辑的差异点 |
| 3. 数据交叉验证 | 将日志数据（如某功能使用率<5%）与访谈内容交叉比对 | 确认是功能无用还是入口太深 |
| 4. 严重度分级 | 按“影响范围×发生频率×安全风险”三维度打分 | P0（安全相关）、P1（高频严重）、P2（低频烦扰） |
| 5. 需求转化 | 将痛点描述转化为“用户故事”格式：作为[角色]，我想要[功能]，以便[价值] | 可进入需求池的条目 |
3.3.3 案例拆解：导航音量与媒体音量的冲突
在某车型的用户反馈中，大量用户抱怨“导航播报时音乐声音忽大忽小，很突兀”。表面痛点似乎是“音量调节不智能”。通过日志分析发现，用户手动调节音量的频率在导航播报前后显著增加。进一步情境访谈揭示深层痛点：用户并非反感音量变化，而是反感“变化过于突兀”且“无法分别记忆导航与媒体的独立音量”。最终需求被重新定义为：提供“导航混音模式”设置，支持“压低音乐”“完全暂停”“并行播放”三种模式，并允许用户为导航和媒体分别设置默认音量。这一需求转化直接指导了音频架构的UI设计，上线后相关投诉下降80%。
经验提醒：在挖掘痛点时，务必区分“伪需求”与“真痛点”。判断标准是：用户是否愿意为该功能改变既有行为习惯？该功能是否解决了高频场景下的核心障碍？例如，“在仪表盘上显示微信消息”可能是伪需求，因为其安全风险大于便利性。
3.3.4 常见误区
- 误区一：将“用户建议”当作“用户需求”。用户说“我想要一个大屏幕”，真实需求可能是“我想看清导航信息”，解决方案可以是HUD或更好的信息层级。
- 误区二：忽视“安全相关”痛点。用户可能不会主动提及“我因为看屏幕差点追尾”，但这类痛点必须通过行为观察主动识别。
- 误区三：痛点清单过于冗长。缺乏严重度分级会导致设计团队无从下手，必须强制使用P0/P1/P2分级。
3.4 需求优先级排序：从“想要”到“先做”的决策
3.4.1 核心原理：座舱UI的排序特殊性
传统互联网产品的优先级排序常采用“用户价值/开发成本”的二维矩阵。但座舱UI必须额外引入“安全影响”和“驾驶分心度”两个维度。一个功能即使商业价值很高，如果会显著增加驾驶分心，也必须降级或重新设计交互形式。因此，推荐采用RICE-H（Reach, Impact, Confidence, Effort, Hazard）模型，即在标准RICE基础上增加“危险系数（Hazard）”。
3.4.2 排序方法：RICE-H评分表
| 维度 | 定义 | 评分标准（1-5分） |
|---|---|---|
| Reach (触达) | 该功能影响的用户比例/场景频率 | 5=影响核心画像的日常场景；1=仅影响边缘场景 |
| Impact (影响) | 对用户体验提升的程度 | 5=解决P0痛点；1=锦上添花 |
| Confidence (信心) | 对需求真实性的把握 | 5=有数据+访谈双重验证；1=纯属猜测 |
| Effort (成本) | 设计+开发+测试的总人日 | 5=小于5人日；1=大于30人日 |
| Hazard (危险) | 该功能在驾驶中使用的潜在分心风险 | 5=几乎无风险（如语音反馈）；1=高风险（如复杂触控输入） |
最终得分计算公式为：优先级分数 = (Reach × Impact × Confidence × Hazard) / Effort。分数越高，优先级越高。其中Hazard作为乘数，意味着任何高危险系数的功能，即使其他维度得分很高，也会被显著降权。
3.4.3 操作流程：从需求池到迭代计划
- 需求池清洗：合并重复项，剔除不可实现项，明确每个需求的验收标准。
- RICE-H评分：由产品经理、设计负责人、技术负责人、安全工程师共同打分，取平均值以减少偏见。
- 分类策略：根据分数将需求分为P0（本迭代必须完成）、P1（下迭代）、P2（ backlog）。
- 风险复审：对P0中的高Hazard需求，组织专项评审，确定是否需调整交互形式（如从触控改为语音）。
实战案例：某新势力车企在规划首次OTA时，需求池中有“游戏中心”（高Reach、高Impact、高Effort、高Hazard）和“语音调节座椅”（中Reach、中Impact、低Effort、低Hazard）。按传统RICE，游戏中心可能胜出。但加入Hazard维度后，游戏中心因驾驶分心风险被降为P2，而语音调节座椅成为P0。最终该OTA以“安全与效率”为主题，上线后用户满意度提升显著，且未发生因游戏功能引发的安全事故。
3.4.4 总结复盘与注意事项
- 排序不是一劳永逸：随着法规变化（如新的ADAS功能强制要求）或用户反馈，优先级需每季度重新评估。
- 避免“安全绑架”一切：过度强调Hazard会导致产品功能匮乏。正确的做法是，对于高价值但高Hazard的需求，投入设计资源寻找“低分心”的交互方案，而非直接否决。
- 记录决策上下文：每次排序决策都应记录当时的评分依据和讨论要点，以便后续追溯“为什么这个功能被推迟”。
通过本章的方法论，学员应能够独立完成从用户画像构建到需求优先级排序的完整闭环。核心在于始终将“驾驶安全”作为最高准则，同时用数据驱动的方法确保需求分析的专业性与可落地性。在实际项目中，这套流程通常需要2-3周的集中投入，但产出的需求池和设计约束将极大提升后续原型设计与开发评审的效率。