Se Connecter Maintenant 人的大脑毕竟不是无限容量的硬盘。面对动辄几十个模块的复杂产品，单靠硬记逻辑，很容易把自己绕进死胡同。这时候，一张信息结构图往往能帮人理清头绪，把散乱的数据重新归位。之前聊过功能结构图，不少朋友留言问它和信息结构图的区别。今天我们就专门把镜头对准后者，聊聊这张图该怎么看、怎么用。
其实，信息结构图并不玄乎。我们每天刷手机，本质上就是在跟信息打交道。打开微信通讯录，头像、昵称、上次聊天时间是信息；点进聊天页，消息的文本或语音类型同样是信息。这些信息从来不是孤立的，它们天然带有层级。拿企业员工档案来说，如果把姓名、身份证号、入职时间、合同期限、学历一股脑堆在一起，谁看谁头疼。但一旦按逻辑拆成基本信息、入职记录、工作履历等维度，杂乱的数据瞬间就清晰了。所谓信息结构图，就是把描述某个核心对象的数据，按照业务逻辑合理分组拆解，最终拼成一张“数据地图”。
这张图最实在的价值，在于它是功能背后的“原材料清单”。用户看到的产品是功能，但底层跑着的其实是信息。以“发送好友名片”为例，用户感知的是分享动作，系统实际执行的，是把一个完整的名片对象传给对方。功能像锅，信息是米。巧妇难为无米之炊，没有底层字段支撑，再精致的交互也跑不起来。很多设计者容易沉迷页面效果，却忘了功能只是载体，真正让产品运转的是那些静默的字段。微信能衍生出通讯录、名片编辑、标签管理等一系列功能，正是因为它把好友信息拆解得足够清晰。信息结构图要做的，就是把“米”提前分类装好。
另一个关键点，新手往往容易混淆：信息结构图和页面布局、交互逻辑是解耦的。画图时如果习惯把页面当对象、把模块当子节点，画出来的其实是线框图的翻版，不是信息结构图。同一套信息为了适配不同场景，必然会分散在多个页面里。比如好友的备注名和头像，既出现在通讯录列表，也显示在详情页，还会用在消息卡片中。字段还是那些字段，只是露出的场景不同。信息结构图只管把对象本身描述清楚，至于信息在哪调用、怎么跳转，那是原型和交互设计的事。把信息和页面拆开看，思路才不会打结。
为什么一定要画它？最直接的原因，是它能对抗人类的认知局限。心理学研究表明，人的短期记忆容量大概在七加减两个信息块。设计简单功能或许能靠脑子理顺，但一旦业务复杂起来，牵扯几十个对象和成百上千个字段，硬画原型难免顾此失彼。有了信息结构图打底，做原型就不再是凭空捏造，而是按图索骥。比如设计服务评价模块，明确了订单ID、提交时间等基础信息后，设计师只需按需抽取：提交页放整体评分和服务维度，成功页只留核心结果，再补上引导文案。每个页面该留什么、舍什么，一目了然。
往深了说，它还是产品与开发之间的翻译器。产品经理习惯从需求和流程出发，工程师的第一反应却是数据表怎么建、接口怎么定义。如果方案只停留在页面描述，开发拿到后还得自己反推数据模型，沟通成本直线上升。反之，如果产品能提前把功能背后的对象和字段穷举清楚，就等于直接递上了数据库设计的草稿。少一点返工，项目推进自然顺畅得多。
具体怎么落地？核心就两步。第一步，找准信息主体。任何结构图都围绕核心对象展开。比如给行政部做图书管理，要满足查书、找作者、办借阅，那么图书、作者、出版社、借阅记录就是明确的信息主体。第二步，按业务价值筛选字段。新人常犯的毛病是“信息大爆炸”，能想到的全往上堆，画原型时才发现一半用不上，该用的却漏了。问题出在脱离了实际场景。描述一本书的字段能列出一长串：ISBN、版次、装帧、开本、纸张重量……但行政图书管理只需要最核心的：编号、书名、作者、出版社、借阅状态。只有能支撑当前功能，或为后续迭代预留空间的字段，才值得放进图里。做减法，往往比做加法更重要。
说到底，功能结构图解决业务怎么走的问题，信息结构图解决数据怎么存的问题。两者分工明确，在实际工作中互补。建议在日常设计流程里养成一个习惯：先梳理功能边界，再拆解信息底盘，最后才是画原型。把信息结构理顺了，后续的页面设计和交互流转自然能走得稳健从容，跨团队协作也会轻盈许多。设计从来不是盲目堆砌功能，而是用清晰的逻辑去驾驭复杂的信息。