3、信息架构设计：信息层级划分、导航逻辑设计、仪表盘信息优先级排序策略

3.1 信息层级划分——别让司机当侦探

做仪表盘HMI，第一个要解决的问题就是：什么东西该放在哪。

我见过不少项目，设计师恨不得把所有数据都堆在眼前。车速、转速、油耗、胎压、导航、音乐、电话……全挤在一个屏幕上。结果呢？司机开车时得像个侦探一样找信息，这太危险了。

我个人习惯把信息分成三个层级：

• 一级信息（感知层）：车速、转速、电量/油量、关键报警。这些是驾驶时必须扫一眼就能获取的。
• 二级信息（交互层）：导航指引、多媒体状态、ADAS信息。这些是驾驶中偶尔需要查看的。
• 三级信息（设置层）：车辆设置、行程数据、系统状态。这些是停车或非驾驶状态下才看的。

说白了，一级信息要大、亮、稳。二级信息要可隐藏、可切换。三级信息……嗯，最好别出现在主驾驶视野里。

3.2 导航逻辑设计——别让用户迷路

仪表盘的导航逻辑，跟手机APP完全是两码事。手机你可以慢慢划，仪表盘不行。司机的手在方向盘上，眼睛在路上，操作必须盲操友好。

我建议采用「树形结构 + 快捷直达」的混合模式：

• 主菜单：通过方向盘按键左右切换（如：行车信息 → 导航 → 媒体 → 设置）。
• 子菜单：通过上下键或滚轮选择，层级不超过3层。
• 快捷返回：任何时候按「返回」键或「Home」键，直接回到一级信息界面。

举个例子，我在一个项目中遇到过这样的问题：用户想调整仪表盘亮度，结果要按5次按键才能找到设置项。后来我们改成了「长按菜单键直接进入亮度调节」，用户反馈好多了。

3.3 仪表盘信息优先级排序策略

信息优先级排序，说白了就是「什么信息在什么场景下最重要」。

我总结了一个简单的排序矩阵，你想想看：

信息类型	驾驶场景	优先级	显示策略
车速	全场景	最高	始终显示，居中或左侧
报警（刹车、胎压等）	异常时	最高	弹窗+声音，覆盖所有内容
导航转弯提示	导航中	高	靠近车速区域显示
媒体信息	非导航时	中	可折叠，默认显示歌名
行程数据	停车/巡航	低	二级菜单查看

这里有个关键点：优先级不是固定的。比如，正常行驶时，胎压是二级信息。但一旦胎压异常，它立刻变成最高优先级，甚至要覆盖车速显示。

我习惯用「状态机」来管理这个逻辑：

// 伪代码示例
enum DriveState {
  NORMAL,       // 正常行驶
  NAVIGATING,   // 导航中
  ALERT,        // 报警状态
  PARKING       // 停车
}

function updatePriority(state) {
  switch(state) {
    case NORMAL:
      showSpeed(); showRPM(); hideNav();
      break;
    case NAVIGATING:
      showSpeed(); showTurnHint(); collapseMedia();
      break;
    case ALERT:
      showAlert(); overlayAll();
      break;
    case PARKING:
      showTripData(); showSettings();
      break;
  }
}

3.4 实战中的取舍

理论说完了，聊聊实际落地。

有一次，产品经理非要在一级界面显示「瞬时油耗」和「平均油耗」。我说不行，信息太多了。他说用户想看。最后我们做了个A/B测试：

• A组：显示瞬时油耗 + 平均油耗
• B组：只显示平均油耗，瞬时油耗放在二级菜单

结果呢？A组用户普遍反映「信息太多，开车分心」。B组用户觉得「够用，需要时也能找到」。你看，用户嘴上说想要，实际用起来根本不是那么回事。

所以我的建议是：永远相信数据，而不是直觉。做信息架构时，先做减法，再做加法。能隐藏的绝不显示，能合并的绝不分开。

嗯，最后总结一句：仪表盘信息架构设计的本质，不是「展示更多」，而是「在正确的时间，展示正确的信息」。