网购流程(流程图的设计思路和绘制方法)

对于任何产品设计来说,构建流程都是一个绕不开的环节。其奠定了后续的产品框架,是用户体验的基石。本文将从定义和分类出发,结合实际案例,深入浅出地阐述流程图的作用以及画法。

网购流程(流程图的设计思路和绘制方法)

定义

流程——顾名思义:水流的路程;事物进行中的次序或顺序的布置和安排。流程是自然而然就存在的,它可以不规范,可以不固定,可以充满问题。

由两个及以上的步骤,完成一个完整的行为的过程,可称之为流程;注意是两个及以上的步骤。

流程图的核心就在于如何排布事物进行的次序,不同的顺序可能造成截然不同的结果。

目的

产品经理画流程图的目的不外乎几点:

流程图为产品设计基石,可以保证产品的使用逻辑合理顺畅传达需求,用流程图来更好地表达产品逻辑查漏补缺,检验是否有遗漏的分支流程分类

流程图以描述对象分类,包括:业务流程图、页面流程图、功能流程图、数据流程图等。

业务流程图(Transaction Flow Diagram, TFD)

先以宋丹丹小品中的一个脑筋急转弯为例:把大象装冰箱,总共分几步?

三步:

第一步,把冰箱门打开;第二步,把大象装进去;第三步,把冰箱门关上。

这看似是一个笑话,但其实蕴含着很强的逻辑思维。首先这里忽略了很多现实中的限制条件。比如,以大多数冰箱的容积都不可能将大象塞进去;比如是否能把大象切成块放进去?如果把大象塞进去,它会不会又跑出来?但抛开这些限制条件,那把大象塞冰箱的极简流程就是三步。打开冰箱门,把大象装进去,最后把门关上。

我们做业务流程图,其实很多时候都需要具有把“大象塞进冰箱”的思维方式,抛开很多现有的认知局限,将具象的行为一个个抽象出来。

结合上面的例子,再来细细品味“业务流程图”的定义:

抽象地描述事物进行的次序和顺序,不涉及具体操作与执行细节。在互联网软件行业通常指脱离产品设计的用户行为流程。业务流程图是一种系统分析人员都懂的共同语言, 用来描述系统组织结构、业务流程。

不管是否理解上述定义,下面带着抽象思维去思考购物行为的业务流程图应该是什么样的?

以上的三步组成了一个最简的一个流程,其完全涵盖了任何购物行为的核心。无论是网购还是在实体超市,都是以这三个行为为主体,然后进行扩展的。相对于大家平时看到的复杂的网购流程图,以上的三步流程简直简单的令人发指,而这恰恰是印证了大道至简的原理。我始终坚信无论再复杂的事情都能简化为极其简单的事情,如果你无法将其简化,说明只是你没有理解其核心。

依据上面的最小流程单元,我们下面尝试能不能将其扩展,尝试套用在更细节的流程图上面。

页面流程图(Page Flow Diagram)

定义:指电子产品具体所呈现的页面跳转流程图。其承载了业务流程图所包含的业务流转信息。

下图以淘宝为例,展示出了网购的页面流程。

网购流程(流程图的设计思路和绘制方法)

由上图红框中的四个节点我们可以看出,功能流程图同样也是由页面流程图拓展而来的。功能流程图是在页面流程图的基础上继续深化,变得更加复杂。同时也渐渐变得像大家日常看到的流程图一样。

数据流程图(Data Flow Diagram)

定义:特指软件产品中,描述数据在不同节点被处理的过程所画的图表。主要表达计算机程序对于业务的实现原理。用户在功能流程图中的每一个操作,对应都会反映在数据流程图中。同时,数据流程图也可以叫程序流程图(Program Flow Diagram)。

它是一种能全面地描述信息系统逻辑模型的主要工具。它可以利用少数几种符号综合的反映出信息在系统中的流动、处理和存储的情况。数据流程图具有抽象性和概括性。

可能业务流程图、页面流程图和功能流程图大家都耳熟能详,但数据流程图恐怕了解的就比较少了。其实,每个流程图中都有一个核心伴随着不同操作在整个系统中不断流转。比如业务流程图大多以人为核心,每个节点都是在传递人的不同行为。而页面流程图和功能流程图也类似,都是以人的操作行为为核心,在不同页面和功能间进行流转。但数据流程图不同,它是以数据为核心,展示整个系统中,数据是如何被处理的。

其更偏技术思维,更多的是展现后台程序的实现原理。所以,常常是开发人员绘制此图,而产品经理涉及较少。但随着产品经理地不断成长,向上提高到战略层,而向下则会深入到实现层。理解程序的开发原理和背后的数据流转,无疑会让产品经理对产品设计有更加深刻的理解。

下面仍以购物流程为主题来展示数据流程图。

网购流程(流程图的设计思路和绘制方法)

相较于之前的图表,数据流程图增加了新的维度——程序。客户端在展现用户操作行为的同时,也表达了程序在用户行为背后的动作。而往往大家说一个产品复杂的时候,可能只注意到了它的前端交互复杂,而忽视了后端逻辑的复杂。对于一个优秀的产品经理来说,不止要关注前端的用户体验,更要能看清事物背后的逻辑。毕竟人人都可以对用户体验指手画脚,而说到程序实现,那可就体现出产品经理的专业性来了。

小结

以上几幅图片分别展示了一个产品的业务流程、页面流程、功能流程和数据流程。从中可以发现,由业务到页面,再到功能,再到数据处理,是顺序拓展的。一个产品的页面或功能,不是凭空出现的,而是依据业务层的各个节点和流程进行设计的。这就是为什么在做产品设计时一定要先理解业务的原因。

在初步学习画流程图时,尽量将业务、页面、功能和数据区分清楚,并且逐层递进,不要把多种类型的流程图混杂一起。这样反而会将思想搞得混乱。

流程图的颗粒度

所谓流程图的颗粒度,其实就是指流程图的细致程度。

我在画流程图时也常常会犹豫纠结,这个功能点用不用描写得更详细?这条分支用不用标出来?这个和服务器的交互事件用不用在流程图体现?等等这些问题,也都是产品经理在日常画图时会遇到的。

依然拿购物流程为例,最简的业务流程分为三个步骤,那如果细化一些,是否可以画出不同的流程图呢?

网购流程(流程图的设计思路和绘制方法)

单看有桩单车的流程图其实没有任何意义,真正的意义在于有桩单车和目前摩拜与ofo的横向对比,下面看一下两家共享单车的业务流程图:

网购流程(流程图的设计思路和绘制方法)

很明显可以看出,无论是有桩单车、摩拜单车还是ofo单车,在业务流程图上竟然没有太大区别。那为什么多年之前政府主导的有桩单车平平无奇,而2016年末出现的共享单车红极一时?那摩拜和ofo两款截然不同的单车,区别点到底在哪里呢?我们需要更加深入地分析每个业务节点,剖析其功能。

因为单车的使用流程不仅是在APP上,还有一部分操作在实体自行车上,这时就不能单使用页面流程图,而是要直接使用功能流程图。并且这里的功能流程图不局限于页面内的功能,而是要表达用户对单车和APP的每一步操作。

首先看ofo单车,在APP中支付押金后,接着便需要寻找自行车。而这时我们发现,虽然ofo有多种单车样式,多种车锁机制。但本案例着重讲ofo第一代机械锁,与第二代伪智能锁。

这两种锁其实代表了两种不同的产品解决方案,我们先讨论第一种机械锁。(所谓机械锁,其实类似于生活中经常见到的密码箱。每个密码箱有预设的固定密码,通过拨弄表盘输入正确密码,即可开锁。并且机械锁的密码是固定的,不会改变)。

我们从路边找到机械锁单车,然后打开APP,输入车牌号或扫描二维码,从APP中得到本车的机械锁密码,然后输入密码,打开单车车锁。此时APP中会进行倒计时,倒计时结束则开始正式计费。最后,骑行到目的地后,需要将车锁关闭,并且必须在APP中点击结束骑行的按钮,才能结算此次行程的订单。

看完了ofo的流程,下面来对比看一下摩拜的流程。

摩拜的产品解决方案为,扫描单车的二维码以后,摩拜单车的车锁会自动打开,不需要像机械锁一样手动操作。并且在锁车后,摩拜单车自动会结束行程,无须在APP中点击结束。在下一次APP打开时,才会进行账单结算。

下图分别为ofo机械锁单车使用流程图和摩拜单车使用流程图(APP标识代表用户在APP上的操作) 网购流程(流程图的设计思路和绘制方法)

ofo采用的这种标记方法其实非常的粗糙,毕竟如果用户强制结束应用,也就获取不到骑行路线了。而ofo针对获取不到骑行路线的情况,也做了处理,那就是用标记起点到终点,然后根据地图提供的路线来显示路程。

网购流程(流程图的设计思路和绘制方法)

上图我亲测的案例。红色箭头是我的实际骑行的路线,绿色线是ofo自带地图上通过起点和终点计算的路线。

下面我们继续分析ofo机械锁的程序流程图 网购流程(流程图的设计思路和绘制方法)

由上面的分析可知,即便是ofo第二代锁,也并没有和服务器通信,其单车依然没有GPS,依然是靠用户手机定位。

摩拜单车的智能锁

上面分析了ofo的机械锁和伪智能锁以后,我们再来看看摩拜单车的智能锁,到底智能在哪里?

首先通过实际体验我们知道,摩拜单车是不需要输入密码的。抛开蓝牙本地验证密码的方式,那摩拜车锁需要和服务器通信,才能实现APP扫描之后自动打开。

下面依据此原理,画出摩拜单车的程序流程图:

网购流程(流程图的设计思路和绘制方法)

由上图对比ofo的流程,可以看出摩拜采用的解决方案是将自行车与服务器连接。让每一个自行车都成为一个终端,实时同步在整个地图上面。这样既获得了良好的用车体验,也收集到了用户数据。就解决方案来看摩拜是比ofo完善很多的。

以上就是整个ofo与摩拜解决方案的对比,其中我也画出了不同阶段的流程图。基本可以代表我分析案例的一些思路。最主要的还是让大家能够理解并应用流程图到日常产品设计与分析中。我们在构建流程图时,如果能按照本文的方法,由业务到程序,由简单到复杂,那相信一定会让你的思路更加清晰顺畅。

本文来自作者:抖音上热门方法,不代表小新网立场!

转载请注明:https://www.xiaoxinys.cn/598378.html

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请联系我们举报,一经查实,本站将立刻删除。