天猫网站内容架构分析(B端设计师存在的意义和价值到底体现在哪里？)

　　天猫网站内容架构分析(B端设计师存在的意义和价值到底体现在哪里？)

　　信息架构的深度解读，希望对大家有所帮助。8500+字，建议配茶喝

　　信息架构是我现阶段比较难学和讲解的知识点，网上关于信息架构的知识内容也参差不齐。在学习和探究的过程中，查阅了大量资料，反复修改多次，并尝试用通俗易懂的语言结合实例来说明信息结构。目录如下：

　　

　　可以根据以上目录选择性阅读，当然全文阅读也很棒~

　　

　　1. 前言

　　这个文章的由来来自于“B端设计师会被组件库取代吗？”的话题。从表面上看，在组件库越来越完善的时代，很多页面设计都可以依靠组件库来快速构建。

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

　　这种设计能否完成相应的业务目标和产品目标；我们的信息呈现是否合理，能否解决当前的需求；用户能否在页面上快速找到自己想要的信息；

　　为了澄清和解决上述问题，在对很多话题进行阐述之后，我发现讨论本质上都逃不出“信息架构”的概念。所以我认为设计师需要对这个概念有一个充分的理解，它可以帮助我们做出正确和优秀的设计。

　　2. 信息架构概念

　　关于信息架构的概念，维基百科上的大部分定义都比较晦涩，比如维基百科和百度百科的解释：

　　

　　相信大多数人都很难理解描述的含义。这里是另一种思路，将信息架构分为信息架构和理解架构。

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

　　

　　通俗的说，信息架构就是让用户更容易理解我们的产品，让用户更顺畅、更自然地使用我们的产品。因此，信息架构没有具体的表现形式，它更多地体现在产品设计的方方面面。具体来说，主要表现为组织系统、标签系统、导航系统和搜索系统。

　　

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

　　降低认知成本需要我们更好地表达信息，让用户看到我们的产品能做什么以及如何使用；提高使用效率，我们需要提高信息传递的效率，让用户可以方便的找到自己需要的功能；

　　从本质上讲，信息架构正是研究信息的表达和传递。因此，我们需要利用它来帮助我们更好的完成B端产品设计。如果没有底层支持的信息架构，那么我们在页面上看到的可能只是一堆功能的堆砌，让产品很难用或者在尴尬的情况下不知道怎么用。

　　强大的信息架构是产品质量的保证，是设计支撑点的支柱。它将减少可用性问题，改善整体导航，并创造用户友好的体验。举个工具层面的例子：

　　

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

　　可以说，良好的信息架构是高效用户体验的基础。视觉元素、功能、交互和导航都建立在信息架构的基础上。所以，要想做出一个有经验的、合理的页面设计，就需要参与到信息架构的过程中，用产品完成相应的架构。而不是从原型到页面完成这部分。

　　

　　如果我们想要建造一座好的建筑，我们需要知道它建造的目的，它是用什么样的结构建造的，里面有什么系统，它最终是什么样子。

　　信息架构也是如此。我们首先需要知道信息是干什么用的，然后我们用什么结构来组织信息，过程中会用到哪些信息元素，以及最后如何呈现。这些都是我们在构建信息架构时需要采取的所有必要步骤。如果有些环节没有做好或者没有完全理解，那么在输出信息架构时，往往会出现方向或策略的问题。接下来我们看看这些步骤是如何详细呈现的。

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

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

　　我个人认为理解业务的基础是能够用一句话清楚地解释当前的设计产品。这句话可以形容为：谁想在什么地方完成什么目标。比如“用户想出去就可以吃”，这就是外卖软件提供的产品和服务。

　　这句话看似简单，却收录三个要素：用户、场景、目标。因此，我们在分析和梳理业务的过程中，首先要了解这三个要素。

　　

　　用户：区分买家和用户

　　用户永远排在第一位，我们要先搞清楚。在B端设计中，本质上有两种角色：客户和用户。比如我们经常使用钉钉或者企业微信。采购客户是公司，实际用户是员工。

　　客户决定购买我们的产品（在某些情况下也会考虑使用），用户决定后续产品的复购率。因此，在业务理解上，我们需要弄清楚当前产品的服务阶段。比如前期，我们必须更偏向客户，才能打开市场，而在中后期，我们会偏向用户，以提升产品体验。

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

　　场景：需求来自场景

　　情景是指需求产生的一定条件。该条件包括但不限于环境、时间、地点、空间等，只有满足上述条件才能成立。在这里，场景可以理解为问题的原因。

　　例如，当用户问“她需要一件衣服”时，那么我们需要弄清楚用户为什么需要添加衣服，她是因为冷还是因为外面冷而感到冷。这两种场景所涉及的解决方案是完全不同的。

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

　　通过业务方文件初步了解业务背景。业务文档一般包括需求背景，我们可以通过文档初步了解。通过业务交流进一步加深对业务背景的了解。因为很多B端业务都离设计师自己的生活很远。因此，对于需求背景中不了解或比较模糊的部分，我们可以通过与业务方或产品的多次沟通来探索底层背景。

　　

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

　　目标：业务目标和设计目标

　　目标决定了我们产品的最终方向。我们首先接触到的一般是业务目标，而我们这次要做的就是将业务目标转化为我们的设计目标。

　　A. 业务目标

　　业务目标是业务想要解决的实际问题。它通常是一个宏描述。例如，叫车软件的商业目标只是让用户更快地叫到*敏*感*词*，减少等待的焦虑。我们通常通过文档或交流来理解这个目标。

　　B. 设计目标

　　设计目标是我们根据业务目标给出的设计策略，是一种更具体的实*敏*感*词*额等要素，需要思考它们之间的关系以及呈现方式。

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

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

　　从上一篇我们可以看出，我们在整体的设计过程中会有很多的信息元素。如果没有相应的组织和处理，将它们堆叠在一起，信息的含义将是混乱的，难以调用。例如，以下内容：

　　

　　右边的图片信息的组织过程可以理解为对分散的数据信息进行分类，然后将它们重新组合成结构化形式的过程。说白了，就是先分类，再结构化呈现。我用一张图来说明这个过程：

　　

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

　　组织方式：模糊分类和精确分类

　　组织方法可分为精确分类和模糊分类。准确分类是指我们将利用物体本身的物理特性进行分类，如位置、字母、时间、类别、级别等进行组织。一些工具应用如勾选列表内容信息是按时间组织的：

　　

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

　　

　　但在很多情况下，产品倾向于将这两种组织方式结合起来，形成一个复合组织，这样可以让我们的整体组织更加符合用户的习惯。例如，蓝湖的信息组织包括模糊分类（按使用类型等分类）和精确分类（按文件上传时间等分类）。

　　

　　事实上，大部分B端产品都是按照模糊分类处理的，比如按照任务和流程。精确分类更多用于页面中的本地信息模块，例如创建时间和文件大小。

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

　　组织结构：选择合适的结构类型

　　信息按照分类维度进行组织后，下一步就是对整体信息进行结构化，使信息可以作为一个整体进行连接和呈现。一般分为以下四种组织方式：

　　A. 层级结构（最重要的结构）

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

　　

　　层次结构的优点是可以承载复杂的多层次内容，通过层次化的方式可以将复杂的多层次拆解得更简洁。

　　但是我们需要控制内容的广度和深度。宽度是指层次结构中每一层的数量，最好控制在七以内。如果宽度过宽，则意味着每个页面都会向用户展示过多的信息，增加查找内容的负担。深度为纵向结构，一般推荐3层，最多不超过5层。太深的层次会让用户点击多次，不容易被用户发现。例如，飞书的基本信息结构主要是在层次结构中进行的。

　　

　　B.矩阵结构（多维结构）

　　矩阵结构是一种信息架构方法，其中每个节点都相互连接。一般来说，用户可以通过多个维度到达同一个信息，或者从一个维度连接多个信息。

　　

　　这个结构其实更像我们在做相关功能的时候：比如当你进入电影全屏想要退出的时候，既可以点击按钮退出，也可以通过Esc返回键盘，您可以通过多次触摸达到相同的操作。.

　　另一个例子是我们的联系功能。我们既可以通过输入号码拨打电话，也可以找到联系人拨打电话，也可以查询电话记录回拨。

　　

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

　　C. 自然结构（随机性）

　　自然结构不遵循任何一致的模式，节点都一一相连。

　　

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

　　

　　但是一般的自然结构并不是单独存在的。比如B站也将层次结构绑定到自然结构上来划分层次。

　　D. 线性结构（奇点）

　　线性结构是一个很单一的结构，整体是一层一层一层一层。更强调秩序的结构。

　　

　　这种结构通常用在我们常用的软件安装程序等中，也可以用在部分功能结构中，比如网站视频发布，一般通过上传-编辑-发布三个步骤。

　　

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

　　注意：注意用户的心智模型

　　在信息组织的过程中，我们需要关注用户的心智模型。比如看到红点就知道有新的信息通知，看到下拉箭头就知道可以展开。这是互联网产品无形中为用户创造的潜在习惯认知。目前，用户已经对常见产品的一些基本布局、功能名称、交互逻辑等形成了一定的习惯，属于用户心智模型的内容。

　　所以，我们在整理信息的时候，尽量不要打破用户的共同心理模型，否则难免会导致用户的不习惯。我们常见的“扫一扫”功能，微信、支付宝又会隐藏在“+”号里。但是，微博和抖音分别放在“我的”和“搜索”中。

　　

　　这将使用户难以发现此功能。因为当用户接触到新的信息时，他会根据最初接触到的部分信息，发展形成初步的认知。用户认知中的信息组织逻辑与实际信息的一致性越高，他查看或查找的信息就越多。过程中体验会更顺畅。相反，如果一开始形成的认知与实际信息相差过大，则在后期的信息搜索过程中容易遇到困难。而这种一致程度其实就是用户的心智模型。

　　虽然建议在一定程度上跟随用户的想法，但并不意味着绝对跟随。对于用户不熟悉的场景或某些技术术语，我们需要通过灵活有效的提示（如标记注释等）来引导用户。比如我们刚刚提出的抖音扫描，它的应用场景其实是用于抖音官网的后台登录，在后台登录的时候已经给出了相应的提示，那么这个设计也合理。

　　

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

　　经过上面的信息组织，其实我们已经可以总结出一个通用的信息架构框架了。但除了信息组织，我们还需要关注以下三点：标签、导航、搜索。这对于信息架构的完整性也非常重要。

　　标签系统：让信息识别更加通用

　　标签系统，一般来说，需要我们对当前整个系统的信息节点进行命名，以便于信息的呈现方式更容易识别。以最简单的例子来说明：

　　

　　您可以在左侧和右侧看到有关厕所的信息标志。左边你可能一眼就能分辨出来，右边可能需要很长时间才能反应过来猜是什么意思。

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

　　A. 优先考虑行业广泛接受的文字或图标

　　在定义标签时，尽量选择用户已经熟悉的词。比如“工作台”、“*敏*感*词*”等用的很熟练，类似的功能直接以这种形式命名，比如在我们的设计软件中，很多图标和功能名称都是通用的：

　　

　　这样可以大大降低用户的学习成本。因此，在B端设计中，我们也需要关注我们行业中哪些条款已经达成共识，所以没有必要创造新的条款。

　　B. 不确定词可以参考竞争产品或研究来做决定

　　当某类功能或场景的标签难以确定时，我们可以尝试寻找竞品是否有类似功能，或者寻找行业领先者（如聊天工具巨头微信），然后在定义时标签，可以参考它的命名系统。因为它已经为我们教育了一些用户，所以会间接降低学习成本。

　　如果在上述过程中某些标签还不清楚，那么我们可以根据自己的经验或咨询业务的相关人员进行讨论。必要时，我们可以在标签旁边添加注释以进一步说明。

　　导航系统：防止用户迷路

　　导航系统应该是大家比较熟悉的系统。就像使用导航系统规划行程一样，导航系统会存在于每一个网站。比如我们常见的侧边导航、顶部导航等。

　　

　　因为网上已经有很多关于导航系统的资料了，下面介绍下四种导航的含义：

　　全局导航：页面最顶层的导航，用户几乎可以在页面的任何地方看到，是最高级别的导航系统；本地导航：位于顶部导航下层的子类导航。子类导航不是必要的导航。根据场景选择；情景导航：点击文字链接跳转的导航，比如在*敏*感*词*中嵌入其他网站链接地址；辅助导航：这里包括网站地图、网站索引、网站指南等辅助导航类型。

　　网站 辅助导航指南包括新手指南和演示教程。这个阶段比较巧妙的功能引导是在执行某些功能时及时提示用户。这样既达到了引导用户的效果，又减少了对用户的一系列新手引导的中断。比如figma更新组件后，只有在调用组件函数时才会及时提醒。

　　

　　搜索系统：让用户轻松查找信息

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

　　

　　内容复杂度：如果当前页面承载的内容的复杂度较小，通常不需要搜索简单的内容页面；内容性质：当前页面性质偏向于用户浏览或搜索，根据用户行为是否需要搜索；搜索场景：如果搜索场景简单，考虑是否可以只通过过滤或分类来解决问题；相反，如果搜索内容比较复杂，我们也可以通过搜索过滤来更好的查找信息；

　　以上3点决定了我们是否需要考虑搜索功能。关于搜索的其他细节，如搜索规则、搜索结果等，这里不再赘述。这个文章中更重要的是弄清楚我们什么时候需要搜索功能。

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

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

　　在学习的过程中，我发现有些材料认为信息架构只是一个思维导图，但实际上，信息架构并不能完全用思维导图来表示。

　　

　　因为信息架构收录很多部分。只能说，思维导图可以是信息架构的一种体现，可以帮助我们在思维阶段梳理出整体产品的信息构成。

　　这里有一个很有趣的观点，就是“功能*敏*感*词*”和“信息架构图”是什么关系。下面是两个图表示例：

　　

　　可以看出，功能*敏*感*词*更多的体现在功能描述的形式，一般的形式是名词+动词，比如头像设置；并且信息*敏*感*词*应该关注信息元素，一般是名词，比如头像图片。

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

　　因此，本文章所描述的信息架构更倾向于基于产品的整体架构。其实信息架构对表现形式没有特别的限制，只要能帮助你清晰的表达出产品的整体结构即可。事实上，第四版《信息架构：超越网页设计》并没有对表达形式提供严格的定义。它用“显示信息元素-站点地图之间的关系”这句话概括了信息架构的呈现形式。, 表示如下：

　　

　　可见，它的表达形式包括思维导图和流程图：思维导图的优点是可以概览整体信息，查看信息的深度和广度，而流程图的优点是可以更好地表达整体的逻辑关系。

　　因此，信息架构的呈现需要根据你的产品场景选择合适的视觉框架表达。没有必要让形式限制我们的表现，但形式应该遵循我们的结构表达。它只是信息梳理结构的解释结果（类似于中间状态），我们需要用它来更好地阐述思想和交流思想。

　　5. 信息架构之后：让信息可视化

　　输出信息结构后，其实我想说说页面的呈现。因为整理了大框架之后，剩下的页面细节其实还需要在原型图中体现出来。这个过程是从框架到页面的阶段。其实对于设计师来说也是一个非常重要的部分。下面根据我自己的理解，列出以*敏*感*词*意事项：

　　

　　A. 页面可以被用户理解

　　这其实和我们的信息组织和标签制度有关。如果我们的某个页面不允许用户第一时间获取该页面上表达的信息，请反思他们做得不好的地方。是标签系统的含义不明确，还是信息的组织和分类有误？从页面呈现反转信息架构。

　　一般来说，设计的安排应该考虑用户的心智模型（如网页的规则布局和常用名词的定义等），对一些难以理解的地方给用户提供帮助和解释。虽然B端产品不可能完全避免学习成本，但我们可以将它们的学习成本降到最低。

　　B. 考虑用户的视觉运动

　　我们在整理信息的时候，需要考虑的是用户的视觉运动，也就是我们常说的视觉浏览的“F型”和“Z型”。对于不同的信息流，使用不同的流模型可以让用户更好地查找信息。

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

　　C. 控制适当的信息水平

　　由于B端没有太多的视觉发挥空间，相对来说，保持良好的信息水平可以让整体体验更好。

　　无论是原型还是视觉，都必须更加清晰地体现出整体的视觉层次。按理说，最好的视觉层次控制在三个级别左右。如果发现视觉层次太多，需要考虑是不是因为信息架构设计中垂直层次太深，可以调整架构的形式，更好的呈现信息。并对同一页面上信息的重要性进行分类。

　　

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

　　

　　业务层：

　　设计目标合理：可以平衡业务目标和用户目标，保证客户和用户有比较好的体验；核心任务目标：使用户能够顺利完成产品的核心任务，需要通过用户测试来验证

　　结构层：

　　平衡广度和深度：使用功能时，不会隐藏太深找不着。是否有冗余步骤保证可扩展性：当前的信息架构可以稳定扩展，以应对未来信息的增删

　　体验层：

　　保证易读性：用户无需介绍即可通过页面信息了解产品的用途。保证易搜索性：用户在需要某项功能时能否快速找到该功能，以及是否有多种搜索方式（如搜索或过滤）

　　一个合理的信息架构需要具备以上条件，而我们在设计和呈现时需要尽可能保证以上条件。但在很多情况下，并不能完全满足。这时，我们需要选择某些点来满足业务目标的重要性。

　　

　　梳理文章的整体结构，其实是按照“what-why-how”的形式拆分的：

　　

　　这个文章想要表达的一点，不是让设计者独立梳理出整体的信息架构，而是让设计者有信息架构的意识，了解它是如何进行和产生的。这样，当你看到整体结构的时候，你就有足够的理论支撑来判断它的好坏，用你自己的理论认知去理解和改进不好的地方。

　　当我们对信息架构有足够的了解后，我们就可以在设计页面时有一个合理的思考方向，做出“正确的设计”，避免成为一个无情的绘图机器。信息架构是产品交互视觉的底层支撑。只有架设了骨架，才能大幅提升用户体验。

　　注：文章难免有不足之处。如果您对文章中的内容有更好的建议，欢迎交流。

　　八步卡片整理法助您确定商品信息结构

　　卡片排序方式可用于网站或应用导航、信息架构等项目。它还可以用于文档和电子书的结构和组织或文件的分类和管理。

　　阅读文章>