产品经理如何画出完整的产品流程图(实例)

流程和流程图

首先来看流程的定义:

《牛津词典》里,流程是指一个或一系列连续有规律的行动,这些行动以确定的方式发生或执行,促使特定结果的实现; 而国际标准化组织在ISO9001:2000质量管理体系标准中给出的定义是:“流程是一组将输入转化为输出的相互关联或相互作用的活动”。

由上面的两个定义,我们可以提炼出流程不可或缺的因素:对象、输入、动作、输出。

  • 对象就是执行人,也就是产品中的用户;
  • 输入可以理解为前提、前置条件;
  • 动作,就是产品中的操作,可以是点击、输入,等等;
  • 输出,可以理解为结果、动作的目的。

需要说明的是:

  1. 产品工作中,输入和输出的形式并不局限,可以是事件,也可以是动作;
  2. 在思考输出时,也不能仅仅考虑用户端的输出结果,同时要思考后台可能产生的输出(比如数据的变化);
  3. 在相连的环节中,通常上一个环节的输出即为下一个环节的输入。

明确了流程的定义和要素之后,顾名思义,流程图就是将流程表达清楚的图形,流程图只要表达清楚一件事:什么对象在什么前置条件下执行了什么操作,产生了什么结果。

流程图的制作方法和工具,已经有很多的介绍,这里不赘述。产品工作中常用到业务流程图和任务流程图,下面将通过实例讲述我所理解的两种流程图的联系和区别。

业务流程图

业务流程图的作用是表达清楚业务需求在产品线的各个阶段中在各个功能模块之间的轮转。

通常情况下,一个业务需求不仅仅对应一个功能需求,而是由多个功能需求组成的,举例来说:业务需求是注册,那么功能需求就包括填写信息的正则校验,验证码的生成与校验,注册协议查看(和勾选),此外,后台还要有账户生成与信息记录的功能,需要手机注册的还要有短信的发送与验证功能(邮箱注册同理)。

可见,业务需求要求概括精炼,功能需求要求详细具体。一个业务需求通常涵盖多个功能需求,涉及前端展示、后台记录等多个部分,所以业务流程图通常复杂详细,尽量能够涵盖各种异常情况(每种异常情况都有相应的前、后台解决方案)。

业务流程图的绘制思路一般是:

  • 首先将业务按阶段划分,比如电商类可以分为下单和支付,单车类可以分为提车、骑行和停车;
  • 然后列出每个阶段参与的功能模块,比如下单阶段,就有商品查看、登录/注册、信息记录、个人中心等功能。
  • 最后按照时间顺序,画出业务需求在各个功能模块之间的流转情况。

为了输出一份完整的业务流程图,一般有两个原则:

  • 先思考主干流程,再思考分支流程,主干流程逻辑准确,分支流程全面无遗漏;
  • 表达清楚后台产生的各种判断及相应的前端展示,这将作为接口设计的重要根据。

下面以电商购物的实例,绘制一份业务流程图

一个完整的电商购物流程,通常包含两个阶段,五个部分,两个阶段就是下单和支付,五个部分是用户、交易、账号系统&个人中心、支付系统和CRM系统,如果仅仅从用户角度出发,很难考虑到后台各种判断和操作,那样就变成了任务流程图,而这个图中包含了购物流程的用户操作、前端展示和后台判断,体现了实现购物业务所需要提供的功能和各部门的支持,在这个图中也能看出所需要的接口和数据。

业务流程图应该是拿到业务需求(或BRD)后,首先输出的文档,而且并不是一成不变的,会在对业务需求或者BRD的多次讨论中不断补充完善,最后成为整个项目的标杆文件,在构建技术架构和技术分工时,将其作为主要参考。所以,绘制业务流程图时,一定要逻辑清晰,不能遗漏任何一个重要部分。

任务流程图

任务流程图表达的是用户在执行某个具体的任务时的工作流程。任务流程图可以理解为一个简化版的业务流程图,只有主要的操作步骤,通常在写用户体验报告时,利用任务流程图表达页面流转和主要操作,同样以电商购物为例:

由上可见,相比于业务流程图,任务流程图的特点是:

  • 只展现用户的操作,不展现后台的判断;
  • 只展现正常流程,不展现异常流程;
  • 只可查看用户的工作流程,无法作为开发的参考。

不管是绘制业务流程图还是任务流程图,重点都应放在逻辑关系上,而不是图形本身的细节。说到底,流程图只是帮助我们更好地进行分析思考的工具,能够画出逻辑清晰的流程图,不一定对每个模块都了如指掌,但如果流程图逻辑混乱、含糊不清,那么肯定要反思是不是对业务需求或者功能需求的理解不清晰。作为刚入门的新手,结合思维导图,经常分析产品的业务流程和任务流程,对提高逻辑感和产品思维,还是很有帮助的。

一. 工具

目前画流程图的工具很多,桌面应用、在线流程图工具等balabala。但其实最好用还是一张大纸,一支笔,感觉纸笔的速度更容易跟上思考的速度,更容易体验爽到飞起的感觉。

二. 实例

最近也在梳理购物车相关联的一些功能,用就这个例子说明一下如何使用流程图帮助梳理逻辑。

购物车作为一个存储商品和最终下单的中间过程,梳理时,必然不能忽略其上下游。

一个用户通常可能有两种路径查看购物车,如下图:

电商平台中,购物车常常会作为一个重要icon直接出现在底部导航中,用户新装完APP后,为了熟悉,可能会依次分别操作底部导航按钮,所以上图中区分了路径B。

通过上图,能够明显分出购物车的空状态和有商品状态。其中空状态也有很多延展情况,比如是否要给用户一个跳转至其他页面的引导?是否要给用户推荐商品?这个涉及到其他逻辑,暂不赘述。

以下的内容主要针对购物车有商品的情况。

我们能够很自然的想到购物车中要展示商品的图片、名称、已选的规格及数量,价钱等信息,所以能够产出如下的原型:

然而,这个原型是否全面呢?我们不妨多问自己几个问什么。购物车的商品如果卖完了怎么办?什么时候商品才会显示被选中的状态?小图是要展示哪一张图呢?商品的名称是显示完整还是要依据什么规则截取?规格是否要显示完整……如此,基本上页面的每一个元素,都要想一下为什么出现,作用是什么,切记想当然。这样将页面的元素拆解后,很容易得到拆分后的局部的小逻辑。

从一个元素(或者问题)入手,开始梳理局部逻辑。比如第一个问题,加入购物车的商品如果卖完了怎么办?这种情况需要给用户一个“缺货”的提示。缺货后如果被下架呢?那么需要有一个下架的提示。

其中,库存不足的这个状态正常可能比较容易忽略,但实际上,库存不足是从正常状态过渡到售罄状态的一个中间状态。

这样,基本能够将购物车中的各种可能的状态补全,更友好的提示用户。

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/447.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息