如何理解并应用信息架构？这篇文章带你系统了解

内容导航：

如何理解并应用信息架构？这篇文章带你系统了解

什么是系统架构设计?

如何应用企业架构？

在高级产品经理眼里，产品架构是怎样的

一、如何理解并应用信息架构？这篇文章带你系统了解

合理的信息架构可以更清楚地反映出产品的核心价值，也能提升用户对产品的认知、助推用户的操作进行。那么，信息架构由哪些部分构成，信息架构又可以如何恰如其分地应用于产品交互设计中？本篇文章里，作者对信息架构设计做了详细解读，一起来看。

前言

第一次认识「信息架构」，还是刚入行的时候。当时做B端产品，经常会研究产品的信息架构，利用思维导图工具输出一份关于功能的结构图。

当时信息架构主要应用在两个方面：

1）竞品分析

信息架构基本是竞品分析的必备环节。主要是将竞品产品功能（侧重导航系统），采用脑图的形式罗列出来（颗粒度有时粗有时细），勾画出产品的功能体系，展示出信息组织结构。根据前辈的经验，将架构大致会分为「宽而浅」和「窄而深」两种形式进行一通分析，得出一个比较主观的结论。

2）界面设计层面

在实际的设计应用时，信息架构更偏向于导航菜单的组织结构。设计师需要将产品功能清单进行结构化梳理，曾经尝试过卡片分类法等，搭建起整个产品的导航菜单结构，并对菜单命名做出一定的优化建议。

总体来说，对信息架构的理解还是比较浅薄的。今天我们来系统地了解下信息架构的知识。

一、信息架构的定义

信息架构（information architecture，缩写为IA）是指对某一特定内容里的信息进行统筹、规划、设计、安排等一系列有机处理的想法。

IA 的主体对象是信息，由信息架构师来加以设计结构、决定组织方式以及归类，好让使用者与用户容易寻找与管理的一项艺术与科学。

——百度百科

定义都是概括性极强的，读起来会比较晦涩难懂。但是我们可以从中获得一些关键信息。

1. 对于产品

信息架构是产品信息的组织、归类方式。需要能够真实地反映出产品的核心价值、展现出主线功能、特色功能，提升用户对产品的认知。

2. 对于用户

信息架构要方便用户理解，并能够帮助用户顺利地找到对应的功能完成操作。在信息架构设计时，要充分考虑用户的理解能力、操作习惯、目标内容使用频率等因素，符合用户认知从而提升用户体验。

二、信息架构与交互设计

在用户体验5要素中，信息架构归属于结构层，主要是面向信息型产品。功能型产品的结构层主要指的是交互设计。

交互设计和信息架构都强调⼀个重点：确定各个将要呈现给⽤户的元素的“模式（patterns）”和“顺序（sequences）”。交互设计关注于将影响⽤户执⾏和完成任务的元素。信息架构则关注如何将信息表达给⽤户的元素。

——《用户体验要素：以用户为中心的产品设计》

两种产品类型为什么会有交互设计和信息架构的区分呢？说一下我个人理解。

1. 信息型产品

信息型产品就是我们常见的各类网站，例如门户网站、品牌官网、知乎、今日头条、或者腾讯视频等内容类产品。这些产品主要是为用户提供各类信息，任务类操作比较少。

网站最终的任务是给予用户足够可用、有效的信息，确保用户在产品中不会迷失或者无法找相应的信息入口，所以结构层的主要任务是构建符合用户认知的信息架构，便于在框架层以此架构为基础完成界面、导航设计。

2. 功能型产品

功能型产品更多的是中后台管理系统，目的是帮助特定的用户完成各种任务，包含了各种流程。在产品中用户会有大量的操作，功能之间可能互为前置条件或者相互协同。

例如用户在商品加购之前，需要完成登录。或者管理员在增加用户之前，需要提前设定系统用户角色。所以对于功能型产品，除了确定信息架构，还要明确好功能之间的交互逻辑关系。

我认为在结构层中，交互设计和信息架构并不是绝对割裂的，功能型产品同样需要制定信息架构，只不过信息架构相对固定，需要遵从用户的业务场景、工作流程等，设计师不能根据自己的理解随意更改。

另外随着业务场景和功能的发展迭代，有些产品已经不能通过简单信息型产品或者功能型产品进行划分。例如电商网站，既要提供商品信息供用户选购，还要提供购物车、下单、支付、物流、售后等一系列的环节，每个环节之间都是环环相扣。因此，在结构层需要信息架构和交互设计并重。

三、信息架构的构建方式

信息架构最核心的是确定产品信息的组织形式，我们可以采用以下两种⽅式来建⽴分类体系：「自上而下」或「自下而上」。

1. 自上而下

这种分类方法从“战略层”（产品目标）出发去考虑内容分类。即根据产品目标与用户需求直接进行结‍构设计。最先从最广泛的、可能满足决策目标的内容与功能开始进行分类，然后在按逻辑细分出次级分类，这样的“主要分类”和“次级分类”就构成了“一个个空槽”，将想要的内容和功能按顺序一一填入即可。

我理解这样的方式是从产品视角出发，根据功能清单，结合用户场景，逐级建立起信息分类形成产品的信息架构，最后将功能/内容放入到信息架构中。

这种方法比较适合B端产品，产品功能和用户业务场景比较明确，并且是紧密结合在一起的。比如财务报销需要包括提单、审批、支付、消息、记录等等环节。信息架构也要按照这些场景和流程进行归类，便于用户理解和找寻。

此外对于C端产品，某些用户需求和场景并是不特别明确，需要产品主动构建信息架构引导用户需求，此时也需要自上而下建立信息架构。例如电商产品中引入短视频，首页的订阅方式等，短视频产品中的同城、兴趣等功能。这些是基于用户洞察，产品自上而下推进信息结构的优化升级。

2. 自下而上

这种分类方法是根据对“内容和功能需求的分析”⽽来的。先从已有的资料（或者当⽹站发布后将存在的资料）开始，我们把这些资料统统放到最低级别的分类中，然后再将它们分别归属到较⾼⼀级的类别，从⽽逐渐构建出能反映我们的产品⽬标和⽤户需求的结构。

当产品已经拥有了内容，但是并不明确如何进行归类，才符合用户的认知和需求。这是就可以采用自下而上的方法倒推，建立信息架构。对于信息量不大的产品，可以做几版方案，找些用户进行测试就可以得出结论。对于信息量会比较大的产品，可以采用卡片分类法，让用户参与其中，为信息架构设计提供参考依据。

我个人认为，在实际的应用中自上而下的创建方式居多，这种方式从产品和用户两个维度出发，可以搭建出比较平衡的一套信息架构。

四、信息架构的构成

在《信息架构——超越Web设计》一书中，将信息架构定义为：

——共享信息环境的结构化设计；——数字、物理和跨渠道生态系统中的组织、标签、搜索和导航系统的合成；

——创建信息产品和体验的艺术及科学，以提供可用性、可寻性和可理解性；

——一种新兴的实践性科学群体，目的是把设计和建筑学的原理理导⼊入数字领域中。

《信息架构——超越Web设计》

这就意味着信息架构不仅仅是我们看到的导航菜单，只不过由于导航菜单是信息架构的直观表现形式，所以常常被理解为“信息架构就是导航菜单”。

信息架构包含了4大系统：组织系统、标签系统、导航系统、搜索系统。

1. 组织系统

组织系统是信息架构的根基，决定了信息架构的基础逻辑，可以拆解为组织方案与组织结构两个模块。

1）组织方案

组织方案就是产品信息的分类逻辑，需要根据用户、场景和业务逻辑进行组织和定义，在产品中信息的归属有不同维度和标准，大致可分为精确信息和模糊信息2类。

有些信息可以按照精确的维度进行划分。例如首字母、时间、行政区、组织结构、文件类型等。精准的信息组织方式可以保证将信息分成定义明确且互斥的区域，容易设计与维护。

但是一些信息缺少明确的划分标准，属于模糊信息。例如网站栏目的划分、电影的分类等，更多的是按照业务和用户认知习惯确定组织形式。

常见的模糊组织方案主要有以下几种方式：

① 主题组织方案

当我们无法按照精确分类时，可以按照用户场景、业务逻辑归纳为符合用户认知的主题（频道），搭建信息架构的基础分类。例如品牌官网的信息归类方式。

② 任务导向方案

任务导向的组织方案通常用在对操作要求较高的工具型产品中，信息架构的基础分类是各种功能的集合。例如WPS工具栏就是按照任务导向分类的。

③ 特定受众方案

特定受众的组织方案即根据不同类型的访问者呈现不同类型的信息。以受众为导向的信息组织方案会把网站切分成更小、以受众为主的小型网站，可以在网页上呈现特定用户感兴趣的内容，避免网页的杂乱。

例如Boss 直聘中用户可以拥有“牛人”和“Boss”两种角色身份，信息内容、组织形式有着明显的差别。

另外随着老龄化人口比重越来越大，无障碍设计成为了产品设计的重要组成部分。无障碍设计并不仅仅是将字体变大，在产品内容、信息结构上也会有一定的优化调整，内容更加精简、聚焦于产品核心功能。

总的来说，特定受众方案应用还是比较少的。有的C端产品会根据用户角色划分为多个产品，例如滴滴出行有乘客端和司机端两款产品。

而在B端产品中，角色划分通常比较多，并且不同的角色间有着比较强的业务关联。因此用户会共用一个产品，通过角色权限区分不同的信息架构。

④ 混合方案

在一款产品中，单一的分类模式很难满足所有场景的需要，信息架构应该根据实际情况，灵活地采用多种方式混合分类。

2）组织结构

组织结构指的信息架构内在的逻辑结构，分为以下四种组织方式：

① 层级结构

在层级结构中，节点与其他相关节点之间存在父级/子级的关系。子节点代表着更狭义的概念，从属于代表着更广义类别的父节点。不是每个节点都有子节点，但是每个节点都有一个父节点，一直往上直到整个结构的父节点。

层级结构是信息架构中最常见的形式，信息多级逐层展开。因此具有很强的拓展性和包容性，可以承载复杂的信息量。并且节点之间是相互独立的，内容的归属比较明确，构建的单个信息空间也比较清晰简洁。

层级结构会存在广度和深度的问题。在信息总量一定的情况下，可以分为「宽而浅」和「窄而深」2种不同的形式。

「宽而浅」的结构意味着父节点越多，子节点层级就会变少。「窄而深」的结构意味着父节点比较少，子节点的层级就会变多。

信息架构增加广度，意味着信息的入口增多，用户不太容易辨别目标点的归属，就会增加寻找和记忆成本。最上层的信息入口，我们一般会遵循7±2 原则，Web端产品控制在7个以内，移动端产品控制在5个以内。

子节点层级一般为3层，最多不超过5层。过深的层级会造成信息难以查找，同时用户到达目标点的路径会变长，操作成本也会相应的增加。

② 矩阵结构

矩阵结构允许用户在节点与节点之间沿着两个或更多的“维度”移动。由于每一个用户的需求都可以和矩阵中的一个“轴”联系在一起，因此矩阵结构通常能帮助那些“带着不同需求而来”的用户，使他们能在相同内容中寻找各自想要的东西。

矩阵式结构是一种多维度结构，可以让用户在相同的内容中按照个人需求找寻自己所需的信息，最典型的就是产品首页信息。作为产品内容聚合、分发的页面，可以满足用户的不同需求。目前不少C端产品都采用的是「主题+推荐」的模式，通过算法实现产品内容与用户需求的高度匹配。

B端首页则是依靠「角色+场景」构建起产品的矩阵结构，实现功能的快捷直达，以及重要信息的清晰展示。

另外矩阵式结构还体现在链路关系上，没有层级和中心的概念，更加强调信息之间的互联互通。通过这种连接关系甚至可以将跨领域、跨层级的信息关联起来。

比较典型的就是电商App，通过商品详情页可以到达店铺、到达同类推荐产品、到达客服、到达购物车、到达活动页面，甚至是搭配商品等等。这种结构具有很强的自由度和灵活性，既可以避免用户行为进入「死胡同」，又可以通过多重的信息连接，丰富产品的运营场景，带给用户更多的可能。

当然这种结构的前提是信息必须是关系紧密的功能场景，否则信息会出现错乱，并增加用户的认知负担。

③ 自然结构

自然结构不会遵循任何一致的模式。节点是逐一被连接起来的，同时这种结构没有太强烈的分类概念。自然结构对于探索一系列关系不明确或一直在演变的主题是很合适的。但是自然结构没有给用户提供一个清晰的指示，从而让用户能感觉他们在结构中的哪个部分。

自然结构具有随机性和不确定性，随着算法的提升，这种结构应用越来越广泛。最常见的就是各种推荐信息流，电商平台、音视频、资讯平台等产品都主打推荐频道，透过投喂的方式，吸引没有明确需求的用户，给他们更多的选择。

不过自然结构的随机性意味着用户无法建立固定的信息架构认知，所以自然结构不会单独存在，只是对信息架构的补充。另外在B端产品中，用户通常具有明确的任务和目标，所以自然结构并不适用于B端产品。

④ 线性结构

线性结构来自于你最熟悉的线下媒体。连贯的语言流程是最基本的信息结构类型，而且处理它的装置早已被深深地植入我们的大脑中了。书、文章、音像和录像全部都被设计成一种线性的体验。

线性结构是比较单一的信息结构，信息有先后顺序要求，逐层向下递进，并且没有交叉。这种组织形式决定了线形结构主要用在简单产品或者产品信息构架的末端场景中。

例如在微信读书中，打开书籍后用户只能一页页翻看，不会与其他书籍有交叉关联。在OA，电子邮箱等产品中，每一个流程，每一封邮件都是线性的、相互独立的，信息之间不会增加不必要的关联。

2. 标签系统

标签系统指的是整个产品信息节点的命名体系，静态展示了产品信息架构的具体内容，包含文字和图片（图标）2种信息。标签系统需要符合用户的认知习惯，减少用户的学习成本。在日常设计工作中，标签系统需要注意以下3个方面：

1）标签内容的准确性

标签定义时，需要准确地表达信息的内容项。举两个例子：

在C端领域为了提高用户的点击率，经常会遇到一些信息融合累加的设计形式。例如宣传用语是“立享300元福利”，用户点开一看，或许只是10张优惠券。这种设计利用了用户“贪便宜”的心理，已经成为了行业约定俗成的表达形式，倒也可以接受。

不过之前有个营销弹窗的案例，用户点击后跳转到活动页面，然后逐个领券。弹窗中按钮有两种方案，A方案是“开心收下”，B方案是“立即领取”。

虽然后台有历史数据显示，“开心收下”的文案用户点击率比较高，并不意味着这个文案可以用在所有场景下。“开心收下”意味着完成领取并入账，“立即领取”则是需要继续操作才能完成领取，两者适用于不同的场景。

标签系统首先要考虑表达的准确性，要符合用户的心智模型以及所代表的行为模式。

2）优先选用行业通用的术语或图标

尼尔森十大可用性原则中要求「贴近用户真实环境」。在标签定义的时候，尽量使用目标用户的语言。尤其在B端产品中，不少名词对设计师而言比较陌生。但是对专业领域的用户，这些都是日常工作术语，早已达成了共识。如果做出改变，反而会增加用户认知成本。

所以设计师要克服自己的认知缺陷。一方面要了解业务、通过用户调研，建立更符合用户认知的标签系统，另一方面也可以参考竞品来学习和应用信息标签。

为了保证新、老用户的快速了解系统，最大程度地降低学习成本，可以在标签旁边添加注释进一步说明。例如英文缩写术语、容易引起歧义的指标、不易理解的标签等等。

对于图标，有些是各个产品通用的形式，用户很容理解。例如「设置」、「删除」、「帮助」等。还有相当大一部分图标很难准确表达出内在信息，就需要增加文字信息，辅助信息表达。

3）标签信息简洁高效

标签系统既要完整表达信息，也要注意信息的简洁高效。

例如下图中菜单命名，大量重复的信息增加了信息识别的难度，并且名称字数没有控制导致内容截断，也会增加用户的操作成本。

3. 导航系统

导航系统是信息架构的动态交互逻辑。一方面能够告诉用户当前所处于的位置，页面信息的层级归属，让用户不会在产品中迷失方向。另一方面导航系统实现了信息的动态联接，用户可以依靠导航系统在不同的层级结构中「闪转腾挪」，高效操作。

导航系统分为4大类：全局导航、局部导航、情景式导航、辅助导航。

1）全局导航

全局导航是面向整个产品的导航形式，通常位于系统的整体框架中，实现在所有页面中可见、可操作。所以全局导航也只是对产品的核心、关键功能和部分即时功能开放。

例如信息框架中的一、二级的信息，或者消息、用户管理这类即时、强管理的内容。

2）局部导航

局部导航是全局导航的补充，对于复杂的产品，局部导航非常有必要，避免全局导航变得臃肿复杂，有利于信息逐级有序地展开。

3）情景式导航

情景式导航又称为上下文导航，指的是根据当前场景或者内容产生的信息链接关系。例如文章内的超链接，或者是标题信息等，点击可以跳转新的网页、下载文件或指定某个对象等。情景导航中可以承载产品外部的内容链接，不必完全是本产品中的内容。

4）辅助导航

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

4. 搜索系统

搜索系统解决的是大容量、高密度信息的定位问题。大到全产品范围内的搜索，小到当前列表搜索，基本成了产品中的必备功能。即使有些产品中搜索功能，用户的使用频率不高，也是需要配备的，方便用户的不时之需。

「搜索」系统对外呈现或许是一个带着图标的输入框，甚至只是一个图标。但是操作则是一个多种状态的融合的交互过程，包括了输入前、输入中、搜索结果展示等内容。系统比较复杂，大家可以去找一些专门的文章学习，也可以看一下我之前的文章《关于搜索设计中3个原则，你知道吗？》。

5. 小结

以上就是信息架构的4大组成系统。信息架构的最终目标是为了让用户能够更快速地获取信息。在实际应用过程中，可以根据产品类型，用户群体做出内容取舍。

值得注意的是，信息架构最重要的标准，不是“整个过程一共需要多少步骤”，而是“用户是否认为每一个步骤都是合理的”，以及“当前的步骤是否自然地延续了上一个步骤中的任务”。

五、信息架构的影响因素

信息架构是为产品和用户服务的。因此信息架构的影响因素主要是来自于这两个方面。

1. 产品视角

1）产品目标及定位

同类型产品的目标、定位、用户群体并不是完全相同的，在各自的细分领域形成了各自的差异化优势。这些都会直接和间接地影响产品的信息架构。

例如国内3大电商平台的主导航基本一致，但也不是完全相同，大家可以体会和思考下其中的差别。

2）产品类型

上面不少案例提及了B端和C端产品，由于产品类型、适配终端、产品目标等方面的影响，信息架构有着比较明显的差异。同样都是C端产品，购物类产品重搜索与推荐，金融证券类产品则是重功能导向，界面看似一致的，但是信息架构中组织系统、搜索系统背后的逻辑也存在较大差异。

3）产品复杂度

简单产品的信息架构也会比较简单，或许线性的组织结构就可以搭建起核心业务的信息架构，例如QQ邮箱。

复杂产品的信息架构会运用多种组织结构方式，相关的标签系统、导航系统、搜索系统都会加强。例如云类产品的标签系统，既要考虑整体的一致性，又要明确各个产品间的差别。搜索功能也不仅限于产品功能，还会拓展到活动优惠、帮助文档等内容，让用户搜索得更彻底。

2. 用户视角

1）用户需求

产品不能一味的只考虑自己的产品目标，还要考虑用户的接受程度。就好比舞台上高雅的古典歌剧，只顾展示自己的专业能力，而底下观众根本听不懂唱的内容，必然无法引起观众兴趣。

如果不重视用户需求，产品设计时，只顾着各种高级能力输出、各种复杂的产品流程，但是从没有考虑用户是否需要这样的产品，带来的结果就是信息架构的无序扩张、内容庞杂、过程混乱，最终成为产品体系的「自嗨」。

2）用户认知能力

不同的用户之间认知能力有很大的差别，信息架构需要面向目标客户群体完成信息架构。

例如之前做过门店后台管理系统改版设计，通过前期调研发现，店员们年龄偏大、学历不高，老版本的信息架构虽然足够的大而全，但是核心功能并不凸显，用户操作流程也被拉长。因此在改版设计时，信息架构做了精简，优先聚焦打造用户核心任务，减少信息的复杂度。

六、信息架构的设计原则

将信息架构抽离出来，其实包括了组织体系、展示形式和操作体验3个环节。相应的也会有3个设计原则。

1. 延展性

产品是不断成长迭代的，信息架构需要具有兼容性和弹性，可以适应多个层级的扩展或精简，保证一定迭代周期内的架构稳定。频繁变动的信息架构必然会带来产品的研发成本提高，并且增加用户的学习成本。

2. 易学性

信息架构需要有一套准确的分类标准，能够指导后续架构的优化迭代，也可以便于用户理解和学习。细分下来包含了逻辑性和一致性两个方面。逻辑性则体现在信息之间的关联关系，实现用户链路的准确、高效。一致性体现在分类方式、分类结构等方面，便于用户认知。

3. 易用性

上文提到过，信息架构的的广度和深度在一定程度上决定了操作体验。设计时要做好信息架构的平衡性，避免只是从业务角度出发，出现十几个一级导航菜单并存的局面。

七、写在最后

信息架构是个复杂的系统，并不是设计师个人的工作，也不应该从零开始构建。而是在产品功能架构或者产品规格清单基础上，从用户需求和场景出发，梳理出来的符合用户体验逻辑的产品骨架。

信息架构直接决定了后续产品设计的组织脉络，因此准确有效的信息架构是产品战略落地过程中重要的一环。设计师需要拥有相关的知识和能力，才能在设计工作中产出合理的设计方案。

信息架构内容很多，文章是笔者个人的观点，难免存在不足之处，欢迎大家交流指正。

专栏作家

子牧先生。公众号：子牧UXD（HelloDesign），人人都是产品经理专栏作家。产品体验设计师。8年互联网行业经验，擅长体验设计思维、设计方法论、交互设计研究。

本文原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。

一、什么是系统架构设计?

定义：

一个软件随着功能越来越多，整个软件系统逐渐碎片化，如果不采取有效措施，软件系统就会越来越无序，最终无法维护和扩展。

所以说软件在一段时间的生长后，就需要及时干预，避免越来越无序，架构的本质就是对软件系统进行有序化重构，使软件系统不断进化。

扩展资料：

系统构架是对已确定的需求的技术实现构架、作好规划，运用成套、完整的工具，在规划的步骤下去完成任务。

抽象来说，它是计算机系统结构，或称计算机体系结构，是一个系统在其所处环境中最高层次的概念；它确定一台计算机硬件和软件之间的衔接。

具体地说计算机体系结构指的是计算机系统设计的观念与架构，描述计算机在实做的设计原则。

它确定一个计算机设计的部件功能 ，部件间接口 并且计算机体系结构着重于“负责了计算机架构的中心功能：计算”的中央处理器内部的运行动作与存储器的访问。

参考资料：

二、如何应用企业架构？

企业架构的兴起对于我们任何人来说都不感到意外，尽管日常的业务工作既没有部署企业架构，也不能有效地部署企业架构。据市场研究公司Gartner的分析师预测，由于执行不利，到2010年将有接近40%的现有的企业架构计划将停止。
实现企业架构对业务的影响 要保持我们并行的生产正常运行，把这个生产的产品想象为一架在空中飞过的飞机。生产这架飞机的过程需要一个详细的蓝图，这是组装线制造这架飞机的基础。采用信息技术，这个同样的原则适用于编写一个10K年度报告。对于那些在萨班斯法案时代经营上市公司的人们来说，这个年度报告要说明公司的年度活动。这个报告是数据仓库生产过程的产品。你的公司像组装一架飞机那样编写这个报告吗？或者像大多数公司一样仍然利用一系列表单文件和宏命令吗？拥有五名员工的财务办公室把它称作财务报告。对于像通用汽车公司或者3M那样的大公司来说，创建一个财务报告不过是使用一个简单的数据搜集命令。因此，这些企业建立了一些系统以便设计其信息系统帮助证明他们遵守了萨班斯法案。
架构不仅帮助创建合法的报告，而且还帮助企业调整其流程和系统的目标和战略。业务流程建模在80年代和90年代的兴起已经发展成为流程编排和现在的 SOA。这是一个成熟的周期，就像每一次组装一架飞机的一个部件一样。这个成熟的周期已经向企业证明IT能够在企业知识工人的生产过程中发挥作用。因此，由于SOA提供的这种成熟的松散耦合的服务，新的业务流程的实施正在迅速改善。
现在是企业整个企业认识到其所有的知识工人的成熟水平的时候了。这是企业架构的主要承诺之一。企业架构是让企业所有的方面都参与创建运行这个业务的架构的实现因素。
使用企业架构支持项目规划 一个好的架构群是非常有价值的。一个客户得到的业务目标是减少客户服务花在电话查询有关发货信息的时间。这个CRM流程意味着从四个不同的业务部门获得当前的状态。这四个业务部门每一个部门都有成熟的信息架构。因此，当执行团队要求得到有关客户的一致情况时，他们能够立即提供答案。
把这个应用程序架构在一个白板上描绘出来以观察这些部门有什么共性以便改变提取信息的过程可能需要两个多星期的时间进行分析。由于采用结构化的架构方法，信息团队用几个小时能够完成的任务应用团队就需要几个星期的时间。现在，这个流程已经变成了企业的一个通用客户知识库，应用团队要按照要求显示他们如何利用通讯图表与这个系统沟通的。这个通讯图表连接到他们在UML（统一建模语言）中的活动图表。
当一家新的小公司被收购并且作为一个分销网络的一部分的时候，必须要对这个小公司进行集成。由于要修改客户状况，这些团队知道如何评估架构以寻找这些差距，从而制定一个在几个星期内实施集成的计划，而不是用几个月的时间进行集成。这个结果是由于企业架构的方法用高水平的通讯图表把信息、应用程序和业务建模等方面的努力结合在一起。
风险管理和企业架构 在任何企业中，人们总是讨厌能够避免而没有避免的风险。这个基本原则能够以多种方式结合到项目管理中。但是，对于企业架构来说，有更多的直接的和具体的结果。
在过去的五年里，由于这种变化会给企业经营带来风险，一直有许多决定要求不要改变工作的系统。由于企业架构能够捕捉到系统中的所有的相关的通讯流，更准确地评估这些变化是很容易的。
企业架构是自然的发展 20年之后，信息系统经理将回顾我们现在的奋斗，并且不能完全理解我们为什么要在容忍具体风险的一段时间内完成这些项目。他们将拥有我们的劳动成果，就像汽车组装线的经理不理解为什么亨利·福特要一次生产一辆汽车那样。一旦企业接受这种需求更严格地构建其信息创建，管理信息创建的人就能够更好地采用企业架构避免重复以前那些人做的愚蠢的事情。

三、在高级产品经理眼里，产品架构是怎样的

一般来说，搭建产品架构这件事情，只有少数的高级PM才能胜任，绝大多数刚入门的产品经理或产品专员，还涉及不到任务这么艰巨的工作（简单的产品功能结构不算）。

经历过需求的采集、分析和筛选，我们对产品的定位和用户的需求有了越来越深刻的认识，对整个产品方向的把控和版本迭代节奏也会更有感觉。这种感觉你也可以称之为“产品感”，虽然讲得有点悬乎，可又的确存在。以我个人的经验来看，不断地了解用户需求和场景，也是积累产品感的一种良好的方式。有了不错的产品感，我们要继续往前走，才能将产品推向一个更高的高度。
产品经理之前已经将产品第一个版本的功能需求都整理好了，也输出了一份详细的功能需求列表，这个时候要做的工作就是为产品搭建一个好的架构，也就是产品设计的第三个环节——搭框架了。任何一款互联网产品都应该有一个产品架构，有了这个强大而坚实的架构作为产品的基础，我们才能将产品需求给一个一个填充进去，让产品变的丰富立体，更有血有肉起来。
那究竟什么是产品架构，产品经理又该如何来搭建一套好的产品架构，我们来接着往下看。
什么是产品架构
任何一个产品都有自己的产品架构（也有很多人把它称为信息架构），就好比每一个人都有自己的骨骼系统一样，你的骨架大小决定了你大致的身材会是如何，每个人的身材都不一样，高、矮、胖、瘦各有不同。
有些产品的产品架构比较繁杂，例如大部分to b 的产品，如客户关系管理系统、ERP软件、电商网站的管理后台、物流管理后台、SaaS软件等；有些架构则比较轻便、简单，比如绝大多数的to c 的产品，像我最近在玩的图友、摩拜单车、直播APP映客、花椒等，当然还包括微信（虽说现在功能越来越多了，但大体架构依然是简单、清晰明了的）。
我们直接看几个例子：

天猫商家工作后台
这是天猫商家的工作后台，看到左侧这一排满满的导航菜单了吗，是不是感觉超级复杂，光店铺管理就有超过10个二级菜单，要梳理好淘宝、天猫这种量级的电商平台产品架构可真不是一件简单的事。不过我也常常好奇一点，这么复杂的后台，卖家们都能清楚地知道每一个功能在哪里么。
复杂架构的产品，对产品经理的能力要求较高，需要产品经理能提供功能完备、结构严谨的架构系统，让用户能通过操作流程来使用各个功能。所以这样一个架构的特点是，它会带来一定的学习成本，有些甚至需要对产品的用户进行培训（像淘宝开设了淘宝大学以及淘宝社区）。这种架构产品的用户群体一般比较聚焦，只针对某一类人群，需要对海量功能进行合理整合、灵活布局来聚焦核心用户场景。

脸萌官网
再来看一个例子，这是曾经爆红一时的脸萌app的产品官网，仔细分析一下这个官网的产品架构，是不是超级简单，简单到只剩下2个菜单——首页、关于我们。这里要注意一点，即使是简单的2个菜单（有些官网只有一个菜单），也依然构成了完整的用户体验，因为通过这个架构，网站的目标和用户的需求都已经得到了充分的满足。当然，如果你想要重新定义网站的目标，或是用户的需求发生了变化，那你就该去准备重新调整产品架构了。
轻架构的产品，它的目标就是提供给用户一个简单明了的信息架构，让用户使用方便、体验流畅。对于产品经理来说，设计轻架构的产品，难点在于体验和创新。我们可以通过给产品做减法来不断聚焦用户的核心使用场景，让用户简单易上手，等产品的用户体量上升到一个新的台阶的时候，再去拓展产品的使用场景，延展产品架构。
典型的几个产品架构模型
Jesse James Garrett在《用户体验要素》这本书中，为我们系统阐述了互联网产品的几个典型的产品信息架构模型。第一种信息架构模型比较符合我们产品经理对产品架构的理解和定位，后面三种信息架构模型，你可以当作是第一种模型的补充，或者你也可以把它当作页面级别的信息架构梳理。
第一种，层级结构（hierarchical structure）

层级结构模型
书中原文是这么来描述这种产品架构的——“在层级结构中，节点与其他相关节点之间存在父级/子级的关系。子节点代表着更狭义的概念，从属于代表着更广义类别的父节点。不是每个节点都有子节点，但是每个节点都有一个父节点，一直往上直到整个结构的父节点。层级关系的概念对于用户来说非常容易理解，同时软件也是倾向于层级的工作方式，因此这种类型的结构是最常见的。”
这种伞状式的产品架构，恐怕是互联网、移动互联网产品中使用最多的一种信息结构，比如我们使用频度最高的微信、手q，以及各类to c 的移动APP，甚至是复杂的to b 类产品，都是使用这种产品架构进行产品设计。这种架构的特点是符合人类的认知习惯，因为人类天生就有分类的习惯，比如书桌，我们会习惯把书籍放在一起，把录音卡带等放到一边；又比如我们的衣柜，我们一半会将不同季节的衣服放在不同的位置。在生活中，整理物品是为了更容易地找到自己需要的东西。
下图是蜻蜓fm早期版本的一个层级信息架构：

蜻蜓fm的产品信息架构
在使用层级结构的时候，需要注意层级的深浅和宽窄这个问题。
大家都有过逛商场的经验，其实有时候做产品和逛商场很相似，有的商场设计的比较合理，很容易地能够让逛商场的用户找到想要的商品品类，有的商场设计却经常让你迷路，来来回回折腾好几次。在确定产品架构的时候，考虑产品架构的深度和广度成为了产品经理的一道必选题，就拿淘宝APP和唯品会APP来说，淘宝属于广而深的架构，唯品会则属于浅而窄的架构（相对）。在偏深度的架构中，用户操作起来效率不高，用户获取信息、完成目标任务的路径增多，但是相对而言，减少了用户选择的入口。在偏广度的架构中，用户面对的入口增多，在选择入口的时候比较费时，但是减少了用户的操作路径。

广度和深度的架构模式
宽而浅的产品架构和窄而深的产品架构，各有优势和劣势，具体使用哪一种产品架构，关键是要结合自身产品的定位、业务特性、发展阶段和用户特征及使用场景来进行取舍和判断。
第二种，自然结构（organic structures）

自然结构模型
原文描述如下——“自然结构不会遵循任何一致的模式。节点是逐一被连接起来的，同时这种结构没有太强烈的分类概念。自然结构对于探索一系列关系不明确或一直在演变的主题是很合适的。但是自然结构没有给用户提供一个清晰的指示，从而让用户能感觉他们在结构中的哪个部分。如果你想要鼓励自由探险的感觉，比如某些娱乐或教育网站，那自然结构可能会是个好的选择；但是，如果你的用户下次还需要依靠同样的路径，去找到同样的内容，那么这种结构就可能会把用户的经历变成一次挑战。”
事实上，这种形态的产品架构一般在to c 的游戏、娱乐、资讯产品里面运用的比较广泛，例如优酷视频、好奇心日报等。当然，很多时候自然结构是应该结合层级结构来进行思考的，比如用户进入好奇心日报这个网站，可能的一种使用方式是，用户心里已经有一个明确的资讯目标，想看一下最近商业有发什么大故事，所以用户会点击上方的“全部分类”，选择电影，选择商业板块然后进行浏览。也有另一种使用方式，就是毫无目标，直接就是这么从上到下浏览下去，看到自己感兴趣的文章标题便点击进去。

好奇心日报官网
自然结构很适合轻架构产品的浏览式形式，尤其比较适合to c 类的娱乐休闲类产品，因为这类产品的目标用户，绝大多数时候的使用场景都是无聊式地浏览，并没有明确的用户目标，也不需要解决什么特定的任务。
第三种，线性结构（sequential structures）
依旧来看下原文描述——“线性结构来自于你最熟悉的线下媒体。连贯的语言流程是最基本的信息结构类型，而且处理它的装置早已被深深地植入我们的大脑中了。书、文章、音像和录像全部都被设计成一种线性的体验。在互联网中线性结构经常被用于小规模的结构，例如单篇的文章或单个专题；大规模的线性结构则被用于限制那些需要呈现的内容顺序对于符合用户需求非常关键的应用程序，比如教学资料。”
说的直白一点，所谓线性结构，就是你用一个讲述故事的方式去给用户介绍你的产品，多见于产品专题页、帮助文档的设计。其实这部分也没什么可讲的，关键是讲述故事或者问题的时候，你的思路是否清晰，很多时候这部分工作也会由运营的同事替我们代劳。

金山快盘专题页
上图就是金山快盘做的一个活动专题页，通过线性结构讲故事的方式来将自己“100G空间永久免费”的活动宣传出去。
第四种，矩阵结构（matrix structure）

矩阵结构模型
书中是这么描述矩阵结构的：“矩阵结构允许用户在节点与节点之间沿着两个或更多的“维度”移动。由于每一个用户的需求都可以和矩阵中的一个“轴”联系在一起，因此矩阵结构通常能帮助那些“带着不同需求而来”的用户，使他们能在相同内容中寻找各自想要的东西。
举个例子来说，如果你的某些用户确实很想通过颜色来浏览产品，而其他人偏偏希望能通过产品的尺寸来浏览，那么矩阵结构就可以同时容纳这两种不同的用户。然而，如果你期望用户把这个当成主要的导航工具，那么超过三个维度的矩阵可能就会出现问题。在四个或更多维度的空间下，人脑基本上不可能很好地可视化这些移动。”
看了上面这段话，你的第一反应是不是想到了下面这个产品设计界面：

淘宝的宝贝详情页
矩阵式的信息结构，需要将多种信息内容放置在一个页面里，所以它的重点和难点是在于如何做好信息分层，让信息更加有效率地传达给自己的目标用户，这个问题我们放在后面来讲。
总体来说，产品经理了解这几个典型的产品信息架构模型，对于后期自己设计产品架构的时候，会更加明确应该朝哪个方向进行努力。这就好比一个建筑师在设计房屋之前，都需要先有足够的建筑设计知识，其中搭建建筑物的框架便是其中少不了的重要一课。
在具体的工作场景中，大多数产品经理从事的工作基本会分为两个大类，一类是C端产品经理，负责和普通用户打交道，更考验对用户痛点和兴奋点的把握和拿捏；另一类则是B端产品经理，负责和企业用户打交道，更考验对业务本质和行业战略的思考。那么，具体这两种类型的产品该如何来搭建产品架构呢？
To C 类的产品如何搭建产品架构
先简单介绍下业务背景：
2014年开始变热的O2O行业，已经迅速从表层变革进入深水区，很多O2O相关商业模式被验证错误或者迅速发展壮大，这个过程无数创业公司创立和倒下。除了商场、吃喝玩乐商户、线下服务商户等成为O2O热点之外，到家模式也成为一个新热点，美甲的、按摩的、泡脚的手艺人很多都变成了流动作业（典型如河狸家），如果说吃喝玩乐等希望辐射的是商圈流量，那到家服务无非希望搞定社区这块“富矿”。
15年初，当时我所在的公司正好也看中社区O2O这个行业（当然是老板有相关资源，又觉得市场前景广阔），而做社区O2O，有个绕不开的门槛——物业，如果有谁愿意费力气去啃物业这块儿硬骨头，就能有机会赢得未来。
于是我们就组建了一个小团队，先去做了一番市场调研，看一下市面上的这些社区O2O产品都做了哪些连接社区居民的服务，得出了这么一份竞品分析报告：

竞品分析报告
把玩了几十款APP后，我们发现只有少数几家公司的产品做了向业主提供在线支付物业费、停车费的服务，更别谈业主可以在线报修，呼叫安保等服务。
总的来说，当时的社区O2O还不算是一片红海，仍然有市场空间和机会进行切入。以产品的开发背景来说无非是两类APP，一类是“叮咚小区”“小区无忧”为代表的第三方创业公司，一类便是开发商自有的“住这儿”“彩之云”等移动端应用。
第一类像“叮咚小区”这种平台模式，没有用户基础，只靠烧投资人的钱来铺地面工作，当时来看是圈了不少小区，但是由于没有根基，用户随时会被抢走，想要做到成规模的应用不知道要烧多少年。目前传闻好像已经倒闭了，估计资本的钱也烧的差不多了吧。
第二类应用大都停留在试水阶段，扮演配合物业的角色，还没找到完整的盈利模式。“彩之云”可以算得上其中的优秀代表了，其垂直电商模式或许可以成为一个突破口，同阿里争夺“最后一公里”。
而当时的BAT等巨头还都持观望态度，没有太大动作，又或者是等待哪一家创业公司做起来之后再进行投资收购。很明显，大家都把这块难啃的骨头放在了一边。
由于当时公司在房地产物业这块有相关资源，所以，我们团队将产品的切入点定位在了物业公司，物业服务站和物业从业人员这里。而后，通过相关小区的试点，验证产品可行性后，再将产品的使用场景拓展到进行车位信息化管理、社区商户平台——商户通过物业平台入驻小区并投放广告、为成熟的业委会提供在线管理平台、社区教育等等。当时，产品的名字暂时就命名为“乐业安居”，正有让社区的老百姓拥有了我们的产品，就能安居乐业的意思。
经过一系列的产品设计准备工作，就要开始搭建APP的产品架构了。结合之前的市场调研及产品路径规划，以及团队对O2O的理解，梳理了一下我对社区O2O产品架构的规划思考，主要由4个tab组成：
社区：负责连接人与人，这个部分可以满足邻里之间人与人的交流沟通，你既可以在这里发布相关信息寻求帮助或需求交换，也可以在这里找到志趣相投的邻居一起去做一件事情。包括后期的业委会、居委会等等，都可以在这里展示相关信息。
物业：负责连接人与物业，这个部分就是通过移动互联网来改善业主和物业的连接效率，让物业的服务成本降低，效率提高，也提升业主的用户满意度。
周边：负责连接人与O2O服务，这个部分就是第三方O2O（如家政服务、维修服务、养老服务、社区教育等）、电商团购的综合展示舞台，通过整合资源可实现有自己特色的O2O社区服务。
我的：负责管理与”业主“有关的所有信息，如”我的报修“、”我的缴费“、若后面产品拓展做了社区教育，则还可能有”我的课程“等等。

社区o2o的产品架构
当然，第一个产品版本的开发，打算就先做2个部分——”物业“和”我的“，既然是从物业作为切入点，就先把这个点做好，后期在相关小区试点可行后，立即迭代产品，再引入其他功能让产品的使用场景变得更加丰富起来。
如果你仔细分析，应该可以看出这里面的框架逻辑——连接。
这里就涉及到对O2O最本质的理解，它的本质是什么？O2O本质其实就是用互联网去改善消费者和服务提供者的连接，让他们之间的连接变得效率更高、成本更低。所以整个产品架构都是围绕着连接去做的功课，连接人与人，人与物业服务、人与其他服务，这样对于用户来说，他们对你产品的认知逻辑就会非常清晰，每一次打开产品的时候，都能够轻松地找到自己想要的东西。
就这个案例，我们尝试着来做一点总结：
1. 做好分类
前面我们就已经说过一点，人类天生就有分类整理的习惯，有这个习惯也是为了更方便地找到自己所需要的东西。超市里的商品摆放也是如此，所有的商品需要按照不同的分类，摆放在不同的货架上，并且上面还要贴上相应的指示牌，告诉用户这是什么商品区域。
我们常用的Windows 资源管理器也是一个极佳的例子，试想一下：如果我们将自己电脑上的所有文档都归存在一个盘里，而且这个盘并没有文件夹的形式让你分类管理你的文件，word文档、excle文档、ppt文档、pdf文档、视频文件、图片格式文件等都混杂在一起，那你想要找到自己需要的文档也则太难了。幸好在Windows 资源管理器模式下，我们可以创建文件夹，并且可以按照文件的名称、修改日期、类型、大小等进行排序和分组，这样才方便了我们更加快捷地找到自己所需的信息和文档。
同理，网站或者移动APP应用也是如此，信息越多，就越需要组织和整理。我们可以根据逻辑习惯来对信息进行分类整理，如上面所举的例子，就是根据社区O2O“连接”的逻辑进行分类的；当然，也可以直接去探究用户的想法，了解用户的使用习惯。一个好的产品经理，往往也是这个行业的资深人士，或者称为行业专家。因为只有产品经理自己本身对所处行业有极深的理解，他才能更准确地命中产品架构的脉门，有时候甚至是一击而中。
2. 平衡用户与商业
对产品架构的设计，一方面是要了解用户的信息需求，另一方面也要了解整个产品的商业目的和诉求。一般情况下，用户目标和商业目标之间肯定存在着矛盾，比如用户都不想看广告，但企业又希望能够把自己的业务和广告推荐给用户（典型如微信的朋友圈广告）。如果一个产品只满足用户的目标，产品体验当然会不错，但这个产品也很难走的长远，毕竟企业的终极目标是要盈利的。
这个时候，如何平衡用户与商业，就成为考量产品经理的功底的重要一环了。在这方面，我们向微信团队进行学习，微信在平衡用户体验和商业目标这一块做的非常好。还记得2015年1月份的朋友圈广告么，当时一经推出，便立刻成为了朋友圈的热门话题，大家都争相在广告底部进行点赞和评论，仿佛品牌一下子就成为了我们身边的朋友一样，在朋友圈直接与我们分享故事和内容。而在社区O2O这个案例中，我们也将周边这种带有业务、广告性质的功能，放在了后面的版本进行迭代开发，并没有立即尝试进行产品的商业化，这也是一种平衡的体现。

微信广告
3. 重要的功能设置快捷入口
产品架构应该是结构清晰、合乎逻辑的，让有明确目标的用户能够快速找到所需信息；有不确定目标的用户，通过浏览和寻找，一点点地明确自己需要的信息；没有目标的用户，则可以在探索中激发需求。所以，对于后两者用户来说，如果重要功能和常用功能隐藏地太深，则很有可能会让他们对产品丧失兴趣。
为重要功能和常用功能设置快捷入口，就好比在原有的产品架构上搭了一个“快捷通道”，典型如微信将“购物”放在了“发现”这个菜单里，手Q的“购物”入口改成了“京东购物”，京东和腾讯的“联姻”，由微信和手机QQ社交应用入口、朋友圈、朋友群、公众号、广点通，以及线下推广共同组成了多场景的京东社交购物生态，汇聚了庞大的社群流量，为京东带来了不少的新用户和成交增长。
当然，快捷入口的设置也是一个需要权衡的过程。必要的快捷入口可以提高用户的使用效率，也能满足产品一定的商业目标，但是如果快捷入口过多（尤其是参杂太多商业目标的快捷入口），产品也会变得混乱和复杂，这个时候就会让用户的使用效率下降，有点得不偿失了。所以你会看到，微信这款产品，并没有把所有的业务都通过快捷入口的方式展现出来，而是通过在“我－－钱包”里面，展示其他的第三方服务。这么一来，这些功能隐藏地如此之深，产品的用户就不会觉得微信是一款复杂而混乱的产品了。

京东微信手机QQ购物两周年庆典
当然，在业余时间我们自己把玩产品的时候，也可以试着去解构一下其他公司的APP产品，看下他们的产品架构是如何搭建的，又有什么地方是值得学习和借鉴的，这也是一个非常重要的学习手段。
说一下我常用的方法，分三步来走：
拆解产品骨架，将所有模块和功能点画成思维导图
分析重点功能的使用场景与流程
分析次要功能的使用场景与流程
当然，分析产品的时候需要考虑很多因素，不仅是从产品设计出发，还要从行业背景、公司战略、运营、实际资源等情况出发，才能得出更接近真相的答案。
To B 类产品如何搭建产品架构
To B类产品（通常都是后台产品）的设计非常具有挑战性，因为To C类的前台产品，大家都已经培养起了使用习惯，对功能有一定程度的理解，见过的模式足够多，能够建立起一定的产品模型，也容易找到参照物去模仿。但是To B类的后台产品，你几乎没有什么竞品可以参照和模仿，所以在搭建产品架构的时候则要求产品经理非常懂业务，非常考验PM的核心竞争力——业务知识储备、结构化思维和系统性抽象能力。不同行业的产品可能做整体架构的思路也不一样。
稍微简单类比一下，产品架构复杂程度的感觉由弱到强是这样的——
设计或者操控以下交通工具：
自行车
汽车
飞机
火箭
宇宙飞船
……
是不是感觉到难度越来越大了，不过我们也算是了解了复杂产品的架构是怎么样的了，其实依然还是有对应的方法去进行设计的。在对后台产品搭建产品架构的时候，往往有两种思路可供参考：
1.按功能模块来进行划分
什么叫按功能模块来进行划分？如下图：

按功能模块来划分
如果一个后台产品的目标用户比较单一，且用户需求也比较统一，并没有出现说某个用户只需要使用其中某一个功能模块的时候，且功能和功能之间并没有太多的逻辑关系，往往可以尝试使用按功能模块来进行划分的方式。比如百度移动统计，它的目标用户就是互联网公司内部的运营人员、产品人员，且运营和产品关注的数据绝大部分是可以通用的，也就是说用户需求还是比较统一的。
2.按业务逻辑来进行划分
另一个划分逻辑，是按业务逻辑来进行划分。很多公司内部的信息管理系统，都是采用这种产品架构来进行设计的，因为这个产品的目标用户往往涉及到多方角色，既有公司的业务人员，如市场、销售、客服、前台等，又有公司的职能部门人员，如人事、财务、行政等。这个时候再采用功能模块来进行后台的产品架构梳理，则显得不是那么适用了。
按业务逻辑来进行划分，则要求产品经理在规划系统时要思考这个系统的作用到底是解决了什么问题，再具体一点就是——解决了哪些用户的哪些问题。在这个大的环境下确定了之后，在需求的收集和分析的阶段，就应该按照业务角色来进行相关的工作，而后到了梳理产品架构这一步才能更得心应手一些。如下图所示，一个研发管理的子系统，就对应了这么多不同角色人员的不同需求。

按业务逻辑来划分
那么，产品经理在做to b产品的时候，进行业务规划和产品架构之前需要储备哪些方面的能力呢？
需要有一定的技术理解能力，帮助自己理解清楚信息在不同的系统之间是怎样交换、存储、耦合和解耦的。
要有基本的商业逻辑思维，比如节省成本、提高营收、提升效率等。
业务的整合需要对所在行业及业务本身有深刻的理解，同时对公司整体的运行逻辑也要有一定的认识，如销售、市场、财务、运营、产品、技术等。
需要有更强的抽象能力。不仅是把一个工作流程抽象成一个功能，而是要把一个业务抽象成一个系统，并且知道这个系统在产品中所处的位置；不是理清任务与任务之间的关系，而是要清楚业务与业务之间的关系，这样的关系最后是如何交织和演化在一起，共同促进产品繁荣的。
最后，这里提供几个优秀的后台产品供大家参考和研习：
淘宝的商家后台
有赞微商城的后台
微信公众平台后台
总结来说，产品架构这件事情涉及的面非常广，上至产品的宏观计划，下至产品的功能模块，囊括产品的目标及愿景、用户需求、商业需求、数据业务流程和设计框架，还涉及到产品的生态结构，所以要搭建好一套产品框架并不是件易事。产品经理在这条道路的学习上，也要做好一个漫长的认知迭代准备。
好的产品架构具有怎样的特性
好的产品架构对于一个产品来说是非常重要的一件事情，就如同人的骨架之于人，房屋的框架之于房屋，是起到支撑、引导、承重的作用。说回到互联网产品，好的产品架构要具备的几个特征，总结起来大致是这么几个点：易用性、稳定性、可扩展性。
什么是易用性呢？人的天性是懒惰的，试想如果用户在一次简单的使用产品后能记住每一个操作，而且能重复使用，不用刻意学习具体的操作，使用起来一定是很“爽”的。对于产品经理来说，我们必须竭力让用户能够方便地使用产品，这就需要产品架构上能够提供一个清晰的路径导航，让用户不会产生迷路等不爽的用户行为了。
什么是稳定性呢？这部分又通常和后台的技术架构有所关联，当产品不断演进和迭代的时候，系统的架构是否能够承受那么多用户的同时访问，在性能和响应速度方面有没有什么影响。所谓的稳定性原则，就是说你提供的服务一定是稳定可靠的，是能及时响应需求的，尽量避免类似APP上突然有提示失败、服务器异常、空等情况。
易用性和稳定性，就不再多用文字解释了，我们来看看产品架构的可扩展性。
可扩展性其实是在传达一个信息，就是要求产品经理在设计产品架构的时候，就要去多思考未来这个产品是否会新增加功能或者内容，也就要求产品经理要有产品规划的意识。如果一个新做的产品刚上线没多久，因为要新增功能，导致页面的信息架构重新调整，相关人员怨声载道，产品的使用用户也会增加对产品的认知成本。可见，产品架构的可扩展性是有多重要，产品经理需要根据实际情况及未来可预见的规划进行构思，争取将产品的维护成本降到最低。