点这里👇星标关注，获取最新资讯！
原型只是表象，过早的进入业务细节，很容易偏离方向而浪费时间。对产品经理而言，持续对用户、业务和商业模式的深刻洞察，特别从商业层面去梳理业务架构，是产品经理的高阶能力。
在画原型之前，功能设计是一个很关键的步骤。在这个步骤中，需要对功能进行拆解，梳理其逻辑和流程，梳理功能架构和产品逻辑。这其中，除了常用的流程图之外，各种架构图也是各位产品经理需要经常绘制的图表之一。这篇文章分享了三种架构图，包括功能架构图、信息架构图、产品架构图的绘制方法。
一、功能架构图
1、什么是业务架构
实际上，当一个简单产品诞生时，它的业务、产品都相对简单，比如：某些工具类的产品，在做产品规划时，往往就不再单独考虑“业务架构”了。
还有一种情况是：产品经理主动不去考虑“业务架构”，而是直奔主题，动手画“产品原型”。
关于业务架构，简单的说就是，“企业希望从这个产品身上得到什么”，以及“用户想从产品身上得到什么”，比如：电商平台这种战略性目标是显而易见的，用户买到想要的东西，企业卖出可以赚钱的商品。
为了实现这一目标，我们还必须弄清楚那些用户，能够通过什么渠道达成他们的目标，甚至还可能会有其他的目标。
也就意味着产品端必须清晰的规划出一个完整的业务互动的过程，搞清楚一个产品涉及到的各种不同的角色，他们所期望的目标，以及他们的需要完成的业务动作，从而为产品设计打下基础。
客户的期望才是产品的真正价值。如何实现客户的期望则是产品经理的价值。
比如：音乐类产品的业务大致包括了内容版权的生产、管理、消费，涉及到的就是用户如何消费内容，版权方如何产生内容，以及平台方如何基于内容进行的运营等。
这个过程用一个图的表达，可以是这样的：
音乐平台的业务架构模型
这种构建的方式，就是“以什么业务作为驱动”的设计方法，它考虑的是整个业务之间的互相协作来达成整体业务发展的问题。换言之，“业务架构”考虑的是：如何为用户提供价值，以及企业可以通过什么方式来实现盈利的问题。强调的是：我们能为用户提供什么？为了实现这一目标，我们需要做什么？
通过整个业务的架构，我们能够清晰的厘清整个平台的用户对象、业务关系，也就确定了整个产品的业务边界范围，确定了整个团队内的业务语言。所有的产品功能都基于两端（用户端和服务端）的业务价值来展开，从而避免了很多不必要的系统开支和过度设计。
2、功能架构图
功能架构图在百度中的定义是：功能架构图就是按照功能的从属关系画成的图表，在该图表中的每一个框都称为一个功能模块。功能模块可以根据具体情况分得大一点或小一点，分解的最小功能模块可以是一个程序中的每个处理过程，而较大的功能模块则可能是完成某一个任务的一组程序。
用通俗的话来说，功能架构图就是以功能模块为类别，介绍模块下其各功能组成的图表。功能架构图一般不涉及具体的字段信息，只强调功能的逻辑关系。
产品概念设计的运用工具之一。在绘制的过程中，能够帮助产品经理思考并清晰产品的功能模块及其功能组成。
梳理需求。以鸟瞰的方式对整个产品的功能架构形成一个直观的认识，防止在业务需求转化为功能需求的过程中出现功能模块和功能点缺失的现象。
绘制功能架构图最重要的前提是对业务的深入理解，只有对业务有了足够清晰的认识，才有可能绘制出合适的功能架构图。
有人说，功能架构图主要就看都有哪些Tab，由此逐步深入展开，最终整理形成功能架构图。
还有人进一步补充说，当一个次级功能模块反复出现在不同的Tab功能模块中的时候，我们就可以考虑将其拆分出来作为主功能模块。
但实际上，无论是我们要着手一个新产品/新功能的相关工作，还是对竞品产品/功能进行拆解分析，首先要明白一点：功能架构图是产品经理开启上帝视角站在业务角度鸟瞰产品功能体系的机会。
这里需要重点关注的是“业务角度”。
产品/功能，均是从业务中来，是实现业务逻辑/商业规则的介质。作为体现这一介质的全局性文档，绘制功能架构图当然是站在业务角度来进行梳理，而不是站在产品角度，所以上面提到的功能架构图主要看Tab等说法都是不恰当的，方向反了，或者说因果反了。
鸟瞰，是对基于业务而得来的功能体系的鸟瞰，不是对产品体系的鸟瞰。在这一点上，我们常常不经意地犯错。
当拿到一项新产品/新功能的产品工作时，不是从梳理业务开始，而是常常一上来就开始分Tab。这样做轻则导致返回来修改工作量增大延误时间，重则带偏了产品方向使产品找不到目标用户。
对于新产品/新功能相关的工作，我们尚且如此，而对于竞品的拆解/已有产品的整理而需要绘制功能架构图时，就更加容易从已有的产品出发了。
实际上，对于竞品拆解/已有产品整理，我们可以从已有产品出发去了解产品，按照产品架构梳理产品功能去理解业务，而最终还是要在全面掌握了业务逻辑/商业规则以后再重新站在业务角度来梳理出功能架构图。
功能架构图的绘制是产品经理的思维由发散趋向于收敛的过程，刚开始的颗粒度一般比较大，可能仅涉及到某个功能模块，随着工作的不断推进，功能架构图的颗粒度会不断细化，最终可以拆分至某个具体的功能操作。层级上最好控制在3级以内，再细分下去的意义不大，功能架构图的主要目的还是从整体上描绘出整个功能体系。
二、信息架构图
1、什么是信息架构
很多时候，产品经理拿到一个“业务需求”，就不自觉的启动类似axure的工具，开始在画布上指点江山，构建产品原型。
这其实是一种对产品的误解，也是一种不太高效的工作方式。
我们太容易从内容的呈现的角度去思考解决方案了（人类的思考惰性是更倾向于直接得到某种结果），而原型确实能够快速的看清楚产品的功能模块、页面布局和交互逻辑等元素。
这种误解，让我们惯性般只顾产品的外观体现，而忽略内在的构建逻辑，最终的结果就是产品的健壮性，扩展性不够，用户体验欠佳。
这个内在的构建逻辑就是：信息架构，它决定这个界面需要呈现什么内容，以及呈现的方式，明确的表达这个界面所需要解决的问题，也就是业务痛点。
信息架构最直接的例子就是商城了。
商城导视图
从地下的停车场，到各个不同品类的楼层，然后各个楼层通过电梯、走道进行连接，让有不同需求的顾客分流在不同的楼层。每个人都可以找到一个路径去到自己想去的地方，这个就是商城的信息架构。
对产品而言（是一个商城本质上也可以被看成是一个产品），是同一个道理，在同一个界面上，如何按照一定规则对产品的信息和内容进行组织变成极为关键，包括每一个功能按钮的位置都变成极为重要。因为它决定了用户在使用产品时的行进路线是否顺畅（体验是否良好）。
也就是在画原型之前，首先要对用户的行进路线做一个规划，让用户在任何一个页面都找到他想要的信息，能够通过最合适的路径去到下一个想去的页面。思考的重点是在功能架构被确定的情况下，如果摆放按钮，设置跳转连接，才能高效的满足用户的使用需求。
这就像一个超市，怎么设计一条合适的路线，让用户能够逛到你想TA逛到的地方，买到TA想买的东西。如果没有合理的信息架构，整个超市就一定会变成杂乱无章。
信息架构考虑的是如何高效的解决用户的问题，也就是如何提升用户的体验问题。
要注意的是在信息架构层，业务架构和产品架构都是黑盒不可见状态，也就是业务价格和产品功能架构都已经被确定，你可以尽最大的能力装修房子，而不是拆除房子的承重墙，不可以撬掉天花板，也不能动地基。
2、信息架构图
每个人在撰写简历时，其实就是把个人相关的信息整理成结构化信息的过程。
每个人的简历上大致会包含姓名、性别、民族、籍贯、出生年月、身份证号码、联系方式、工作单位、工作时间、职位、收入情况、离职原因、毕业院校、学习时间、所学专业、获得证书等信息。
这么多信息，如果一一就这样罗列在这里，会显得非常繁杂。但我们可以将其梳理成以下分组，看起来就会轻松很多：
基本信息（姓名、性别、民族、籍贯、出生年月、身份证号码、联系方式）；
工作经历（工作单位、工作时间、职位、收入情况、离职原因）；
教育经历（毕业院校、学习时间、所学专业、获得证书）。
将信息进行结构化梳理后，会更清晰、更有条理。
而且我们可以从中发现，以上信息是对“一个人”这个对象的结构化信息描述。
信息架构图就是将业务中的对象按照如上的方式梳理而成的结构化信息图谱：
在绘制信息架构图时我们需要注意：信息架构图和页面以及交互是没有关系的。
三、产品架构图
产品架构图示例
（ps：此文为简化版，后续再另文再详细阐述如何构建整个产品架构。）
这个图，我们能从上往下看用户发起请求后的一系列动作过程，也可以从下往上看，为了支撑用户的服务请求所需要构建的一系列服务。
从上图可以也可以得出一个结论：产品架构可以指导产品经理思考如何解决用户的问题，如何满足用户的期望。
作为产品的指南，“产品架构”解决的是如下三个问题：
1）产品方向
按照产品架构图的架构和路径，产品的RoadMap也就可以被清晰的拆解出来，同时它还能指导技术架构的选型，比如：业务的容量，扩展性等等，为未来的产品发展指明了方向。
2）产品边界
不做什么，很多时候更为重要，明确一个产品的基本边界，可以让这个产品少走很多弯路，降低很多的风险和不必要的成本。这对于创业团队来说，有些时候非常关键。
3）产品路径
产品架构设计了各个功能模块的业务范围，针对每个功能的内外关系有清晰完整的定义。当一个产品的架构被确定后，也就确定了产品的迭代周内的范围，并且能够帮助上下游清晰的理解产品的架构、功能和复杂度。
从其解决的问题来看，我们也能很清晰的了解，一个好的产品架构图的基本要求：
功能经过抽象，做到标准化、互相独立清晰的功能边界，架构分层明确
具备迭代优化的能力
2、产品架构图
在开始说产品架构图之前我们必须要清醒地认识到一点：前面的所有内容都还没有涉及到产品设计，也就是说还都是站在业务角度进行的一系列工作，这时连产品的影子都还没见到呢。从产品架构图开始，才会开始产品经理的产品设计之旅。
产品架构图是综合展示产品信息和功能逻辑的图表，是将功能和信息进行有机结合，按照一定层次和逻辑关系形成的产品雏形。
之所以说是雏形，也是因为这时还不能看清全部细节。
简单说，产品架构图就是产品原型的简化表达。
产品架构图是将功能和信息以一种合理自然的逻辑，把功能架构图和信息架构图中的内容放入产品中的每一个页面的结果，是产品概念化设计的结尾阶段的产物。
有人认为产品架构图就是在功能架构图基础上将信息架构图中的信息添加进去，认为产品架构图=功能架构图+信息架构图。
本人不赞同这种说法。
既然作为产品原型的简化表达，那么必然已经经过了产品设计，而功能架构图和信息架构图都还是在业务层面，简单的叠加并不能直接产生产品架构图。
实际上，产品架构图是产品经理从业务层面落地到产品层面的一个重要过程。经过这个过程后，可以看到产品的主要页面架构和基础信息，能看出产品的基本轮廓。
既然后续还需要做产品原型，并且看起来产品原型必不可少，那么产品架构图的作用是什么呢？
产品架构图在前期的需求评审中或其他类似场景中可以作为产品原型的替代——因为产品架构图相较于产品原型，其实现成本低，能够快速对产品功能架构进行增、删、改操作，减少产品经理在这个过程中的实现成本；同时可指导产品原型制作，以产品架构图作为绘制产品原型的依据，可以避免我们在产品设计中边画边改，跳进只见细节不见森林的陷阱。
除此之外，产品架构图也是产品和研发沟通的桥梁，便于研发初期评估开发计划。
现在小结一下：
很多产品经理都说，这3个都是架构图，容易混淆，怎么能够更加容易区分、加深理解呢？
功能架构图，关键词是功能，是功能的结构化表达；
信息架构图，关键词是信息，是信息的结构化表达；
产品架构图，关键词是产品，是产品的结构化表达。
四、架构，是一种递进的能力
信息架构、产品架构与业务架构的关系，可以认为是一种递进的思考方式：
信息架构：是最前端的表现层架构，也就是给最终用户呈现的内容；产品架构：连接业务和用户表现层的产品功能的架构，解决的是如何实现用户的价值问题（解决具体的问题）；
业务架构：包含商业逻辑在内的业务运转机制的架构，解决的是产品边界的问题，最终的目的是阐述整个产品商业模式。以上分析可以得到一个结论，形象一些来说，业务架构是心脏，产品架构是骨架，信息架构是肌理脉络，最外面呈现的UI，只是皮肤了。
这个结论给我们的实际指导意义是：“别再把自己当原型仔，画原型是最容易的一件事”。《用户体验五要素》一书中，详细阐述了这3层架构在使用产品开发中的应用（有兴趣的朋友可以再读一读这本书）。
业务架构、产品架构和信息架构，既可以从上往下看，也可以从下往上看，都能够推导出最终呈现再用户面去的产品形态，只是取决于设计者如何结合实际应用采用的方式。
如果反过来看，其实是从业务架构一步步推导出最后的信息架构，从而以前端的表现层呈现在用户面前。
对三种架构的思考是我们把事情做对的重要方法，作为产品经理，持续对用户、业务和商业模式的深刻洞察，特别从商业层面去梳理业务架构，是产品经理的高阶能力。
END
