产品业务逻辑图怎么画

㈠ 如何画好一个产品的逻辑图

逻辑要弄清楚！为什么我这么强调逻辑，因为如果你的逻辑跑不通，最后出来的东西会陷入死循环，这对于使用产品的用户来说是致命的！你的每个功能的逻辑要跑得通，三个字跑得通看似简单，实际你需要花一定量的时间去跑逻辑，当然了，并不是说你花的时间越多越好，如果逻辑比较复杂，花的时间越多越可能把自己搞晕。有精力的朋友可以去梳理以下淘宝的订单逻辑流程图。跳出订单页面的可以不用理会哈。聪明的产品一看这个图就明白如何画，而且还会在我这个基础上更加完善更加美观。

㈡ 一张图讲清楚产品架构，手把手教你画产品框架图

什么是产品架构图

产品架构图是产品经理用来表达自己产品设计机制的一张概念图：

它将可视化的具象产品功能，抽象成信息化、模块化、层次清晰的架构，并通过不同分层的交互关系、功能模块的组合、数据和信息的流转，来传递产品的业务流程、商业模式和设计思路。

由于产品架构图通常用于比较复杂的产品项目中，目前介绍产品架构图的相关书籍和资料极少（尤其是入门级别的资料很少提及），却是设计复杂产品时不可或缺的文档之一。

没有资料的探索过程漫长且没有方向，在终于有所沉淀后，我花了四周写下了这篇总结，希望可以为你绘制产品框架图时提供简明的参考。

为什么要画

梳理自己对产品方向的判断：

思考这张图如何设计的过程，也是帮助你梳理“半年内自己的产品该往何处去、需求应该如何分期和落地、和其他产品的依赖&竞争关系是什么、未来的可拓展性在哪里”等问题的过程。

为技术&运营的输出形成支撑：

当这张图被设计出来后，按照产品架构图的结构和路径，项目的里程碑（RoadMap）就可以被清晰的拆解出来，同时项目成员也可以根据这张架构图产出运营计划、技术系统架构方案等强依赖产品方向的方案。

让他人可视化的理解你的产品架构：

能较为清晰简单的呈现自己的思路、明确自己的产品边界、指明发展的方向，常用于在项目规划或项目总结中进行演示，帮助不了解你的产品的人快速的建立对你的产品结构、功能、复杂度的认知。

何时需要画

建议在复杂项目开始前写：

当你要开始设计一个系统性、完整的需求时，如果跳过画产品架构图的步骤，直接开始画原型、写PRD、kick off，就很容易发生“改了又改”、“做了一版需求然后又推翻”的情况。

但“种一棵树最好的时间是十年前，其次是现在”：

如果你的项目已经进行到一半，自己却从未产出过这张图，那么就从此刻开始，按照下文的步骤尝试为自己的产品产出一张产品架构图吧。

如何画

之前我们分享了【AR最全干货及资料】设计AR产品，你一定要看的总结 ，你可能对AR相关的背景知识已经有所了解。为了分享的延续性，我们来做一个大胆的假设*：

假设你是 微信-扫码功能 的产品经理，有一天老板把你叫到办公室，一番鼓励后拍着你的肩对你说：

“苹果发布会看了没？苹果这么重视对AR能力的支持，我们微信也要赶紧把AR功能做起来。这是个Allen（张小龙）很重视的项目，你回去好好设计一下，明天来跟我过方案。记住，要能够一炮打响，全民参与喔！”

啊，张小龙级别的项目啊！明天就要出方案，怎么办 ？

画前准备

列出问题域

在需求初期，产品经理得到的往往只是一句比较模糊的需求描述，它们可能来自于老板、运营或用户。

直接把这句话作为核心产品功能是不恰当的，合理的做法是先把这个产品所有的问题域列清楚。

“问题域”是指自己的产品能够解决的所有问题的空间集合。从核心需求出发，将所有当前需要解决、未来可能要解决的问题放入产品框架的范围，能够帮助你的产品架构图拥有更高的可拓展性，在后续具备迭代和优化的空间。

以微信AR的需求为例，问题域是这样一个集合：

详细操作步骤：

1. 找到收到的需求中，跟产品形态、产品目标相关的词句，去列出“XX的流程会是什么样”、“XX该怎么达成”之类的问题，直到如果这些问题解决，能够实现核心需求的方向和业务目标。

2. 去逐次寻找这些问题需求被解决的过程中，是否有其他要先解决掉的问题、或者其他跟业务相关的问题能够被解决/改善。

3. 按照层级去罗列出所有的问题，并附上自己的初步回答，从而形成一个初步的、自己的产品能够解决的“问题域”。

确定产品方向

在经过问题域的罗列后，你应该能够得到一个模糊的产品方向和功能范围。把这些问题域的答案抽象总结成一个确定的产品需求。

以微信AR的需求为例，根据问题域，我们发现需求不只是扫码组件增加AR识别能力这么简单，整个需求里需要引入广告主的角色，并且需要和广点通、腾讯开放平台等团队合作。最终得到的产品方向描述是这样的:

详细操作步骤：

问题域的环节非常发散，这一步需要回归基础，把模糊的需求补充、拓展和翻译成一个在商业模式和用户体验上能够形成闭环的产品需求。

1. 核心需求确定：我的产品核心解决的是哪批用户、哪个用户需求？

2. 产品目标：如果以一个数字指标衡量我的产品，它应该是什么？

3.用户场景：核心需求基本的产品形态、用户使用的路径是怎样的？

清晰的业务流程

这一步需要根据核心产品需求和问题域的答案，画出简单的业务流程。业务流程是产品设计中常见的图表，绘制方法就不再多做说明。

以微信AR的需求为例，从广告主准备AR互动，到用户在前台使用摄像头参与互动，整个业务流程如下:

着手绘制

搭建基础框架

基础的产品框架脱胎于业务流程，但相比业务流程，更加注重产品功能的枚举、功能模块之间的分界。

详细操作步骤：

1. 对照业务流程，根据自己设想的产品机制、基本产品形态和用户的使用路径，列出需要的页面&功能&模块等前后端逻辑。

2. 将刚刚得到的多个流程图中所有功能类似或者范围有包含关系的机制/功能放在一起，以模块化的形式形成一张简单的矩阵图。

3. 将明显是同一个产品范围、同一组产品功能的模块放在同一层级，得到一个基础的产品框架。

明确架构分层

一个具备前后台关系的产品架构图至少分为三层：用户感知层（在何种场景下通过何种方式触达用户）、功能模块层（通过哪些功能模块实现产品的核心功能、和哪些外部平台功能有信息交互）、数据层（产品的数据从哪里来、产品的数据沉淀到何处去）。

在上一步进行简单分层后，我们已经得到一个初步框架，但是难免会有分层不明确的问题。此时需要按照两种维度来处理架构图的层级：不同信息层级的边界、同一层级内模块和模块的边界。

1. 处理不同信息层级的边界：

架构图的层级表达的其实是信息之间的流转关系，不同信息层级之间一定是有逻辑关系的。

其中用户感知层和数据层通常可以简化为一层（用户端的功能表达往往逻辑简单、数据的来源问题则不是自己产品的核心功能），而功能模块层则需要按照自己产品的逻辑去将功能模块层内的主要模块变成新的层级。

2. 处理同一层级内子模块的边界：

各层次之间虽然相关，但同一层次内的子模块之间一定是互相独立、界限分明的（常常对应着不同的开发团队和系统应用）。将解决不同问题的功能拆分成两个子模块，做到一个问题只在同一层解决，避免牵一发而动全身的情况出现。

3. 明确产品间的边界：

产品边界对于开发设计系统架构、业务间的合作模式都非常重要。用不同颜色标识清楚产品框架中，各个部分所属产品的边界，通常其中属于自己团队的部分用亮色表示。

加入信息流转机制

产品架构图在表达产品的核心功能外，也应该体现信息流动的路径：当前层级数据的交互形成产品功能，产品功能又产生新的数据，从而推动下一层级的功能运转起来。

如果当前产品的主要使用角色只有一个，则只需要用箭头标明模块间信息流动的方式即可。如果当前产品会涉及的主要角色比较多，则需要用不同颜色的线条将他们和各个模块之间的信息交互关系外化出来。

最终检查

一张好的产品架构图，应该具备以下特点。

清晰的模块功能边界

功能经过抽象，做到标准化、互相独立

上下游产品功能边界清晰，架构分层明确合理

具备迭代优化的能力

记得不断根据你的产品的发展情况来更新产品架构图，每次修改的过程对提升产品架构能力的帮助非常巨大。

————————————————

原文地址：https://blog.csdn.net/pmcaff2008/article/details/78111282

㈢ 产品架构图的定义和基本画法

本小节主要介绍 产品架构图 的相关知识，整个内容框架分为三个部分，分别是： 产品架构图是什么（what） ； 为什么要画产品架构图 （why） ； 如何画产品架构图（how） ，下文将对各部分的内容做详细介绍。

1、产品架构图的定义

产品架构图是一种将具象产品的业务架构、功能架构、信息架构、技术架构，生态架构以及商业模式等，通过层级划分、模块组合，而设计出的可视化图形，其抽象且精简的表达形式，很适合用来介绍复杂产品体系。常见的产品架构图有业务架构图、功能架构图、信息架构图，以及混合架构图。

有句俗语叫做： 思考常常越复杂，形式往往越简单 。人类历史上许多伟大的知识和定律都是以精简而优美的形式表达出来的，例如亚里士多德的三段论表述、牛顿的三大定律、欧拉的上帝公式，达尔文的进化论表述等。思考的足够通透后，只需要用简单的形式就可以表达复杂的体系结构和逻辑关系，相反很多看似简单的表现形式，背后却承载着巨大的复杂。

对比各种产品输出物（文档、原型图，流程图等），产品架构图的形式最为精简，都是由单一的矩形控件排列组合形成，但却在所有的产品输出物中拥有最高的抽象程度和复杂度，输出产品架构图是对产品经理产品设计能力的衡量和体现。

2、为什么要画产品架构图

在进行产品设计的时候，首先应该输出的是产品功能架构图，思考这张图如何画的过程，是帮助你梳理产品设计思路以及确定产品边界过程。例如，现在让你设计一个CRM系统，可以试着先画出具体业务的CRM系统的功能架构图，在画的过程中，会辅助你思考整个CRM系统有哪些核心功能模块组成，各模块的关联关系是怎样的，每个阶段应该做什么，从而形成完成的产品设计思路。

其次，产品设计的过程就像是盖大楼的过程，输出产品功能架构图就好比是搭建大楼地基的过程，产品原型设计的过程就像是大楼建造的过程，地基没有问题，后面的添砖加瓦就不会有太大问题。如果一开始地基质量就有问题而没有被重视，后续盖了一半发现整个工程出现问题，修复重建则会浪费巨大的资源和成本。所以项目初期产品功能架构图是很重要的交付物，当你要开始设计一个完整的产品方案时，如果跳过画产品架构图的步骤，直接开始画原型、写PRD文档，就很容易发生改了又改，甚至是做了一版需求然后又推翻的情况。

最后，在产品上线后无论是对内普及还是对外推广都需要有高度抽象，简洁易懂的载体来介绍产品整个情况，介绍和推广的不可能去用繁杂的页面和文字去描述，这个时候产品架构图会是介绍整个产品理念，功能和设计的一个很好的传达媒介。

3、如何画产品架构图

上文介绍了什么是产品架构图以及为什么要画产品架构图，接下来要介绍如何画产品架构图，产品架构图的画法主要分为四个步骤，分别是：（1）确定对象；（2）拆解结构；（3）挖掘关系；（4）表达输出。

图5-1产品架构图的画法

（1）确定对象

首先要明确产品架构图描述对象的范围和边界是什么，例如，对于一个CRM系统，要画的是CRM系统的业务架构图、功能架构图、信息架构图、还是综合了多种元素混合在一起的混合架构图。

（2）架构拆解

确定好描述对象的类型后，要对其进行架构拆解，例如，输出一家借贷平台的业务架构图图，可以拆解为贷前业务、贷中业务，贷后业务等。又例如输出一个CRM系统的功能架构图可以拆解出整个CRM系统的功能模块，如账户管理模块、客户管理模块、用户管理模块、权限管理模块，系统设置模块等。

（3）关系挖掘

输出对象的架构拆解完成后，需要发掘出各个模块之间的关联关系，同样以CRM系统的功能架构图为例，在拆分完整个系统的功能模块时，接下来要分析出各个功能模块的关系，产品架构图内部元素之间的关联关系主要有四种：统计并列关系、父子包含关系、辅助支撑关系，底层支撑关系。

（4）表达输出

确定了各个功能模块的关系之后，则需要进行关系表达，层级相同的模块元素，则按照同级并列关系，需要排列在一起。

例如，在CRM系统中，客户管理模块和权限管理模块就属于同层级的并列关系。而权限管理模块和权限分配这个功能模块之间则属于父子包含关系，在表达父子包含关系时，通常父级模块会包含住子级模块。

其次，一些产品的非核心的功能模块或者产品之外的一些功能模块，例如第三方平台的短信功能模块，这些模块对产品自身功能的实现起到了一定的辅助作用，与其他产品功能模块呈现出辅助支撑的关系，辅助支撑模块一边画在产品架构图的右侧。

最后是底层支撑关系，例如产品的 会员体系 是建立在账户体系的基础上的，所以账户体系与会员体系属于底层支撑关系。底层支撑关系的表达方式一般是支撑模块在底下，被支撑模块在上面。这些基本关系的图形化表达方式，会在后面小节结合实际的案例做详细介绍。

整个边界范围内的结构关系表达完成后，整体检查一遍是否有遗漏和错误，检查完毕后配上整个架构图的标题，架构图标题往往是对整个架构图内容的说明，一般放在最上面或者框架左右两边，最终输出完整的产品架构图。

爱因斯坦说过： 如果你不能把一件事情用最简洁的语言描述清楚，说明你还没有理解他。 对于产品架构图而言： 如果你不能用简单的矩形， 通过 排列组合的方式 ， 把一个复杂的产品 结构描述 清楚，说明你还没有真正理解 你做的产品 。 所以，在日常的产品工作中，要培养自己去画产品架构图的习惯，培养抽象思考能力的同时，辅助自己高效的完成产品方案设计。

原文地址：https://www.cnwebe.com/articles/157113.html