对于任何产品设计来说,构建过程都是一个不可分割的环节。它奠定了后续的产品框架,是用户体验的基石。本文将在定义和分类的基础上,结合实际案例,简单说明流程图的功能和绘制方法。
以上三个步骤构成了一个最简单的流程,完全涵盖了任何购物行为的核心。无论是网购还是实体超市,这三种行为都是主体,然后延伸。与大家平时看到的复杂的网购流程图相比,以上三步流程简直离谱,正好印证了“从大道到简”的原则。我一直相信,再复杂的事情,也可以化为极其简单的事情。如果不能简化它们,说明你只是不了解核心。
根据上面的最小流量单元,我们将尝试扩展它,并尝试将其应用到更详细的流程图中。
页面流程图(页面流程图)
定义:指电子产品的具体跳页流程图。它携带业务流程图中包含的业务流程信息。
以淘宝为例,下图是网购的页面流程。
从上面红框中的三个节点可以看出,页面流程图仍然包含在业务流程图中。这正好符合定义中的要求,也印证了页面流程图的正确性。相比当初的极简流程图,现在的流程图逐渐变得更加复杂。我们将抽象的业务映射到具体的页面上,并将业务需求携带到软件页面中。以上是业务流程图到页面流程图的转换过程。
功能流程图(功能流程图)
定义:指单页内或多页间的功能操作流程,包含在页面流程中。
任何一个功能都包含在一个页面中,但是一个页面中往往不止一个功能,所以单独的页面流程图可能无法完全表达所有的流程,那么就需要用功能流程图来更具体地表达每个页面中包含的功能。
从上面红框中的四个节点可以看出,功能流程图也是从页面流程图展开的。功能流程图在页面流程图的基础上不断深化,变得更加复杂。同时也逐渐变得像大家每天看到的流程图。
数据流图(数据流图)
定义:它是指在软件产品中绘制的图表,描述数据在不同节点处理的过程。它主要表达商业计算机程序的实现原理。用户在功能流程图中的每一个操作都会在数据流程图中体现出来。同时,数据流图也可以称为程序流图。
它是全面描述信息系统逻辑模型的主要工具。它可以用几个符号来综合反映系统中信息的流动、处理和存储。数据流程图抽象、笼统。
也许业务流程图、页面流程图、功能流程图大家都很熟悉,但恐怕对数据流程图不太了解。其实每个流程图都有一个核心,以不同的操作,不断的流过整个系统。例如,大多数业务流程图都是以人为中心的,每个节点都在传递不同的人的行为。页面流程图和功能流程图类似,都是以人的操作行为为核心,在不同页面和功能之间流动。而数据流程图则不同,它以数据为核心,展示整个系统是如何处理数据的。
更多的是技术思维,更多的是展示后台程序的实现原理。所以画这个图的往往是开发人员,产品经理参与较少。但是随着产品经理的不断成长,会向上到战略层面,向下到实施层面。了解程序的开发原理及其背后的数据流,无疑会让产品经理对产品设计有更深的理解。
下面的数据流程图还是以购物流程为主题呈现的。
与以前的图表相比,数据流程图增加了一个新的维度-过程。客户端不仅展示了用户的操作行为,还表达了用户行为背后的动作。当人们说一个产品很复杂的时候,他们可能只注意到了它前端交互的复杂性,而忽略了它后端逻辑的复杂性。一个优秀的产品经理,不仅要注重前端用户体验,还要能看清事物背后的逻辑。毕竟用户体验是每个人都可以口述的,说到程序实现,更能体现产品经理的专业性。
总结
上图分别展示了一个产品的业务流程、页面流程、功能流程和数据流程。可以发现,业务、页面、功能、数据处理都在依次扩展。产品的页面或功能不是由空显示的,而是根据业务层的每个节点和流程设计的。这就是为什么我们在设计产品时必须首先了解业务。
在初步学习画流程图的时候,尽量把业务、页面、功能、数据区分清楚,循序渐进,不要把各种类型的流程图混在一起。这样会迷惑心智。
流程图的粒度
流程图的粒度其实是指流程图的细节。
我在画流程图的时候,经常会犹豫和纠结。我应该更详细地描述这个功能点吗?这个分支会被标记吗?这个与服务器的交互事件是否体现在流程图中?等等,这些问题也是产品经理在日常绘图中遇到的。
以购物流程为例。最简单的业务流程分为三个步骤。如果比较详细,可以画出不同的流程图吗?
显然,即使是同一个流程,也可以画出不同的流程图。如上图,所选商品分三步,成交分两步。但是两个流程图还是表达了一套流程。这就是为什么每个人对粒度的理解不同。有很多新人总想一步画出完美的流程图。但这其实是一种非常不可取的思维。任何完美的流程图都需要经历从简单到复杂的过程,而不是一蹴而就。
理论上,流程图越详细,产品设计就越准确流畅。但实际上,过多的细节是浪费时间。把握粒度的能力需要经验积累和团队磨合。这也是产品经理可以把握粒度的地方。画流程图的最终目的是让团队成员理解我们的产品设计,而不是画一张非常详细的流程图。理想情况下,图表应该以团队能够理解的最简单的形式绘制。
流程图
上面说明了流程图的定义和分类,下面说明具体的流程图绘制方法
流程图的基本要素
这些是流程图中最常用的元素。此处不显示不常用的元素,您可以在微软Visio中查看它们。
泳道地图
泳道图是流程图中的一种绘制方法,根据不同的操作角色划分流程图中的一些流程节点。比如刚才数据流程图实际上是通过绘制车道图来显示的,其中顶层有两个不同的角色——用户和服务器。同时,在垂直的基础上,可以增加水平泳道,按不同页面对操作进行分类。
对于涉及多个角色的复杂流程图,绘制泳道流程图会看起来更清晰。
流程图的组成
流程图主要由三部分组成:
主干流程分支流程(异常流程属于分支流程)子流程下图以前面功能流程图的例子为主流程,再添加分支流程。我们在画流程图的时候,要遵循先主干后分支的顺序,因为主干流是大多数用户最常用的路径。
主流程和分支流程都很好理解,那么子流程是什么呢?在绘制流程图的过程中,经常会遇到一些流程,比如登录流程、注册流程、修改密码流程等。对于电子商务,可能会有退货流程,购物凭证使用流程等等。每次都要重新画一遍相关的流程图,会比较繁琐。因此,子流程是具有逻辑关系的节点的集合,可以在各个地方重用。
下图是登录流程变成子流程后的流程图。
流程图结构
流程图中有四种结构:顺序结构、条件结构(也叫选择结构)和循环结构。基本上大多数流程图都是由这三个结构组成的。
情形
上面说了这么多理论知识和概念,让我们用真刀真枪展示一个案例。本来我想以电子商务产品为例,因为电子商务产品是需要很强逻辑思维的产品,是常见的。但是后来发现淘宝和JD.COM都是极其庞大复杂的,分析起来太繁琐。转向自行车共享是一个非常好的教科书案例。其产品极简主义,但背后有着有趣的逻辑结构。尤其是mobike和ofo在市场上的不同产品解决方案,在分析上更具可比性。
自行车共享的前身
如果要追溯到最早的自行车共享,恐怕就是政府推出的堆砌自行车了。其目的是缓解交通压力,减少环境污染。当时受成本、技术和群众普遍素质的限制,堆码自行车的解决极其不方便。想租一辆有桩的自行车,必须先在相关单位用身份证办理IC卡,交押金和代垫费用。然后只能在指定地点租车还车。先不说办卡多麻烦,租车还车多不方便,加班扣费多神奇。如果简单的用业务流程图展示,应该是什么样子?
以下仍然是展示使用堆积自行车的业务流程图的最简单的业务形式:
单看堆自行车的流程图是没有任何意义的。真正的意义在于堆自行车和现在的mobike、ofo的横向对比。让我们来看看这两种自行车共享的业务流程图:
很明显,无论是堆单车、mobike单车还是ofo单车,业务流程图都没有太大的区别。那么,为什么政府主导的自行车在很多年前很常见,而2016年底出现的自行车共享却大受欢迎呢?mobike和ofo有什么区别?我们需要深入分析每个业务节点,分析其功能。
因为自行车的使用流程不仅仅是在APP上,在实体自行车上也是如此,不可能单独使用页面流程图,直接使用功能流程图。而且这里的功能流程图并不局限于页面中的功能,而是表达用户在自行车和APP上操作的每一步。
先看ofo单车,在APP里交押金,再找单车。这时候我们发现虽然ofo有很多自行车款式,很多车锁机构。不过这个案例重点是ofo的第一代机械锁和第二代伪智能锁。
这两个锁实际上代表了两种不同的产品解决方案。先讨论第一把机械锁。(所谓机械锁,其实类似于生活中经常见到的密码箱。每个密码箱都有一个预设的固定密码,可以通过拨号输入正确的密码来解锁。而且机械锁的密码是固定的,不会变)。
我们从路边找到机械锁自行车,然后打开APP,输入车牌号码或者扫描二维码,从APP中获取自行车的机械锁密码,然后输入密码打开自行车锁。这时候APP会倒计时,倒计时结束就开始正式计费。最后骑行到目的地后,需要关闭车锁,在APP中必须点击结束骑行的按钮,才能为本次行程结算订单。
看完ofo的过程,我们来对比一下mobike的过程。
Mobike的产品解决方案是扫描自行车的二维码后,mobike的车锁会自动打开,不像机械锁那样需要人工操作。而且锁车后,mobike会自动结束行程,不需要在APP里点击end。下次打开APP,结账。
下图是ofo机械锁自行车的流程图和mobike的流程图(APP logo代表用户在APP上的操作)
我们可以清楚的看到mobike的进程比ofo少了两个节点,这就是mobike相对于ofo第一代机械锁的优势。当然,第一代ofo在其他方面也优于mobike,比如骑行的舒适性。不过本文主要针对的是产品流程,所以没有在骑行体验上花太多笔墨。
看ofo机械锁和mobike智能锁的解决方案,ofo明显不如。机械锁带来的问题不仅仅是使用过程的复杂,还有产品使用上的漏洞。比如用户锁车后,必须手动拨打密码,否则下一个人就可以免费乘车了。比如用户骑行后忘记点击APP,会导致额外扣款。还有很多问题,就不一一列举了。
此外,ofo也理解这些问题。如果机械锁的解决方案只在封闭的校园内有效,那就不太理想了。但是一旦投入校外市场,这个解决方案无疑会给公司带来巨大的损失。那ofo为什么会知道问题并大量投放呢?原因很简单。以mobike扩张的速度,如果当时不迅速离开校园,他可能永远出不了校园。
言归正传。之前的讨论避开了一个很重要的节点——“找车”。除了在路边随机看到自行车,如果在地图上找车,第一代ofo机械锁肯定是没有GPS定位的。为什么能在地图上显示出来?
我们试着画一下ofo解锁的程序流程图。
我们从节点“APP扫描二维码/输入自行车号码”开始。如果我想开一辆车牌号为XXX的自行车,我需要得到密码,所有汽车的密码都要放在ofo的自行车数据库里。不管是扫二维码还是输入车号,本质应该是把车号传到服务器,告诉它我要哪个车的密码。服务器查询到这辆自行车的密码后,传回APP,我们看到了这辆自行车的密码。
因为节省了车锁的电量,服务器此时没有联系自行车,而是手动输入密码打开车锁。所以ofo会在用户拿到密码后开始倒数。解锁状态可以在倒计时内取消;倒计时结束,表示用户默认开始骑行,计费从此时开始。
这时,如果你是iPhone用户,当你最小化ofoAPP的时候,你会发现手机顶部的电池条变成了蓝色。其实这才是ofo自行车之旅的重点。既然机械锁无法向服务器传输数据,不如让用户的手机来代替。得到手机的位置就可以得到自行车的骑行路线。并且停车后点击结束骑行,并报告位置,以便服务器标记此自行车的停车位置。此时,报告位置没有自行车。这就是为什么ofo地图上有很多假标记的原因。
ofo使用的阅卷方式其实很粗糙。毕竟如果用户强行结束申请,就不会获得乘车路线。Ofo还处理了无法获得骑行路线的情况,即标记起点到终点,然后根据地图提供的路线显示距离。
上面我个人测试的案例。红色箭头是我实际的骑行路线,绿线是ofo自己地图上从起点到终点计算出来的路线。
我们继续分析ofo机械锁的程序流程图
注意上图中的服务,看起来步骤很少很简单,但真正的服务器一定有更复杂的逻辑判断。但是对于产品经理画的流程图,在编程中不可能完全描述技术细节,产品经理也没有必要帮助技术去思考代码的实现逻辑。我们需要做的是理解程序的宏观实现逻辑。
比如扫描二维码后,为什么APP显示的是这辆车的密码,而不是其他车辆的密码?很简单,所有自行车的密码都必须存储在服务器中,扫描二维码的过程是将这辆自行车的ID发送到服务器,服务器会在数据库中找到密码并返回给用户。
在这个过程中,服务器肯定会有其他的判断,比如用户账号是否正常,是否被封。这辆自行车被标记为故障车辆了吗?等等。但是你发现上面的流程图中并没有画出这些逻辑判断。我忘了吗?其实不是。这里我们不得不提到这个论文的核心概念——粒度。这个图意在表达程序实现的宏观逻辑,让读者更加关注问题的核心,我们只需要强调主要过程。如果增加更多的分支流程和异常流程,会影响读者的注意力。所以还是那句老话:画流程图一定要先分支,千万不要一开始就盲目追求细节。
离家近一点,ofo第一代锁的解决方案漏洞百出,但还是用其巧妙的方式在地图上显示自行车位置。ofo推出的二代锁,改善了以往机械锁的很多问题。最大的影响是车锁的密码不再固定,锁车后不需要点击结束行程。现在ofo的锁已经优化了,为什么以前叫伪智能锁?ofo和真正的智能锁有什么区别?为什么ofo的车锁还是需要手动输入密码,而不是像mobike那样直接解锁?为什么经常在地图上看到汽车,实际的地方却没有汽车?
这里有一段80后90后的童年记忆:你的传奇。
《你的传奇》(又名网易账号保护器)是广州网易互动娱乐有限公司自主研发的高科技身份认证产品,拥有完整的知识产权。旨在保护网易pass账号(游戏账号)和直销商账号的密码,其独有的60秒密码动态自动更新技术将黑客入侵风险降至最低。
《你的传奇》的出现伴随着梦幻西游的流行,其创新的技术确实解决了大部分黑客问题。你的传说的实现机制是什么?简单解释一下:首先打开“你的传说”,会生成一系列数字。当你登录游戏时,输入这些数字,系统将允许该帐户登录。同时,“你的传奇”号每60秒动态变化一次,“你的传奇”的验证码每次登录都会不一样。其实现原理是“你的传说”和服务器保持相同的算法,同时计算结果一致。
回头看ofo的伪智能锁,其实也是一样的实现原理。每个车锁都有一个单独的算法存储在服务器中,车锁会定期根据算法更改密码。当你打开APP查看自行车密码时,服务器使用与车锁相同的算法计算当前时间的密码,所以密码必须与车锁当前计算一致。
下图是ofo伪智能锁自行车的程序流程图
从上面的分析可以看出,即使是ofo二代锁也不与服务器通信,它的自行车仍然没有GPS,仍然由用户的手机定位。
Mobike的智能锁
在分析了ofo的机械锁和伪智能锁之后,我们来看看mobike的智能锁。情报在哪里?
首先,通过实践经验,我们知道mobike不需要输入密码。除了蓝牙本地密码验证,mobike车锁还需要与服务器进行通信,这样在APP扫描后就可以自动打开。
根据这个原理,画出mobike的程序流程图:
对比ofo的流程和上图可以看出,mobike采用的解决方案是将自行车和服务器连接起来。让每辆自行车成为一个终端,在整个地图上实时同步。这样,我们不仅获得了良好的汽车体验,还收集了用户数据。从解决方案来说,mobike比ofo完美得多。
总结
本文从定义、分类和绘图三个方面对各种流程图的特点进行了分层说明。尽量以教科书的形式解释其原理和机制。目前没有统一的流程图规范,难免会出现文字上的错误和误解。也希望大家可以作证,可以交流。
虽然本文的目的是介绍流程图,但整个思维过程才是我真正想表达的核心。任何复杂的东西都可以分解成最小的单位,然后再由最小的单位逐渐还原复杂的东西。推而广之,这种思维方式其实是一种分析事物的思维模式。掌握后可以应用到各种分析场景中。希望有机会单独写一篇文章详细介绍一下思维模式。
参考参考:
流程_百度百科产品经理业务流程图的绘制流程分享如何绘制业务流程图谈谈页面流程图(附案例)产品设计流程系列:业务流程和流程图介绍众云行第二弹:从BRD到页面流程图数据流程图_百度百科解读NB-Iot智能锁:为何ofo和摩拜都要做NB-Iot智能锁?#专栏作家#这篇文章是独家发表的,因为每个人都是产品经理。未经本网站许可,禁止转载。谢谢合作。
1.《程序流程图 一篇文章读懂流程图|附共享单车全流程解析》援引自互联网,旨在传递更多网络信息知识,仅代表作者本人观点,与本网站无关,侵删请联系页脚下方联系方式。
2.《程序流程图 一篇文章读懂流程图|附共享单车全流程解析》仅供读者参考,本网站未对该内容进行证实,对其原创性、真实性、完整性、及时性不作任何保证。
3.文章转载时请保留本站内容来源地址,https://www.lu-xu.com/jiaoyu/803913.html