做产品，为什么要画这些图？

　　画图之前，我们一定要知道：为什么要画图？因为，画图是需求分析的重要环节，是用可视化的方式，对需求进行梳理和展示，把需求描述清楚，才能保证想法落地变成产品。
　　经常看到网上有人问，产品经理要画哪些图，怎么画流程图等关于画图的问题。
　　确实，画图是产品经理必备的硬核技能。然而，画图又不仅仅是画几个图而已。
　　做产品没有统一、标准的规范指导，容易让人为了画图而画图。
　　甚至，在很多外行看来，感觉产品经理就是个画图的。
　　还有人戏称，去大厂当产品经理，就是个画图仔。
　　幸好，我从最初做项目，就学着用UML进行需求分析。受益于此，我渐渐体会到，画图背后的逻辑和意义。
　　趁这段时间，从画图入手，用自己的理解，总结自己做产品的方法。
　　一、当我们画图时，是在画什么
　　1。探寻本源
　　在需求分析领域，谈到画图，不能不提UML。
　　早在IT软件时代，UML就是一套非常好用的需求分析、系统分析设计的工具和方法。
　　那么，什么是UML？
　　UML（UnifiedModelingLanguage）统一建模语言，是一种用来对软件系统开发的产出进行可视化、规范定义、构造和文档化的面向对象的标准建模语言。
　　这是比较官方的定义。
　　我理解：它是用一套规范的可视化图形，及建模方法，来描述软件系统的分析、设计等各个阶段，最终形成可视化、文档化的产出。
　　作为一门语言，UML在建模过程使用的基本图形元素，就是它的“词汇”，如用例、参与者、类等；而这些元素间的使用规则，好比“语法”，如用例图、活动图便是在这种“语法”指导下绘制的视图。
　　学习一门语言，既要学习其“词汇”，也要掌握其“语法”的运用，将“词汇”合理组织起来，才能编写足以“传情达意”的“文章”。
　　UML中，通过元素、视图建立起来的模型，正是这样一种可准确描述需求，又便于用开发思维去理解的“文章”。
　　UML不仅提供了一套工具，还提供了一套思想和方法。
　　学工具，只能让我们知其然；掌握该工具背后的思想和方法，才能让我们知其所以然、活学活用。
　　UML中，将可视化视图分为“静态视图”和“动态视图”。从“静”和“动”两个维度，来描述软件系统。
　　这也是人们描述现实事物的方法。
　　从“静”的方面，描述事物的结构性特征；
　　从“动”的方面，要描述事物的行为性特征。
　　一静一动相结合，便能把事物全面、准确地描述清楚。
　　这让我明白，做产品需求分析，也是对需求进行描述和表达。
　　使用这种方法，从静态、动态两个视角维度去分析和描述需求，就有了指导思想，能提高准确性和效率。
　　2。画图的实质
　　这就不难理解，当我们画图时，一方面是在借助工具，对业务、需求、场景等进行梳理；一方面是在对需求、产品进行描述，并输出可视化的材料，供相关人员，阅读使用。
　　因此，画图，是需求分析的重要组成部分，是用可视化的方式，对需求进行梳理和展示。
　　需求理解和描述清楚了，才能真正把想法落地变成产品。
　　同时，产出的可视化图形，是后续产品规划、研发、设计、测试，及优化迭代、问题排查等的重要依据。
　　3。本文思路
　　UML中的图形、视图、建模方法等知识内容很多，要深入学习，推荐《大象：ThinkinginUML》一书。
　　本文，结合在产品工作用到的内容，及自己的理解、体会，先从整体进行总结，建立一个整体的认知框架，后续再具体深入。
　　为了方便理解，我结合在资讯、充值等方面的经验，虚构了一个小型APP的前端需求，作为案例来分析。从静态、动态两个维度，总结在产品工作中常用的视图。
　　二、从静态视角看需求
　　从静态的视角去分析需求，是用静态视图，来描述产品的结构性特征，这些结构决定了产品是由什么组成、能做什么、长什么样的。
　　在UML中，静态视图包括用例图、类图、包图。类图与包图，在产品层面较少使用，开发层面更为需要。
　　结合实际工作，总结产品的静态视图有：结构图、用例图、无交互的原型图。
　　1。结构图
　　结构图，顾名思义就是描述、展示产品的基本结构、框架。它能清晰展示产品有哪些模块、功能或系统组成，它们之间的层级、从属等结构关系是怎样的。
　　这在需求分析的初始阶段，就要明确。
　　好比，建一栋楼，需要有建设蓝图，得先知道楼要建多高、地基要挖多深、面积多大、盖多少层等基本的框架信息。
　　结构图，像一栋楼的框架，那么一旦确立，就很难改，除非推倒重来。所以，一开始一定要搞清楚，避免挖坑。
　　当然，在基本框架下，随着对需求的不断深挖，各模块、功能、系统之间的结构、层级、从属关系，会更加清晰，结构图也要细化、完善。
　　根据使用情况，结构图大致可分为：功能结构图、信息结构图、产品结构图。
　　1）功能结构图
　　功能结构图，就是描述产品都有哪些功能，层级和归属关系是怎样的。
　　这在产品工作中，经常用到。大部分人做产品，都知道在规划产品时，要画功能结构图。
　　现在用案例来看看这些图是怎么画的。
　　这个虚构APP的需求是：要做一个APP，给用户提供电商优惠活动信息、手机话费充值，后续会加更多功能，发展用户体系等。
　　一般经过需求调研和确认，脑海里就要有个大概的框架，这个APP给什么人用的、由哪些功能组成。
　　这个需求，我只能先脑补需求调研和确认的过程，然后得出这个产品大概要有：首页聚合展示、优惠活动、话费充值、个人中心，这四个大的功能模块。
　　功能结构图
　　2）信息结构图
　　信息架构图，跟功能结构图，容易搞混。
　　其实，有所不同，信息结构图重点在“信息”。也就是，从信息的维度，将整个产品的信息进行抽象、归类，说明产品包括哪些信息、字段数据。
　　这有点类似，UML中的类图。在产品层面，更多是要把产品里面的信息进行整理、归类、描述清楚，特别是信息的类型、条件、规则。比如，标题字数上限、图片尺寸等。
　　案例中的需求进行抽象，可以得出如下简单的信息结构图。
　　信息结构图
　　3）产品结构图
　　产品结构图，网上说法不一，这本来就没什么标准，关键是看怎么理解、怎么用，能把需求准确、清晰地描述出来即可。
　　个人理解，产品结构图，就是功能结构图与信息结构图的结合。
　　就是在描述功能结构后，把对应功能模块有哪些信息，这些信息字段的定义、规则、条件、类型都列出来即可。
　　这种做法，更为常用。这个图画出来内容比较多，因为篇（太）幅（懒）关系，这里就不再画，可以自行脑补下。
　　2。用例图
　　用例图，采用参与者和用例来展现产品的功能性需求，是UML中一种很重要的视图。
　　在UML中，将用例图，分为业务用例图和系统用例图。
　　除了画图，还要写用例规约，以描述说明用例，包括对用例的描述、参与者、前后置条件、基本流程等，一般用表格形式比较清晰。
　　1）业务用例图
　　业务用例图，是从业务的视角，通过业务建模，对业务进行描述。
　　这里说的业务，是在还没有新系统或产品前，业务是如何进行的。
　　UML使用业务用例图，进行业务建模，旨在把业务描述清楚，发现业务问题和难点，这样的新系统才能更好的融入业务去解决问题。
　　简单的需求，很少画业务用例图；如面对比较复杂、有规模的需求，建议最好用这个思路进行分析，可以更好地发现业务问题，以保证产品需求不跑偏。
　　案例需求中，就话费充值这个业务，可画成业务用例图如下。
　　业务用例图
　　2）系统用例图
　　系统用例图，是对有新系统或产品后，业务又是如何进行的，进行建模描述。它是对业务用例进行分析得到的，是系统的开发范围。
　　简单看来，系统用例图与功能结构图很类似。
　　功能结构图，只是从产品或系统层面，描述都有哪些功能。
　　系统用例图，则是从使用者的角度，描述对应用户能使用产品做什么。这样的好处，是让我们时刻以用户为中心，思考产品和功能。
　　好多人，在做产品时，经常做着做着就忘了用户是谁、产品或功能是给谁用的。使用系统用例图，可以帮我们避免这一点。
　　以下为案例需求的系统用例图。
　　系统用例图
　　3。原型图（无交互）
　　原型图，是产品经理最熟悉不过的，也是最常用的。甚至，有不少人，以为做产品就是画原型图，一接到需求，巴不得马上打开Axure画图。
　　众所周知，原型图，是产品表现层面的Demo，描绘产品的界面长什么样，功能如何设计、摆放，有哪些内容。
　　好比，建一栋大楼，需要设计每一层楼的布局，都有哪些房间、大小怎样，到具体每一间房的格局，什么地方设置门、在什么位置安窗户等。
　　一般来说，无交互的原型图，属于结构图的范畴。在工作中，为了提高效率，很少画交互型的原型，除非像大厂有专门的交互设计师。
　　画原型，除了要准确把握需求，还涉及一些人机交互、视觉设计的知识。这里不具体展开。案例中的话费充值功能，简单绘制原型参考如下。
　　话费充值页面原型
　　三、从动态视角看需求
　　从动态的视角去分析需求，则用动态视图，来描述产品的行为性特征，这些特征决定了产品是怎样运行的。
　　在UML中，动态视图包括活动图、时序图、协作图、状态图。协作图，在产品层面较少使用。活动图，就是常用的流程图。
　　结合实际工作，总结产品的动态视图有：流程图、时序图、状态图。
　　1。流程图
　　流程图，是描述为完成某个目标，需要以什么顺序做哪些动作；能直观描述实现目标过程的具体步骤。在很多领域，被广泛使用。
　　梳理、绘制流程图的过程，也是一种流程化的思考。
　　UML中，流程图，也叫活动图；另外，还有泳道活动图。产品上，都经常使用。
　　1）普通流程图
　　普通的流程图，就是在描述产品的具体功能，在具体场景下，是怎么一步步实现的运转过程。
　　普通流程图中，包括了多个不同对象执行的动作事件，只能大致描述过程；无法将整个过程中，参与的各个对象体现出来。
　　案例需求中，从用户感受到的充值过程，用普通的流程图来梳理，可绘制如下。
　　用户充值话费流程图
　　2）泳道活动图
　　泳道活动图，用来梳理、描述有多个对象参与的流程，对象可以是人，也可以是系统。
　　泳道活动图，在活动图的基础上，引入了泳道，像游泳比赛的运动员只能在其泳道中比赛一样，规定每个对象的动作只能画在其对应区域。
　　这样，可以很好地体现整个过程参与的多个对象所做的动作和顺序。
　　同样是用户充值话费的过程，在产品层面，至少有用户、APP、管理后台、话费供应商（这跟每个公司的业务和系统情况有关，但基本逻辑类似。）的参与才完成。
　　因此，用泳道活动图来描述，最合适不过。为了避免示例图过于复杂，此处仅画出正常流程，并未包括异常分支。
　　话费充值泳道活动图
　　2。时序图
　　时序图，用于描述产品为实现某一具体目标，多个参与对象之间按时间顺序交互的过程。
　　时序图，与泳道活动图类似。不同的是：时序图更强调对象在交互过程中消息事件的发生顺序。
　　有时为了了解系统性能，或优化体验，要统计某些交互的时长，用时序图，就很方便定义和描述。
　　用时序图来梳理多个系统间的交互过程，特别好用，我最常使用。时序图画得好，泳道活动图不画都没关系。
　　同样用户充值话费过程，用时序图来梳理，可以对比下与泳道活动图的区别。
　　话费充值时序图
　　3。状态图
　　状态图，用于描述产品为完成某个目标，某个对象的状态变化和流转过程。状态，是对象执行或等待某个事件的条件。
　　常见的，有电商的订单状态、快递物流状态、支付状态等。
　　系统中对象的状态细化和明确，对监控系统的处理过程，和事后问题排查有很大帮助。
　　状态图非常重要，又很容易被忽略。以前填过很多坑，就是产品没定义好状态，结果开发按自己想象补上了，事后发现问题，处理起来很麻烦。
　　如案例中，如今的话费充值，虽然到账时间很快，但订单在系统的流转过程，也有各种状态的变化。
　　下面以此为例，看看一个比较完整的状态图，可以注意下其与流程图的区别。
　　话费充值订单状态图
　　四、原则与工具
　　1。基本原则
　　画图，虽说没有标准答案，但毕竟，产出的可视化图形是后续工作的重要依据，也要给各环节的人阅读使用。
　　所以，为了保证产出质量和工作效率，还是要满足以下基本原则：
　　逻辑合理、清晰
　　没有疏漏
　　可读性强
　　美观
　　2。善用工具
　　画图、分析过程，可用的工具很多，只要功能满足我们的需要，用起来顺手即可。
　　另外，一定要善于利用工具，让工具为我们所用，可找准一两个工具，用好它，能大大提高效率。
　　比如，Axure就非常强大，不仅画原型图，大部分图都可用它完成。
　　甚至，还能用来写需求文档，这样输出的文档相对统一，便于管理和阅读。
　　其他常用的，有Visio，及专门画思维导图的MindManager、XMind等。
　　其实，只要掌握了方法，哪怕是用纸和笔，照样能描述清楚。
　　五、回顾总结
　　总结一下：做产品为什么要画这些图？
　　首先得明白：为什么要画图？
　　因为，画图是需求分析的重要环节，是用可视化的方式，对需求进行梳理和展示，把需求描述清楚，才能保证想法落地变成产品。
　　能帮助我们梳理、分析需求，更好地理解和分析清楚需求
　　能产出可视化的需求描述，便于阅读使用
　　其次得知道：为什么画这些图？
　　因为，画图有一定的指导思想和方法，能提高准确性和效率。
　　UML提供了很好的思想和方法，可以从产品的静态和动态两个视角进行描述。
　　由此，有了静态和动态两种视图，每个视图有对应的图形，供不同情况使用。
　　1）静态视图，描述产品的结构，决定产品是由什么组成、能做什么、长什么样的。包括：
　　结构图：功能结构图、信息结构图、产品结构图
　　用例图：业务用例图、系统用例图
　　原型图（无交互）
　　2）动态视图，描述产品的行为，决定了产品是怎样运行的，包括：
　　流程图：普通流程图、泳道活动图
　　时序图
　　状态图
　　六、写在最后
　　写完之余，感受颇深。
　　原本只想大概总结下，不料职业病又犯了为了总结，把整个分析过程的思路重新捋了一遍，把每个环节的分析视图画了一遍。
　　虽然严重影响进度，却感觉体会又加深了。
　　平时分享，可能几句话就能讲清楚的内容，用文字记录并表达出来，却是删删改改，终不能满意。
　　篇幅关系，很多内容未能很好展开，每个人对文字的理解也不同。
　　况且，个人的理解和思路，也并非标准答案；只是通过自己的总结，抛砖引玉，提供一些参考，愿您有所启发。
　　感谢阅读！
　　参考资料：
　　大象：ThinkinginUML》
　　《人人都是产品经理》