信息架构基础：定义、五要素与汽车HMI中的应用
各位同学，今天我们来聊聊信息架构。说实话，很多刚入行的设计师觉得信息架构就是画个菜单树，其实远不止如此。我做了这么多年HMI，踩过最大的坑，就是信息架构没想清楚，结果后期改来改去，开发兄弟差点跟我翻脸。
一、信息架构的定义与五要素
信息架构，说白了就是把复杂的信息组织起来，让用户能快速找到想要的东西。在汽车HMI里，这个定义尤其重要——你想想看，驾驶员在高速上找导航目的地，多花一秒钟都可能出危险。
信息架构有五要素，我习惯用它们来检验每个设计方案的合理性：
| 要素 | 定义 | 汽车HMI中的例子 |
|---|---|---|
| 组织系统 | 信息如何分类和分组 | 车辆设置按「驾驶」「舒适」「安全」分组 |
| 标签系统 | 每个信息项叫什么名字 | 「能量回收」还是「动能回收」？ |
| 导航系统 | 用户如何在信息间移动 | 从空调界面跳转到座椅加热 |
| 搜索系统 | 用户如何查找特定信息 | 语音搜索「最近的充电站」 |
| 内容 | 实际展示的信息本身 | 续航里程、胎压数值、导航路线 |
我的经验：五要素中，最容易出问题的是「标签系统」。我曾经在一个项目中，工程师把「驾驶模式」写成了「行驶模式」，结果用户反馈找不到。嗯，一个词的区别，用户就是不认。
二、汽车HMI中的信息分类模型
汽车里的信息量其实很大。仪表盘、中控屏、HUD、后排娱乐……每个屏幕都有自己的信息。怎么分类？我一般用三层模型：
1. 按优先级分类
- 一级信息：驾驶安全相关。车速、续航、故障报警。这些必须一眼看到。
- 二级信息：驾驶辅助相关。导航提示、音乐播放、空调状态。可以稍作交互。
- 三级信息：娱乐与设置。车辆设置、应用商店、用户手册。可以藏在深层菜单。
2. 按使用频率分类
- 高频：空调温度、音量调节、导航目的地。放在首页或快捷栏。
- 中频：座椅记忆、驾驶模式切换。放在二级菜单。
- 低频：系统更新、恢复出厂设置。放在设置深处。
3. 按信息类型分类
- 车辆状态：胎压、油量、里程
- 导航信息：路线、路况、POI
- 娱乐内容：音乐、视频、电台
- 通讯信息：电话、消息、日程
避坑指南：我曾经把「车辆状态」和「导航信息」混在一起，结果用户想查胎压，翻了三页才找到。后来我强制自己：每个信息只属于一个分类，不要交叉。
三、用户心智模型与信息架构的关系
心智模型，就是用户心里认为这个系统应该怎么工作。举个例子，用户觉得「空调温度」应该在「空调」下面，而不是在「车辆设置」里。你非要反着来，用户就会觉得这车「反人类」。
我总结了几条经验：
- 用户的心智模型来自日常经验。比如手机上的「设置」图标是个齿轮，汽车上也用齿轮，用户就秒懂。
- 不要挑战用户的习惯。用户习惯了「左减右加」调音量，你非要做成「上滑增加」，用户会骂娘。
- 如果必须创新，给用户学习路径。比如特斯拉的触控换挡，虽然颠覆，但给了清晰的引导动画。
我的一个教训：有一次我设计了一个「智能推荐」功能，把空调、座椅、音乐打包成一个场景。我觉得很酷，但用户完全找不到入口。为什么？因为用户的心智模型里，空调就是空调，座椅就是座椅，他们不会想到去一个叫「场景」的地方找。后来我改成了在空调界面加一个「推荐场景」按钮，用户才接受。
四、如何将心智模型映射到信息架构
具体怎么做？我一般分三步：
第一步：用户研究
找真实用户，让他们描述「你觉得这个功能应该在哪里」。别问「你觉得信息架构怎么设计」，用户听不懂。直接问「你想调座椅加热，你会先点哪里」。
第二步：卡片分类
把功能写在卡片上，让用户自己分组。你会发现，用户的分组方式和你想象的完全不一样。我做过一次，用户把「导航」和「音乐」放在一起，理由是「开车时最常用」。嗯，有道理。
第三步：原型测试
画个低保真原型，让用户走一遍任务。看他们会不会迷路。如果三个用户都在同一个地方卡住，那就是信息架构有问题。
注意：不要完全照搬手机的信息架构。汽车是驾驶环境，用户注意力有限。手机可以藏三级菜单，汽车最好两级以内搞定。我曾经把手机上的「九宫格」直接搬到车机上，结果被测试用户骂「开车时根本点不准」。
五、总结一下
信息架构不是画个树状图就完事了。它要回答三个问题：
- 用户要找什么？
- 用户觉得它在哪里？
- 用户怎么最快找到它？
我个人习惯，每次设计前先画一张「信息架构草图」，贴在工位上。然后每天问自己一遍：如果我是用户，我能三秒内找到空调开关吗？如果答案是否定的，那就重来。
下一节课，我们会讲具体的导航设计模式。到时候我会分享一些实际项目的代码示例，嗯，保证干货满满。
课后小练习：找一辆你熟悉的车，打开它的中控屏，把每个功能按「优先级」「频率」「类型」三个维度分类。看看它的信息架构有没有问题。如果有，你会怎么改？