基于web标准的网页设计与制作课后答案产品交互视觉中的信息架构知识内容也是参差不齐？

编辑导语：在产品交互视觉中，信息构架作为最底层的支撑逻辑，是许多B端设计师都要把握的。当我们对信息架构有足够的感知时，在设计页面时才会有合理的反思方向，做出恰当的设计。骨架搭得好，用户体验才无法有本质的提高。作者分享了相关信息架构知识，希望对有必须的你有所帮助。

信息架构这篇是本人在现阶段感到较难学习与探讨的常识点，网上关于信息架构的常识内容也有参差不齐。在学习与研究的过程中查阅了这些资料，反复更改多次，尽量用直白的语言结合实例来探讨信息架构。目录如下：

大家可以按照上述目录来进行选取性阅读，当然全文阅读也是极好的～

一、信息架构基本思维1.前言

这篇文章的由来，来源于今天见到的话题“B端设计师会被模块库替代吗？”。从表面上看，在模块库越来越建立的时代，很多页面设计依靠组件库就无法迅速构建。

那么在这些状况下，B端设计师存在的含义和价值到底体现在那里呢？难道B端设计的重点并不在页面的视觉上，视觉也是成为设计师最后输出成果的一小部分。个人觉得B端设计师工作重心体现在做「正确的设计」，比如下面几个方面：

而想要弄明白并缓解上述这种弊端，在很多的话题探讨之下基于web标准的网页设计与制作课后答案，我看到其阐述本质上都逃离不了「信息架构」这个概念。因此我觉得设计师都必须对这个概念有充分的感知，这无法帮助我们作出恰当且优异的设计。

2.信息架构概念

关于信息架构的概念，在百科里面的定义大个别都非常繁杂难懂，比如维基百科和百度百科的解释：

相信大部分人都很难知道其中表述的含义。在此处换种模式，将信息构架拆分为信息与架构去理解。

信息指的是内容的载体，常见的文字、图像等都是信息；架构的涵义则比喻对应的组织和构架。那么信息架构就是将信息通过一定的方式组织起来，然后展现出来。其本质就是探究信息的表达与释放。

通俗点讲，信息架构就是让客户可以更易于的理解我们的产品，让顾客在使用我们的产品时可以更成功、更自然。因此信息架构没有一个详细的展现方式，它更多的是表现在产品设计的各方面。具体主要体现为组织平台、标签系统、导航系统和搜索平台。

二、为什么还要信息架构

为什么还要信息架构？我们都清楚B端产品设计的核心是「降本提效」，在设计这一侧的可以将其理解为减少认知成本，提升使用效益。

增加认知成本必须我们更好的表达信息，让客户能看明白我们的产品无法做哪些，如何用；提高使用效益必须改善信息的释放强度，让用户无法很易于的找到需要的功能；

而信息架构从本质上来讲也正是探究信息的表达和释放。因此我们必须借助它来帮助我们更好的完成B端产品设计。如果没有信息构架来作底层支撑，那么我们在页面上发现的或许就唯有功能的堆叠，让产品遭遇无法上手以及不清楚如何用的难堪局面。

一个超强信息架构是产品品质的确保，是成为设计支撑点的骨架，它会降低可用性难题，提升整体导航性，创造对客户友好的感受。比如举一个工具层面的举例：

PS的软件栏堆叠在图标各个个别，而Figma的工具栏则集中在左侧且只发生当前应该的功能。很显著Figma在信息架构中的信息组织个别做得更为友好，PS则会变得逊色一些。这只是我们在学习PS的之后会变得非常吃力的缘由之一。

可以说良好的信息架构是高效用户体验的基础。视觉元素，功能，交互和导航都是在信息构架的基础上建立的。因此想要作出体验好且合理的页面设计，我们就必须参与到信息架构这个过程中来，和产品一起完成对应架构的梳理。而不是只完成从原型到页面这个部分。

三、怎样设计合理的信息架构

如果想要搭建一个好的建筑，我们必须了解其建造的目的，是根据何种样的构架搭建，内部有什么系统，以及最终呈现的模样。

那么信息架构也同理，我们首先必须了解信息是为了什么目标服务，然后我们借助怎样的结构来组织很多信息，以及过程中会用到的信息元素，最后能否展现它们。这都是我们在建立信息架构中必须进行的必要方法。

如果这些环节没有做好以及没有认识透彻，那么在输出信息架构时通常会发生方向以及策略上的难题。接下去我们说说这些方法是怎样准确呈现的。

1.信息获得：先理解业务，再谈架构

B端市场针对业务理解的要求是相当高的，只有在理解业务的基础上，将业务需求转换为对应的设计目标，我们才无法输出合理的信息架构方案。

个人觉得理解业务的基础，就是无法用一句话讲明白当前设计的产品。这句话可以表述为：谁在哪个地方想要完成什么目标。比如「用户想要不出去就无法吃到东西」，这就是外卖软件提供的产品服务。

然而看起来这句话很简洁，但其中包含了三个要素：用户、场景和目标。因此我们在探讨和梳理业务的过程中首先要弄明白的就是这三个要素。

（1）用户：分清购买者与使用者

用户依然是排在第一位的，也是我们首先必须弄明白的。在B端设计中，本质上可以分为两类角色：客户和顾客。比如我们常见的钉钉或企业微信，购买客户是企业，实际用户是人员。

针对企业：「我想要有一款工具可以更好的管理员工」

对于员工：「我想要这款硬件才能更好地减少工作效率」

客户决定了我们产品的购买（个别状况下也注重使用），而客户则决定了后续产品的复购率。因此在业务理解中，我们必须弄明白当前产品所处的服务阶段，比如早期为了开启市场显然更偏向于用户，而中前期为了提升产品的使用感受又会倾向于用户。

此外我们首先必须弄明白的就是当前产品是为这些「目标客户」服务，这也就决定了我们在设计信息架构时对应的不同侧重点。

（2）场景：需求源于场景

场景是指意愿产生的某些条件，这个条件包含但不限于环境、时间、地点、空间等，只有上述条件满足，这个意愿能够建立。这里可以把画面理解为形成该难题的理由。

包括当用户提出「她必须一件服装」，那么我们就必须弄明白客户为什么还要添加衣服，是她生病了自身认为冷还是由于外界环境冷。这两种场景涉及到的缓解方案是完全不一样的。

在平日的工作中我们可以借助以下两种方法来更好的知道业务场景：

通过业务方文档进行业务背景的初步理解。业务文档中通常还会包含需求背景，我们可以借助文档进行初步知道。

通过业务沟通进一步增进业务背景的理解。由于这些B端业务离设计师原本的生活非常远。

此外针对需求背景中不理解以及非常模糊的个别，我们可以借助与业务方或产品多次沟通来挖掘最底层的背景。

虽然需求背景是理解业务的重要方法，我们只有了解需求形成的缘由，才无法对于性的给出缓解方案。

（3）目标：业务目标和设计目标

目标决定了我们的产品最后的方向。我们首先接触到的通常都是业务目标，而我们要做的就是将业务目标转换为我们这次的设计目标。

①业务目标

业务目标就是这次业务想要解决的实际问题，它一般是一个宏观上的表述。比如打车软件的业务目标简单概括来讲就是让客户无法更迅速地打到车，减少等待焦虑。我们通常借助文档以及沟通来认识该目标。

②设计目标

设计目标是我们基于业务目标而给出的设计思路，是一种更准确的推动模式。比如我们要让顾客快速的打到车，那么这个之后我们的设计目标就是借助将客户位置和司机位置进行迅速匹配，并借助超时补贴红包的细则来增加客户焦虑。从而推动业务目标。

而这一过程涉及到的信息点就有：司机位置、乘客位置、等车时间、补贴数额等元素，并必须探讨他们之间的关系和呈现形式。

可以看到从业务目标转换到设计目标这个过程，实际上就是在确认功能和信息点的过程。这样就能让我们更好地设计信息架构。

2.信息架构核心：信息组织

从前文可以看出我们会在整体设计过程中发生这些的信息元素。如果不经过对应的组织和处理，直接堆叠在一起，那么信息含义会非常乱且无法调用。比如下方：

而右侧照片信息的组织过程可以理解为借助将零散的数据信息进行分类，再以某些结构化的方式将他们再次组合排布的过程，直白一点就是先分类，再结构化展现。我用一张图来说明这个过程：

那么这个过程中「信息组织」和「结构展现」到底需要怎样做，也就是接下去要讲的组织形式和结构类别。

（1）组织形式：模糊分类和准确分类

组织形式可以分为准确分类和模糊分类。精确分类就是我们会运用物体原本化学属性来进行分类，比如位置、字母表、时间、类别、层级等方法进行组织。一些软件类应用比如滴答清单内容信息都是根据时间来进行组织的：

而模糊分类则是根据更为主观的逻辑对信息进行分类,如主题、任务、用户、隐喻等来进行归类，比如我们常见的APP商城是根据不同的主题类别来进行区分的。

但在这些之后，产品倾向于将两种组织形式结合出来产生复合型组织形式，从而无法使我们的整体组织方式更依照用户的使用习惯。比如蓝湖的信息组织，其中既包括了模糊分类（按使用类别等分类），也包括了准确分类（按上传文件时间等）。

虽然在大个别B端产品中，大都根据模糊分类来进行处理，比如根据任务、流程等方法。而准确分类更多用于在页面内的局部信息模块，比如建立时间和文件大小等。

归根结底，我们分类方法的选取需要结合我们中间提到的客户、场景和目标，这样就能让我们的分类更具说服力。

（2）组织结构：选择适合的结构类别

当信息根据分类维度组织后，我们接下去就是把整体信息进行结构化，这样才可以将信息整体连接起来并展现出来。一般分为下列四种组织形式：

①层级结构（最重要的结构）

这是信息架构中最为常用的结构，也是非常符合用户思维的结构。有时称作为「树状结构」。以子父节点的方式一层一层延展。

层级结构的优势就在于可以承载复杂的多层级内容，通过层级递进的形式将复杂的多层级拆解得更简单。

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

如果广度太宽意味着每个页面会给客户展示太多的信息，增加寻找内容的负担。深度为横向构架，建议通常3层，最多不低于5层。过深的层级会让客户点击这些次，且不易于被用户看到。比如飞书的基本信息构架也是主要以层级结构来进行的。

②矩阵结构（多维度结构）

矩阵结构是各个结点都互相联结的一种信息构架形式，通俗来讲就是客户既可以借助多个维度去触达同一信息，也可以从单个维度连接多种信息。

这些结构虽然就更类似于我们在做相关功能时：比如当你开启电影全屏时想要退出时，既可以借助点击图标退出，还可以借助键盘的Esc返回到，通过多点触达同一操作。

又例如我们的联系人功能，我们既可以借助输入数字拨打电话，也可以查找联系人进行拨打，还可以查询电话记录进行回拨。

矩阵结构最重要的含义在于给用户提供多种模式，使用户无法在不同模式中寻求各自想要的东西。

③自然结构（随机性）

自然结构不遵守任何一致的方式，节点都是被逐一连接出来的。

自然结构通常都带有随机性和不确认性。这种更偏向于泛娱乐化的C端应用。比如我们常用视频网站的在推荐流都是应用的自然结构。比如开启B站等视频平台，你很难猜到刚步入看到的是哪个。

但通常自然结构不会单独存在，比如B站在自然结构中也绑定了层级结构来进行层级上的界定。

④线性结构（单一性）

线性结构是相当单一的一个构架，整体是一层一层往下递进。比较注重先后次序的一种结构。

这些结构一般用于我们常用的硬件安装程序等，也可以用于部分用途结构，比如网站的视频公布，一般都是经过上传-编辑-公布这三个方法来依次进行。

大家可以看到在进行信息架构时，我们在这些状况下或许会利用多种组织结构形式，我们必须按照对应的客户决策场景来考量让最合适的几种方法相结合。但最后目的都是为了让客户无法更迅速的获得信息。

（3）留意事项：关注用户心智模型

在信息的组织过程中，我们必须注意用户的心智模型。比如当我们发现红点就了解有新信息通知，看到下拉箭头就明白可以展开。这是互联网产品在无形中给客户构建的底层习惯认知。

用户现在针对普遍产品的一些基础加码、功能名称和交互逻辑都产生了一定的习惯，这都属于客户的心智模型的内容。

此外我们在组织信息时尽可能不要去摆脱用户常见的心智模型，否则必定会造成客户的不习惯。我们常用的「扫一扫」功能，微信、支付宝和QQ会隐藏在「+」号上面。而微博和抖音却分别放置在了「我的」和「搜索」里面。

这种会造成用户无法看到该功能。因为客户接触新的信息时，会以最初接触的局部信息为根据展开并产生初步感知，而客户认知中的信息组织逻辑和实际信息的吻合度越高，他在进一步查看或寻求信息的过程中感受会更顺畅。

反之，若一开始产生的感知与实际信息的差别过大，在前期的信息搜寻过程中则易于见到困难。而这个吻合程度似乎就是用户心智模型。

尽管建议在必定程度上依照用户心智，但并不是说绝对遵守。对于用户不了解的画面以及那些专业词汇，我们必须借助灵活有效的提醒（例如标记注解等）来鼓励用户就可以了。比如我们今天提出的抖音扫一扫，它的应用场景虽然是用于抖音官方后台登录，且在后台登录时尚未给出了对应提示，那么这种的设计也有合理的。

3.信息架构支撑：标签、导航和搜索

经过里面的信息组织，其实我们将要能够归纳出一个大体的信息构架框架。但在信息组织之外，我们还必须关注以下三点：标签、导航和搜索。这针对信息架构的完整性也是相当重要的意义。

（1）标签系统：让信息识别更通用

标签系统，通俗来讲就是要我们对当前整个平台信息节点的命名，从而让信息的展现更容易识别。拿个最简单的事例来进行说明：

可以发现右边和两侧关于卫生间的信息标志，可能两边你能一眼分辨，右边可能就必须反应半天才能猜出究竟代表哪个意思了。

这也许就是关于我们的信息命名是否还能被大多数用户所接受的画面，也就是我们标签作用所起的作用。标签可以分为照片和文字标签，都必须考量用户对该信息命名的感知程度，也就是中间提到的心智模型。那么怎样才能更好的去定义标签名称呢，这里应该留意2个方面：

①优先选择被市场广泛接受的词或图标

在进行标签定义的之后，尽量选用早已被用户所熟悉的词语，比如「工作台」「通讯录」等早已被利用得十分熟练，对于类似用途就直接以该方式命名，比如我们的设计工具中，很多按钮和用途名称都是通用的：

这种做才能很高程度降低客户的学习费用。因此在B端设计中我们也必须注意到我们所在的市场，哪些名词尚未达成了议题，就无需再造新名词。

②不确认的词语可以参考竞品或调研来决策

当某类用途或画面的标签难以确定时，我们就可以尝试去找一下竞品是否有类似用途，或者找该市场的领头羊（例如聊天软件的大佬微信），那么在进行标签定义的之后，可以参考它的命名模式。因为它终于替我们教育了一个别客户，会间接减少学习成本。

如果这些标签在上述过程中而是能够确认，那么我们结合自己心得以及与咨询业务相关人员来进行探讨，在必要时候可以在标签后面添加注释来进一步表明。

（2）导航平台：让用户不迷路

导航系统虽然需要是你们相当熟悉的一个平台了。就像使用导航平台来规划行程一样，导航平台都会存在于每个网站中。比如我们常用的侧边导航、顶部导航等。

由于网上关于导航平台尚未有众多资料的讲解了，在此处列举下四类导航的含义：

全局导航：位于页面最上层的导航，用户几乎在页面的每个地方都可以看到，是最高层级的导航平台；

局部导航：位于最高导航的下级子类导航，子类导航并不是需要的导航，根据场景进行取舍；

场景式导航：通过单击文字链接进行跳转的导航，比如在个人资料上面植入其他网页的链接地址；

辅助导航：这里包含网页地图，网站索引，网站指南等辅助类型的导航。

辅助导航的网站指南包含新手引导和演示教程等。现阶段更巧妙的用途引导，是当用户在进行这些功能的操作时迅速进行提醒，这样除了超过了为用户引导的效果，还降低了一连串的新手引导对于用户的打扰。比如figma在进行模块更新后，只有当你调用模块功能时基于web标准的网页设计与制作课后答案，才会立即进行提示。

（3）搜索平台：让客户轻松找信息

搜索，是我们平日最常见的查找信息的功用，它无法帮助我们迅速进行信息的检索。虽然搜索功能十分重要，但并不是每位系统每个页面都必须搜索。我们决策能否添加搜索时必须考量以下三点：

内容复杂度：当前页面承载的内容复杂度即使较少，对于简单内容页面通常不应该搜索；

内容性质：当前页面的性质是倾向于用户浏览还是查找，根据客户行为来决定能否需要搜索；

搜索场景：如果搜索场景很简洁，考虑能否只用筛选或分类就无法缓解问题；反之即使搜索内容很复杂，我们还可以搜索结合筛选来更好的查找信息。

上述3点决定了我们能否需要考量搜索功能。而关于搜索的其它细节点，比如搜索规则和搜索结果等，在此处不做进一步的阐明。在这篇文章中更重要的是弄明白我们何时应该搜索功能。

4.信息架构表达：视觉化你的架构

我们借助上述方式尚未清楚怎样梳理信息架构了，那么我们必须怎样展现它呢。这部分原来只是众多资料中非常模糊的点。

在学习的过程中，发现个别资料认为信息架构就是纯粹的指认知导图，但实际上信息架构并不能纯粹只用思维导图就无法完全表示。

由于信息架构包括了众多部分的内容。只能说认知导图可以是信息架构的一种体现方式，其可以帮助我们在探讨阶段梳理整体产品的信息构成。

此处抛出一个很有含义的看法，那就是「功能结构图」和「信息架构图」到底哪个关系，这里用两张图示例：

可以看到，功能结构图更多表现的方式是用途体现，一般方式为副词+谓语，比如头像设置；而信息架构图重点展现的应当都为信息元素，一般为术语，比如头像照片。

但在大多数之后我们发现的产品架构图，其实更倾向于功能结构图和信息构架图的结合。因为在这些之后揭示信息构成时必须依赖用途进行辅助说明。

然而这篇文章讲述的信息构架更倾向于基于产品的整体构架。其实信息架构针对呈现方式并没有非常的限制，只要无法帮助你清晰表达产品整体结构就行。

《信息架构：超越web设计》第4版中虽然也并没有对体现方式这一块进行严格的定义，其用「显示信息元素间的关系——站点地图」的表述概括了信息构架的展现方式，其表达如下：

可以发现其表达方式包含认知导图和步骤图等方式：思维导图的优势是无法总览全局信息，查看信息的深度和广度，而流程图的优势则更无法表达整体的逻辑关系。

此外信息架构的展现需要按照你的产品场景选择适合的视觉框架表达。不必让手段限制了我们的发挥，而是需要形式追随于我们的架构表达。

其并非一个信息梳理结构的表明结果（类似于前面态），我们必须通过它来更好的阐释思路与沟通见解。

5.信息架构以后：让信息具像化

在输出信息架构以后，其实此处想聊一聊页面的展现。因为当梳理好大的框架后，剩余的页面细节似乎都必须借助原型图来进行诠释。这个过程是从框架到页面的阶段，其实对于设计师来说只是很重要的个别。在此处根据自己的理解列出了下面几方面的注意点：

（1）页面就能让用户看懂

这也许就是涉及到我们的信息组织和标签系统。如果当我们的某个页面不能让客户第一时间获得到该页面表达的信息，反思一下是在那个方面做得不好。是标签系统意思模糊呢，还是信息的组织分类方法不对。从页面呈现倒推信息架构。

综合来说就是设计时的排列要考量用户的心智模型（例如网站的常规排版和通用术语定义等），对于那些无法理解的地方予以用户帮助和解释。虽然B端产品想要完全导致学习成本是不可能的，但我们可以尽量避免其学习成本。

（2）考虑用户的视觉动线

当我们在进行信息排列时，这时应该反思的就是用户的视觉动线，也就是我们常说的视觉浏览「F模型」和「Z模型」。对于不同的信息流来说，采用不同的动线模型无法让客户更好地查找信息。

F模型和Z模型的使用区别也许就是在使用画面上，对于内容页面来说F模型会更为适合（例如文章以及搜索结果），适合文本类的内容。但针对非文本的页面，则更合适用Z模型，Z型方式的设计跟踪了人眼扫描页面时的路线——从左到右，从上到下，能够更好鼓励用户的视线。

（3）掌控好适当的信息层级

B端因为在视觉的发挥空间不多，那么相对来说维持良好的信息层级进而让整体的感受更加更为良好。

不管是原型图还是视觉，整体的视觉层级要表现得更为清晰。按理说最好的视觉层级控制在三级左右。如果看到视觉层级过多，需要考量是不是由于信息构架设计时横向层级过深，通过调整架构的方式来更好的展现信息。以及对同页面的信息进行重要程度分级。

四、如何评判信息架构的优劣

当我们做完或者听他人阐述对应的信息架构时，该怎么评价呢，到底怎样的信息架构才算优秀呢。个人觉得可以从3方面去进行判断：

1.业务层

设计目标合理：能平衡商业目标和顾客的目标，保证客户和顾客都有较为良好的体验；

核心任务目标：能够让客户成功完成产品的核心任务，需要借助用户检测来进行验证。

2.结构层

平衡广度和深度：在进行功能使用时不会隐藏的太深而找不到，是否有冗余步骤

确保拓展性：当前信息架构在应对将来新增以及删减信息时才会稳定拓展

3.体验层

确保易读性：用户不经过介绍，通过页面信息呈现才能看懂该产品是拿来做哪些的。

确保易查找性：用户在必须某个功能时能够快捷的找到，是否有多种查找方式（例如搜索或筛选）。

合理的信息架构必须具有以上条件，我们必须在做设计展现时也尽量确保以上条件。但在这些状况下原来并不能完全满足，这个之后我们必须按照业务目标的重要性来选取这些点进行满足。

五、写在最终

梳理一下整体文章的架构，其实是根据「是哪个-为什么-如何做」的方式来进行拆分的：

这篇文章想要表达的看法，不是让设计师独立去梳理整体信息构架，而是让设计师拥有信息构架意识，了解其是怎样进行并形成的。这样你在发现整体架构时，有足够的理论支撑去推断它的好坏，并借助自己的理论思维去理解和改进不好的地方。

当我们对信息架构有足够的感知时，我们在设计页面时才会有合理的反思方向，做出「正确的设计」，避免变成无情的作图机器。信息构架作为产品交互视觉最底层的支撑，只有骨架搭好，对于用户的使用感受才无法有本质上的强化。

注：文章中不可导致会存在不足之处，如果对文章中内容有更好建议，欢迎随时交流。

参考资料：

本文由@阿东授权公布于人人都是产品经理，未经许可，禁止转载

题图来自unsplash，基于CC0协议