看信息架构还是很多年前的事情了，大概是在 2010 年吧，有一本叫《Web 信息架构》的书，当时还在一线，想去做一个架构师，看到架构两个字就冲动买了下来。

有道是「买书一时爽，读书火葬场」

当然，这本书后面还是看完了，和想象中的不一样，但是也提升了自己某些方面的认知，现在回想起来还是有一些作用的，至少知道了一些信息架构的基本逻辑，在 battle 的时候也有一些逻辑来讲了。

最近回顾架构师必备的一些知识点，回想起来，也是必备点之一，于是温故一下。

为什么架构师要懂信息架构

大多数技术架构师在设计系统时，90% 以上的精力放在了技术实现上，却忽略了最终用户如何使用这个系统。

以下这样的场景我们应该都见过：

• 功能强大的 ERP 系统，员工需要培训一个月才能熟练使用
• 配置灵活的中台管理系统，业务人员宁愿用 Excel 也不愿意打开
• 技术先进的数据平台，分析师找个报表要点击七八次

这些系统在技术层面可能已经不错了，但在信息组织和呈现上却是不尽人意。

作为架构师，我们不仅要考虑系统怎么实现，还要考虑信息怎么组织、怎么流转、怎么被用户理解和使用。这就是信息架构要解决的问题。

信息架构到底是什么

提到信息架构，很多技术同学的第一反应是：”这不是产品经理或 UX/UI 设计师的事吗？”

有些偏了。用一个简单的类比来解释一下：

如果把系统比作一座大楼，技术架构就像是大楼的钢筋混凝土结构，决定了楼能建多高、承重多少。而信息架构则像是大楼的空间布局和导视系统，决定了人们在楼里能不能找到想去的地方。

更准确地说，信息架构 = 信息 + 架构。

这里的「信息」是指用户需要理解和使用的所有内容：

• 功能：系统能做什么（订单管理、库存查询、报表统计）
• 内容：系统展示什么（商品信息、客户资料、交易记录）
• 概念：系统如何定义事物（什么是”订单”、”客户”、”库存”）
• 流程：任务如何完成（下单流程、退货流程、审批流程）

同时也包括用户在 Web 上可以看到的文本、图片、影音等元素。

而”架构”则是如何组织这些信息：

• 分类：按什么逻辑分组（按部门？按流程？按对象？）
• 层级：分几层，每层放什么
• 关联：不同信息之间如何连接
• 路径：用户如何找到需要的信息，如导航，搜索

根据维基百科的定义：信息架构（英语：Information Architecture，缩写IA）是在信息环境中，影响系统组织、导览、及分类标签的组合结构。它是也基于信息架构方法论，并运用内容管理技术来管理和组织信息的一个专门学科。

理查德·索·乌尔曼（Richard Saul Wurman）在 1976 年创造了”信息架构”这个术语。他当时面对的问题，在今天看来更加严峻——信息爆炸。

人类认知的局限与信息架构的价值

人类感官系统每秒可以接收 高达 10 亿比特的信息（如视网膜、听觉系统等能高速采集大量感官数据），但我们大脑用于行为和认知的信息处理速度却极为有限。

根据 2025 年 4 月发表于《Neuron》期刊的综述文章《The unbearable slowness of being: Why do we live at 10 bits/s?》，美国加州理工学院的研究团队通过实验和信息论分析发现：

人类大脑在执行诸如打字、说话、阅读、听力理解等任务时，信息处理速度平均只有约 10 比特/秒。

量化理解大概是这样：

• 英语听力理解：约 13 比特/秒
• 打字行为：约 10 比特/秒（100词/分钟 ≈ 10 bits/s）
• 语言表达、复杂任务处理：也普遍维持在 10 bits/s 左右

这就像：

“感官系统是一个每秒吸入瀑布的超级吸尘器，而大脑处理系统是只能一滴一滴滴水的慢筛子。”

刻意注意一下，你会发现你每天会见到很多的人和事，实际能在你脑海里面留下印象的寥寥无几。

我们大脑处理信息的速度这么慢，其实就像你用一个老旧手机加载高清视频，根本带不动。这时候，最重要的不是往里塞更多内容，而是怎么把内容排好、简化、分清主次。这就是信息架构的价值：它就像一个聪明的「内容管家」，帮你把复杂的信息分门别类、有序呈现，让大脑不至于崩溃。不是你记不住，而是信息没被安排好。

我们刷网页、看报告、看PPT，很多时候不是内容不好，而是太乱，不知道看哪里，不知道重点在哪。大脑每秒只能处理 10 比特的信息，就像一个只能看一小角的手电筒，所以信息架构的作用就是：把重要的东西放在光照能到的地方，其他的先收起来，或者慢慢来。这种结构化的呈现，既是对读者的呵护，也是对注意力的尊重。

无论我们是在做一份 PPT 汇报、写一篇文章，还是在设计一个产品页面，真正的挑战不是“讲得多厉害”，而是让人听懂、记住，并且愿意继续往下看。这就要求我们站在对方的认知角度去思考，用结构帮他减少思考负担。换句话说：做内容不是堆信息，是搭桥——在信息和人之间，搭一座他们能走得过去的桥。

架构师会遇到的信息架构场景

架构师在实际工作中会遇到的信息架构场景：

1. 系统功能菜单设计：虽然通常由产品负责，但架构师需要评估：功能模块如何分组？菜单层级是否合理？是否与底层服务划分一致？
2. 业务概念统一：同一个业务实体在不同模块中的命名是否一致？比如”客户”在 CRM 中叫 Customer，在订单中叫 Buyer，在财务中叫”付款方”，这种不一致会从代码层面影响到用户理解。在实际工作过程中，微服务的拆分和设计，领域建模，数据加设计都需要基于业务概念统一来做。
3. API 对外暴露的信息组织：对外 API 的资源如何分类和命名？开发者文档的组织结构？这直接影响外部开发者对系统的理解。
4. 错误信息体系：用户能看到的错误提示如何分类？错误码如何设计才能让用户（包括运维人员）快速理解问题？再远一些会涉及监控系统和监控指标的设计。
5. 多端信息一致性：Web、App、小程序等多端的功能和信息如何保持一致？哪些功能在哪些端出现？
6. 系统集成时的信息映射：当多个系统集成时，如何统一不同系统中的概念和术语？如何设计统一的信息视图？

架构师的技术决策会直接影响用户（包括最终用户、运维人员、开发者）对系统的理解和使用。

构建信息架构的核心系统

信息架构不是简单的分类和排序，一般包含四个核心系统：

1. 组织系统：如何分类信息

组织系统是信息架构的基础，它决定了我们用什么维度和逻辑来分类信息。就像图书馆需要决定是按主题、作者还是出版时间来排列书籍，系统设计时也需要选择合适的组织原则——是按业务流程、用户角色、数据对象，还是使用场景来组织功能和内容。这个选择没有绝对的对错，关键在于是否符合用户的心智模型和使用习惯。

常见的组织方式包括：按字母或时间的精确型组织（适合已知查找目标的场景）、按主题或任务的模糊型组织（适合探索式浏览的场景），以及混合型组织。比如电商系统，商品分类采用层级主题（服装>男装>衬衫），订单查询采用时间序列，用户中心采用任务分组（我的订单、我的收藏、账户设置）。每种组织方式服务于不同的用户需求和使用场景。到底按照什么维度进行单一归类还是进行矩阵归类，这就是我们的组织系统要解决的问题。

架构师在设计时最容易犯的错误是按技术实现来组织信息，而不是按用户理解来组织。比如把”用户注册”放在”用户服务”模块下，把”下单”放在”订单服务”模块下，看似合理，但用户可能期望在”开始购物”这个流程中完成所有操作。好的组织系统应该让用户感觉自然和直观，而不是需要理解你的技术架构才能找到想要的功能。

2. 标签系统：如何命名信息

标签系统定义了如何命名系统中的各个信息节点，包括功能名称、按钮文案、图标选择等所有用户可见的标识。它就像路标系统，决定了用户能否快速理解每个元素的含义和作用。一个好的标签应该既准确又易懂，既符合业务语言又贴近用户认知。比如，同样是查看历史数据的功能，叫”数据回溯”还是”历史记录”，给用户的感受完全不同。

标签设计的核心挑战在于平衡专业性和通俗性。企业内部可能习惯了专业术语，比如”SKU管理”、”履约中心”、”清结算”，但对于普通用户来说，”商品管理”、”订单处理”、”对账”可能更容易理解。图标的选择也是如此，一个购物车图标比一个抽象的立方体更能让人联想到”订单”。标签系统需要建立一套统一的命名规范和词汇表，确保同一概念在整个系统中保持一致，避免用户困惑。

架构师虽然不直接负责界面设计，但在定义服务、接口、数据模型时的命名选择，会深刻影响最终的标签系统。同样是”用户”这个概念，在不同模块里分别叫User、Account、Member、Customer，这种不一致性很容易延续到界面层，造成用户理解困难。

3. 导航系统：如何浏览信息

导航系统定义了用户在系统中移动的方式和路径，它不仅包括显式的菜单、面包屑、标签页，还包括隐式的链接、快捷操作、上下文跳转等。一个好的导航系统应该让用户始终知道三件事：我在哪里（当前位置）、我能去哪里（可达路径）、我怎么回去（返回机制）。就像商场的导购图，不仅要标明店铺位置，还要提供多条到达路径，以及紧急出口的位置。

导航设计需要考虑不同用户的使用模式：新手用户倾向于使用全局导航逐层探索，熟练用户更喜欢搜索和快捷入口，专家用户可能需要自定义常用功能。因此，一个完整的导航系统通常包含多个层次：全局导航提供整体框架、局部导航处理模块内跳转、关联导航连接相关内容、面包屑提供位置感和返回路径。比如在订单详情页，除了顶部菜单和面包屑，还应该有”查看客户信息”、”相关订单”、”物流追踪”等关联导航。

架构师在设计系统时，需要预见导航的技术实现需求。单页应用（SPA）还是多页应用（MPA）？URL 路由如何设计才能支持深度链接和分享？页面状态如何保存以支持后退操作？权限控制如何影响导航的显示？这些技术决策都会影响导航系统的用户体验。更重要的是，导航路径往往反映了业务流程，一个清晰的导航系统背后，必然是清晰的业务逻辑和合理的功能划分。

4. 搜索系统：如何检索信息

搜索系统让用户能够直接定位到需要的信息，而不必通过层层导航来寻找。它包括搜索入口的位置、搜索范围的定义、搜索结果的组织和筛选机制等。一个优秀的搜索系统不仅要能精确匹配用户输入，还要能理解用户意图——当用户搜索”退货”时，系统应该同时返回退货政策、退货申请入口、历史退货记录等相关结果。搜索的核心价值在于缩短用户到达目标的路径，特别是当信息量庞大或用户明确知道要找什么时。

搜索系统的设计需要解决几个关键问题：搜索什么（全文搜索还是特定字段）、如何搜索（精确匹配还是模糊匹配）、结果如何排序（相关性、时间、热度）、如何优化（搜索建议、历史记录、热门搜索）。比如在 B 端系统中，订单搜索可能需要支持订单号精确查询、客户名称模糊查询、时间范围筛选、状态过滤等多种方式。搜索结果的呈现也很重要——是简单列表还是分类聚合？是否需要高亮关键词？是否提供”没找到想要的结果”时的引导？

搜索系统和导航系统是互补而非互斥的关系。导航系统适合探索式浏览，帮助用户了解系统全貌和信息关系；搜索系统适合目标明确的查找，让用户快速直达目标。实际使用中，用户常常在两者间切换：先通过搜索快速定位到大概区域，再通过导航浏览相关内容；或者通过导航了解系统结构后，使用搜索来快速访问常用功能。架构师需要确保两个系统使用一致的信息组织逻辑和命名体系，让用户无论通过哪种方式都能找到相同的内容。

不是所有系统都需要搜索功能，但当信息量达到一定规模时，搜索就变得必不可少。

决定是否需要搜索功能，可以考虑三个因素：

• 内容丰富度：信息量是否足够大
• 内容性质：是否需要精确查找
• 使用场景：用户是否有明确的查找目标

比如配置中心，当配置项超过几百个时，分类浏览就不够用了，搜索功能变得必需。

常见的信息架构类型

1. 层级结构（树状结构）

这是最常见的信息架构类型。就像公司的组织架构图，从一个根节点开始，逐层向下展开，每个节点下面有多个子节点。最典型的例子就是 Windows 的文件夹系统，或者企业官网的菜单结构。

当信息之间有明确的从属关系，需要从大类到小类逐步细化时，层级架构能让用户通过逐步深入的方式找到目标。它解决的是”如何把大量信息有条理地组织起来”的问题。

企业官网、电商的商品分类、文档管理系统、组织机构管理等。比如京东的商品分类：家用电器 > 电视 > 液晶电视 > 65英寸。

其优点是结构清晰，容易理解；扩展方便，随时可以加新分类；适合信息量大但关系明确的场景；用户学习成本低。

缺点是层级太深用户会迷失（一般不超过3-4层）；同一个信息可能属于多个分类，不知道放哪里；跨分类查找很困难；移动端展示受限，层级多了不好操作。

2. 矩阵结构

允许从多个维度访问同一信息，像 Excel 表格一样，用多个维度来组织信息，用户可以从不同角度切入找到同一个内容。比如招聘网站，你既可以按职位类型找，也可以按地区找，还可以按薪资范围找，最后都能找到同一个职位。

当同一个信息需要从多个角度访问时，矩阵架构避免了「这个东西到底该放在哪个分类下」的纠结。它解决的是「一个内容多种查找方式」的问题。

电商的筛选功能（品牌+价格+功能）、招聘网站、房产网站、多维度报表系统等。比如链家找房：可以按区域、价格、户型、面积等多个维度组合筛选。

其优点是灵活性高，满足不同用户的查找习惯；信息不用重复存储也能多处访问；特别适合需要多条件筛选的场景；能够展示信息的多个属性。

缺点是维度太多用户会选择困难；实现复杂，需要良好的标签和索引系统；可能产生大量无结果的组合；对信息的标准化要求高。

3. 线性型架构（流程结构）

信息按固定顺序排列，用户只能顺序浏览，像看书一样，从第一页翻到最后一页，用户按照预定的顺序一步步前进。最典型的就是安装向导、注册流程、购物结算流程，用户必须完成当前步骤才能进入下一步。

当任务有明确的先后顺序，需要引导用户一步步完成时，线性架构能确保用户不遗漏任何环节。它解决的是「如何引导用户完成复杂任务」的问题。

注册流程、下单流程、问卷调查、教程引导、多步骤表单等。比如 12306 买票：选择车次 → 选择座位 → 填写乘客 → 确认订单 → 支付。

其优点是用户不会迷路，始终知道在哪一步；适合新手，降低学习成本；确保必要信息都被收集；可以在每步做验证，减少错误。

缺点是不够灵活，用户不能跳过或改变顺序；如果流程太长用户容易放弃；返回修改很麻烦；不适合老用户，每次都要走完整流程。

4. 网状型架构（关系结构）

信息之间没有固定的层级关系，通过标签或关联连接。像维基百科或社交网络，信息之间通过各种关系相互连接，没有固定的层级或顺序。用户可以从任何一点开始，通过链接跳转到相关内容，形成自己的浏览路径。

当信息之间的关系复杂、非层级化，需要展示多对多关系时，网状架构能够灵活地表达这种复杂性。它解决的是”如何表达信息之间的复杂关联”的问题。

知识库系统、社交网络、推荐系统、相关内容展示等。比如知乎的问题页面，会显示相关问题、相似回答、用户的其他回答等多种关联。

其优点是最灵活，能表达复杂关系；鼓励探索，用户可能发现意外的有价值信息；没有死胡同，总有路径可走；适合内容关联性强的场景。

缺点是用户容易迷失方向，不知道自己在哪；没有明确的开始和结束；信息架构难以可视化和理解；搜索和导航设计要求高，否则用户找不到想要的内容。

实际工作中，我们很少只用一种架构类型，通常是混合使用。比如电商网站：商品分类用层级型、商品筛选用矩阵型、购买流程用线性型、商品推荐用网状型。关键是根据不同的信息类型和用户任务，选择最合适的架构方式。

小结一下

信息架构设计要求我们不仅要梳理清楚系统中有哪些信息、这些信息如何命名才能让用户理解，还要思考如何组织这些信息才符合用户的认知模式、如何设计导航和搜索才能让用户高效地找到目标。每一个节点的命名、每一条连线的关系、每一个层级的划分，都会直接影响后续的界面设计和用户体验。

信息架构是连接业务逻辑和用户界面的桥梁。向上，它需要准确理解和表达业务需求，确保所有功能和内容都有合适的位置；向下，它为界面设计提供清晰的框架，让设计师知道需要设计哪些页面、页面之间如何跳转、每个页面应该包含什么内容。一个清晰的信息架构图，能够让团队成员快速达成共识，减少后期因为结构调整带来的返工成本。

作为架构师，我们在设计系统时不能只关注技术实现，还要站在用户视角思考信息的组织方式。好的信息架构应该是”隐形”的——用户使用时感觉自然流畅，不需要思考就能找到想要的功能。这需要我们在前期投入足够的时间去理解用户需求、分析使用场景、设计合理的分类体系和命名规范。只有把信息架构的基础打好，后续的框架层和表现层设计才能水到渠成，最终构建出既强大又易用的系统。