编辑导语:在产品交互视觉中，信息架构作为最底层的支撑逻辑，是很多B端设计师都应该掌握的。当我们对信息架构有了足够的了解，在设计页面的时候就可以有一个合理的思考方向，做出正确的设计。骨架搭建好了，用户体验才能有实质性的提升。笔者分享了相关的信息架构知识，希望对有需要的你有所帮助。

信息构建是我现阶段觉得很难学习和阐述的知识点，网上信息构建的知识内容也是参差不齐。在学习和探索的过程中，我查阅了大量的资料，反复修改了很多次，尽可能用直白的语言和例子来解释信息架构。目录如下:

你可以根据上面的目录有选择地阅读。当然全文阅读也是极好的~

1.介绍

这篇文章的出处来自最近看到的话题“B端设计师会被组件库取代吗？”。表面上看，在组件库越来越完善的时代，很多页面设计都可以依靠组件库快速搭建。

那么在这种情况下，B端设计师存在的意义和价值在哪里呢？其实B端设计的重点并不在页面的视觉上。视觉只是设计师最终输出的一小部分。我认为个人B端设计师的工作重点是做“正确的设计”，比如以下几个方面:

为了发现和解决这些问题，我发现很多话题的讨论都逃不出“信息架构”这个概念。所以我觉得设计师需要充分理解这个概念，它可以帮助我们做出正确优秀的设计。

2.信息架构的概念

关于信息构建的概念，维基百科中的定义大多晦涩难懂，比如维基百科和百度百科的解释:

我相信大多数人很难理解描述的意思。这里有另外一种思路，把信息架构拆分成信息和架构来理解。

信息是指内容的载体。常见的文字和图像都是信息。架构的含义描述了相应的组织和结构。那么信息架构就是把信息以一定的形式组织起来，然后呈现出来。其本质是研究信息的表达和传递。

通俗点说，信息架构就是让用户更容易理解我们的产品，让用户更流畅自然地使用我们的产品。所以信息架构没有具体的呈现形式，更多的体现在产品设计的各个方面。主要包括组织系统、标签系统、导航系统和搜索系统。

为什么需要信息架构？我们都知道B端产品设计的核心是“降本增效”，可以理解为在设计端降低认知成本，提高使用效率。

降低认知成本需要我们更好地表达信息，让用户明白我们的产品能做什么，怎么用。要提高使用效率，就要提高信息传递效率，让用户轻松找到所需功能；

从本质上讲，信息构建是对信息表达和传递的研究。所以我们需要它来帮助我们更好的完成B端产品设计。如果没有信息架构作为底层支撑，那么我们在页面上看到的可能只是功能的堆砌，使得产品处于难以使用或者不知道如何使用的尴尬境地。

强大的信息架构是产品质量的保证，是设计支撑点的框架。它可以减少可用性问题，改善整体导航，创造用户友好的体验。例如，以工具级别为例:

PS的工具栏堆叠在界面的各个部分，而Figma的工具栏集中在右侧，只出现当前需要的功能。显然，Figma在信息架构的信息组织部分更友好，而PS则不那么友好。这也是我们会觉得学习PS很难的原因之一。

可以说，好的信息架构是高效用户体验的基础。元素、功能、交互和导航都建立在信息架构的基础上。因此，为了做出一个好的、合理的页面设计，我们需要参与到信息架构的过程中，完成相应的架构与产品的梳理。而不是仅仅完成从原型到页面的部分。

想要建造一个好的建筑，我们需要知道它的建造目的，它是按照什么样的结构建造的，它的内部有什么系统，最后会是什么样子。

因此，信息架构也是如此。首先，我们需要知道信息服务于什么，然后我们使用什么样的结构来组织信息，在这个过程中将使用的信息元素，最后如何呈现它们。这些都是我们在构建信息架构时需要采取的必要步骤。

如果某些环节没有做好或理解透彻，输出信息架构时往往会出现方向或策略上的问题。接下来，我们来详细看看这些步骤是如何呈现的。

1.信息获取:先了解业务，再谈架构。

B端行业对业务理解的要求很高。只有了解业务，将业务需求转化为相应的设计目标，才能输出合理的信息架构方案。

我个人认为，理解商业的基础是能够用一句话把目前设计的产品解释清楚。这句话可以描述为:谁想在哪里达到什么目标。比如“用户不出门也能吃饭”，这是外卖软件提供的产品服务。

这句话虽然看似简单，但包含了三个要素:用户、场景、目标。所以在分析和梳理业务的过程中，我们首先要搞清楚的就是这三个要素。

(1)用户:区分买家和用户

用户永远是第一位的，这也是我们首先要搞清楚的。在B端设计中，本质上有两类角色:客户和用户。比如我们常用的钉钉或者企业微信，客户是企业，实际用户是员工。

对于企业来说:“我想有一个能更好管理员工的软件”

员工:“我想让这个软件更好地提高工作效率”

客户决定购买我们的产品(某些情况下也考虑到使用)，而用户决定后续产品的复购率。所以在业务理解中，我们需要搞清楚当前产品的服务阶段。比如前期肯定会偏向客户打开市场，中后期会偏向用户提升产品体验。

因此，我们首先需要搞清楚的是，目前的产品服务于哪些“目标用户”，这也决定了我们在设计信息架构时的侧重点不同。

(2)情景:需求源于情景

场景是指需求的某些条件，包括但不限于环境、时间、地点、空房间等。只有满足以上条件，需求才能成立。在这里，场景可以理解为这个问题的起因。

比如用户说“她需要一件衣服”，那么我们就需要找出用户为什么需要加衣服，是她冷还是因为外部环境冷。这两种场景涉及的解决方案是完全不同的。

在日常工作中，我们可以通过以下两种方式更好地理解业务场景:

通过商务文件初步了解商务背景。业务文档一般包括需求的背景，通过文档我们可以有一个初步的了解。

通过业务交流进一步加深对业务背景的了解。因为很多B端业务离设计师自己的生活很远。

所以，对于需求背景中那些不了解或者模糊的部分，我们可以通过与业务方或者产品的多次沟通，挖掘出最底层的背景。

毕竟需求背景是了解业务的重要一步。只有了解了需求的原因，才能给出有针对性的解决方案。

(3)目标:业务目标和设计目标

目标决定了我们产品的最终方向。我们首先接触到的通常是业务目标，而我们要做的就是这次把业务目标变成我们的设计目标。

①业务目标

业务目标是该业务想要解决的实际问题，通常是一个宏观描述。比如打车软件的商业目标，简单来说就是让用户更快的打到车，减少等待焦虑。我们通常通过文件或沟通来理解这个目标。

②设计目标

设计目标是基于业务目标的设计策略，是实现业务目标的更具体的方式。举个例子，如果我们希望用户快速打车，那么这个时候，我们的设计目标就是快速匹配用户位置和司机位置，通过长时间补贴红包来降低用户的焦虑。从而实现商业目标。

这个过程中涉及到的信息点有:司机位置、乘客位置、等待时间、补贴金额等元素，我们需要思考它们之间的关系和呈现方式。

可以发现，从业务目标到设计目标的过程，其实就是确定功能和信息点的过程。只有这样，我们才能更好地设计信息架构。

2.信息架构的核心:信息组织

从上一篇文章中我们可以看到，在整个设计过程中会出现很多信息元素。如果不经过相应的组织和处理就直接叠加在一起，信息的含义就会混乱，难以调用。例如，下面:

右边图片信息的组织过程可以理解为将零散的数据信息进行分类，并以结构化的方式重新排列的过程。直截了当地说，就是先进行分类，然后以结构化的方式呈现出来的过程。我用一张图来说明这个过程:

那么，这个过程中的“信息组织”和“结构呈现”应该怎么做，也就是接下来要讲的组织方法和结构类型。

(1)组织:模糊分类和精确分类

组织方法可以分为精确分类和模糊分类。准确分类是指我们会利用物体本身的物理属性进行分类，比如位置、字母表、时间、类别、层次等方式来组织。一些工具应用程序(如勾选列表内容信息)是按时间组织的:

模糊分类是根据更主观的逻辑对信息进行分类，如主题、任务、用户、隐喻等。比如我们常用的应用商店，就是按照不同的主题类别来分类的。

但在很多情况下，产品往往会将两种组织方式结合起来，形成一种复合的组织方式，可以让我们的整体组织形式更加符合用户的使用习惯。例如，blue lagoon中的信息组织既包括模糊分类(按使用类型分类等。)和准确分类(文件上传时间等。).

其实在大部分B端产品中，大部分都是按照模糊分类进行处理的，比如任务、流程。准确分类更多用于页面中的局部信息模块，如创建时间、文件大小等。

归根结底，我们分类方法的选择需要结合我们前面提到的用户、场景、目标，这样才能让我们的分类更有说服力。

(2)组织结构:选择合适的结构类型

当信息按照分类维度进行组织后，下一步就是对整个信息进行结构化，使整个信息能够被连接和呈现。一般来说，它可以分为以下四种组织方式:

①层级结构(最重要的结构)

这是信息架构中最常见的结构，也是比较符合用户认知的结构。有时被称为“树形结构”。以子节点和父节点的形式逐层扩展。

层次的好处是可以承载复杂的多层次内容，通过层次递进的方式可以更简洁的拆解。

但是我们需要控制内容的广度和深度。广度是指层级结构中每一层的数量，最好控制在7个以内。

如果广度太宽，就意味着每个页面会向用户展示过多的信息，增加查找内容的负担。是有进深的竖向结构，建议一般3层，最多不超过5层。太深的层次会让用户点击很多次，用户不容易发现。例如，舒菲的基础信息体系结构主要基于层次结构。

②矩阵结构(多维结构)

矩阵是所有节点相互连接的一种信息架构方式。一般来说，用户不仅可以通过多个维度访问相同的信息，还可以从单个维度连接多种信息。

这个结构其实更类似于我们在做相关功能的时候:比如当你进入电影全屏的时候想要退出，你要么点击按钮退出，要么通过键盘的Esc返回，多点触控也可以达到同样的操作。

再比如我们的联系人功能。我们可以通过输入号码打电话，找联系人打电话，查询电话记录回电。

该结构最重要的意义在于为用户提供了多条路径，让用户可以在不同的路径中找到自己想要的东西。

③自然结构(随机性)

自然，结构不遵循任何一致的模式，节点是一个接一个连接的。

自然结构通常是随机的和不确定的。这种C端应用更倾向于泛娱乐。比如我们常见的视频网站的推荐流，就是应用的自然结构。例如，当你打开哔哩哔哩等视频平台时，你很难猜到你看到了什么。

然而，一般的自然结构并不是单独存在的。例如，哔哩哔哩还将等级结构绑定在自然结构中进行等级划分。

④线性结构(单一性)

线性结构是非常单一的结构，整个结构是一层一层向下递进的。强调比较顺序的结构。

这种结构通常用于我们常见的软件安装程序等。，也可用于一些功能结构，如网站的视频发布，一般通过上传-编辑-发布三个步骤进行。

你可以发现，在信息构建的过程中，很多情况下我们可能会使用多种组织结构，需要根据对应的用户决策场景考虑组合最合适的方法。但最终目的是让用户更快地获取信息。

(3)注意:注意用户的心智模型

在信息组织过程中，我们需要关注用户的心智模式。比如看到红点就知道有新的信息通知，看到下拉箭头就知道可以展开。这是互联网产品无形中为用户建立的底层习惯认知。

目前，用户对常用产品的一些基本布局、功能名称和交互逻辑已经形成了一定的习惯，属于用户心智模型的内容。

所以在组织信息的时候尽量不要打破用户常见的心智模式，否则必然会导致用户的不习惯。我们常见的“扫一扫”功能，微信、支付宝、QQ都会隐藏在“+”号里。微博和Tik Tok分别放在“我的”和“搜索”中。

这样会让用户很难找到这个功能。因为当用户接触到新的信息时，他会基于最初接触到的局部信息发展并形成初步的认知，用户认知中的信息组织逻辑与实际信息的重合度越高，他在进一步查看或搜索信息的过程中体验就越顺畅。

相反，如果一开始形成的认知与实际信息差异过大，那么在后期的信息搜索过程中就容易遇到困难。这种重合度其实就是用户的心智模型。

虽然建议在一定程度上遵从了用户的心意，但并不代表绝对遵从。对于用户不熟悉的场景或者一些专业术语，我们需要通过灵活有效的提示引导用户(比如标注笔记等。).比如我们刚刚提出的Tik Tok扫一扫，它的应用场景其实是在官网、Tik Tok进行后台登录，后台登录时已经给出了相应的提示，所以这样的设计也是合理的。

3.信息架构支持:标记、导航和搜索

通过以上的信息组织，实际上我们已经能够总结出一个通用的信息架构框架。但除了信息组织，我们还需要注意以下三点:标记、导航和搜索。这对信息架构的完整性也具有重要意义。

(1)标签系统:让信息识别更通用

系统，通俗地说，就是要给整个系统当前的信息节点命名，让信息的呈现更容易识别。举个最简单的例子来说明:

你可以看到厕所左右两边的信息牌。也许左边一眼就能看出区别，右边可能要半天才能猜出什么意思。

其实这就是关于我们的信息命名能否被大多数用户接受的场景，也就是我们标签的作用。标签可以分为图片标签和文字标签，这两种标签都需要考虑用户对信息命名的认知程度，也就是前面提到的心智模型。那么如何才能更好的定义标签名呢？在这里，我们需要注意两个方面:

①优先选择被业界广泛接受的文字或图标。

在定义标签的时候，尽量选择用户已经熟知的词，比如“工作台”、“通讯录”，这些词已经用得非常熟练了。对于类似的函数，直接用这种形式命名。例如，在我们的设计软件中，许多图标和功能名称都很常见:

这样可以大大降低用户的学习成本。所以，在B端设计中，也需要注意我们所在的行业，哪些条款已经达成共识，不需要重新创建新的条款。

②不确定词可以参考竞品或研究来决定。

当某一类功能或场景的标签难以确定时，我们可以试着去找竞品是否有类似的功能，或者找行业的龙头(比如微信，聊天工具的巨头)，这样在定义标签时可以参考它的命名体系。因为它为我们教育了一部分用户，所以会间接降低学习成本。

如果在上述过程中有些标签无法确定，那么我们将与自己的经验或咨询业务的相关人员进行讨论，必要时可以在标签旁边添加注释，以便进一步说明。

(2)导航系统:防止用户迷路

导航系统实际上应该是一个众所周知的系统。就像用导航系统规划行程一样，导航系统会存在于每一个网站中。比如我们常见的侧边导航，顶部导航等等。

因为网上有很多关于导航系统的信息，下面是以下四种导航的含义:

全局导航:页面顶部的导航，用户在页面上几乎随处可见，是最高级别的导航系统；

局部导航:位于最高导航中的子类导航。子类导航不是必须导航，根据场景选择。

情景导航:通过点击文本链接进行跳转的导航，比如在个人数据中嵌入其他网站的链接地址；

辅助导航:包括网站地图、网站索引、网站指南等辅助导航类型。

辅助导航的网站指南包括新手指南和演示教程等。现阶段比较巧妙的功能引导是在用户正在操作某些功能的时候进行提示，既达到了引导用户的效果，又减少了一系列新手引导对用户的打扰。比如figma更新组件后，只会在你调用组件函数时及时提醒。

(3)搜索系统:让用户轻松找到信息

搜索是我们日常生活中最常用的查找信息的功能。它可以帮助我们快速搜索信息。虽然搜索功能很重要，但并不是每个系统的每个页面都需要搜索。在决定是否添加搜索时，我们需要考虑以下三点:

复杂度:如果当前页面承载的内容复杂度较小，往往不需要搜索简单的内容页面；

内容:当前页面的性质是面向用户的浏览还是搜索，取决于用户的行为。

搜索场景:如果搜索场景简单，考虑是否只通过过滤或分类就能解决问题；相反，如果搜索的内容非常复杂，我们也可以通过搜索和筛选来更好地找到信息。

以上三点决定了我们是否需要考虑搜索功能。搜索的其他细节，如搜索规则和搜索结果，在此不再赘述。在本文中，更重要的是找出我们何时需要搜索功能。

4.信息架构表达:可视化你的架构。

通过以上方法我们已经知道如何梳理信息架构，那么应该如何呈现呢？这部分其实是很多材料中比较模糊的一点。

在学习的过程中，我发现有些资料认为信息构建简单的指思维导图，但实际上信息构建仅仅靠思维导图是无法完全表达的。

因为信息架构包含很多部分。只能说思维导图可以是信息架构的一种表现形式，可以帮助我们在思考阶段理清整个产品的信息结构。

这里有一个很有意思的观点，就是“功能结构图”和“信息架构图”是什么关系。以下是两个图表示例:

可以看到，功能结构图更多的是功能解释的形式，一般形式是名词+动词，比如头像设置；信息架构图应该关注所有的信息元素，一般是名词，比如头像图片。

但是很多时候，我们看到的产品架构图其实更倾向于功能架构图和信息架构图的结合。因为很多时候解释信息构成需要依靠函数进行辅助解释。

因此，本文描述的信息架构更倾向于基于产品的整体架构。事实上，信息架构对呈现形式没有特别的限制，只要能帮助你清晰地表达产品的整体结构。

事实上，《信息架构:超越网页设计》第4版并没有严格定义表现形式。它用“展现信息元素之间的关系——站点地图”的表述来概括信息架构的展现形式，表述如下:

我们可以看到它的表现形式包括思维导图和流程图等。思维导图的优势是可以总览全局信息，检查信息的深度和广度，而流程图的优势是更能表达整体的逻辑关系。

所以信息架构的呈现需要根据你的产品场景选择合适的视觉框架表达。我们不必让形式限制我们的发挥，但我们应该遵循我们的建筑表达。

它只是一个信息梳理结构(类似于中间状态)的解释结果，我们需要用它来更好地解释思想，沟通思想。

5.信息架构之后:让信息形象化。

输出信息架构之后，这里其实想说一下页面的呈现。因为在整理出大框架之后，剩下的页面细节其实是需要原型图来体现的。这个过程就是从框架到页面的阶段，对于设计师来说其实是很重要的一部分。在这里，我根据自己的理解，列举了以下几点注意事项:

(1)页面能被用户理解

这其实和我们的信息组织和标签体系有关。如果我们的某个页面不能让用户第一时间获得页面上表达的信息，反思我们哪些方面做得不好。是标签系统不明确，还是信息的组织和分类方式不对？从页面表现的逆向信息架构。

一般来说，设计中的安排要考虑用户的心智模型(比如网页的常规布局，常用名词的定义等。)，并向用户帮助和解释一些无法理解的地方。虽然B端产品不可能完全避免学习成本，但是我们可以尽量降低他们的学习成本。

(2)考虑用户的视觉运动

我们在整理信息的时候，这个时候需要考虑的是用户的视觉运动线，也就是所谓的视觉浏览的“F模型”和“Z模型”。对于不同的信息流，使用不同的动态模型可以帮助用户更好地找到信息。

F模型和Z模型的使用区别其实在使用场景上。对于内容页面，F模型更适合(比如文章或者搜索结果)，适合文本内容。但是，对于非文本页面，Z-model更适合。Z-model的设计追踪了人眼扫描页面的路线——从左到右，从上到下，可以更好的引导用户的视线。

(3)控制适当的信息水平

在B端，因为没有太多的视觉显示空，相对来说，保持一个好的信息等级可以让整体体验更好。

无论是原型还是视觉，都应该更清晰地体现整体视觉水平。按理说，最佳视觉水平控制在3级左右。如果发现视觉层次过多，就需要在设计信息架构时考虑垂直层次是否过深，调整架构的形式，更好的呈现信息。并在同一页上排列信息的重要性。

当我们讲完或者听别人讲解相应的信息架构时，应该如何判断，什么样的信息架构是优秀的？个人认为可以从三个方面来判断:

1.业务层

合理的设计目标:能够平衡业务目标和用户目标，保证客户和用户有更好的体验；

核心任务目标:使用户能够顺利完成产品的核心任务，这些核心任务需要通过用户测试来验证。

2.结构层

平衡广度和深度:使用功能时，不会隐藏太深而被发现。有没有多余的步骤？

有保证的可扩展性:当前的信息架构可以在未来面对新的或删除的信息时稳定地扩展。

3.体验层

保证可读性:无需介绍，通过呈现页面信息，用户就能明白产品的用途。

保证搜索方便:用户需要某项功能时是否能快速找到，是否有多种搜索方式(如搜索或过滤)。

一个合理的信息架构需要满足以上条件，我们在设计和呈现时需要尽力保证以上条件。但是，很多时候，并不能完全满足。这时，我们需要根据重要性选择一些点来满足业务目标。

梳理整篇文章的结构，其实是以“什么——为什么——怎样”的形式拆分的:

本文想表达的思想不是让设计师独立整理整体的信息架构，而是让设计师有信息架构的意识，了解它是如何进行和产生的。这样，当你看到整体架构的时候，你就有了足够的理论支撑来判断它的好坏，也可以通过自己的理论认知来了解和改进不好的地方。

当我们对信息架构有了足够的了解，在设计页面的时候就能有一个合理的思考方向，做出“正确的设计”，避免成为一个无情的绘图机器。信息架构作为产品交互视觉的最底层支撑，只有框架搭建起来，才能从本质上改善用户的体验。

注:文章难免会有不足之处。如果你对文章中的内容有更好的建议，欢迎随时交流。

参考资料:

本文由@阿东作为产品经理授权发布给大家，未经允许禁止转载。

图片来自unsplash，基于CC0协议。