第三章：信息架构设计——车载信息层级划分、功能优先级排序、卡片式布局逻辑

好，咱们进入第三章。这一章我特别想跟你聊聊，因为信息架构这东西，说白了就是「把东西摆对位置」。

我在做车载HMI的早期，踩过一个坑。当时觉得功能越多越好，把所有设置项都塞进一级菜单。结果呢？用户开车时想调个空调温度，得翻三页。嗯，那版方案被测试团队骂得很惨。

所以今天咱们就好好拆解一下，车载信息架构到底该怎么搭。

3.1 车载信息层级划分：三层就够了

我个人习惯把车载信息分成三个层级。别搞太复杂，三层刚刚好。

层级	定义	典型内容	交互要求
一级（驾驶层）	驾驶过程中必须快速访问的信息	导航、车速、续航、空调温度	1步操作，0.5秒内响应
二级（任务层）	停车或等红灯时操作的常用功能	音乐切换、座椅调节、驾驶模式	2-3步操作，1秒内响应
三级（设置层）	车辆设置、系统偏好等低频操作	蓝牙配对、灯光设置、系统更新	3-5步操作，可接受短暂等待

你想想看，开车时最怕什么？分心。所以一级信息必须「一眼看到，一触即达」。我在项目中遇到过，有些团队非要把导航和音乐放在同一级，结果用户想切歌时，导航路线被遮挡了。这其实是个很危险的交互设计。

3.2 功能优先级排序：别让用户做选择题

功能优先级排序，说白了就是「什么功能该放在最显眼的位置」。我建议用这个四象限法则来判断：

• 高频+高安全关联：导航、车速、续航 → 常驻显示，不可隐藏
• 高频+低安全关联：音乐、音量、空调 → 快捷入口，可折叠
• 低频+高安全关联：紧急呼叫、故障报警 → 特殊触发，全局置顶
• 低频+低安全关联：座椅按摩、氛围灯 → 三级菜单，不占主屏

为什么会这样排？因为人的注意力是有限的。我曾经在某个项目中，把座椅加热按钮放在了首页，结果用户开车时误触，烫得跳起来。嗯，从那以后我就明白了——不是所有功能都配上一级入口。

3.3 卡片式布局逻辑：模块化、可拖拽、自适应

卡片式布局，现在基本是车载HMI的标配了。为什么？因为它天然适合「信息分组」和「动态调整」。

我个人习惯把卡片分成三种类型：

• 固定卡片：导航、车速、续航 → 位置固定，不可移动
• 动态卡片：音乐、空调、通话 → 可根据使用频率自动排序
• 临时卡片：来电提醒、低电量警告 → 出现后自动消失

这里有个关键点：卡片的大小和内容密度，必须跟驾驶场景匹配。举个例子，导航卡片在行驶中应该放大，显示路线信息；停车时则可以缩小，让出空间给音乐或视频。

// 伪代码示例：卡片优先级动态调整
if (vehicleSpeed > 0) {
    navigationCard.setSize(LARGE);
    musicCard.setSize(SMALL);
    videoCard.setVisibility(HIDDEN);
} else {
    navigationCard.setSize(MEDIUM);
    musicCard.setSize(MEDIUM);
    videoCard.setVisibility(VISIBLE);
}

你想想看，如果开车时视频卡片还显示在屏幕上，那得多危险。所以卡片布局一定要跟车辆状态绑定。

3.4 实战案例：一个典型的主页布局

好了，理论讲完了，咱们看一个实际案例。这是我参与过的一个项目，最终落地的方案：

区域	内容	卡片类型	优先级
顶部状态栏	时间、信号、电量、温度	固定卡片	P0
左侧主区域	导航地图（行驶中放大）	固定卡片	P0
右侧快捷区	音乐、空调、通话（可切换）	动态卡片	P1
底部 Dock 栏	主页、车辆设置、应用列表	固定卡片	P2

这个布局的好处是：驾驶时，导航占据视觉中心；停车时，右侧快捷区可以展开成完整卡片。说白了，就是「动态适应场景」。

下一章咱们聊聊「手势交互与触控反馈」，到时候我会分享一些关于「误触」的血泪史。嗯，先卖个关子。