选购商品的流程
画具体任务流程的时候要注意从整体流程到局部流程,从主干流程到分支,从正常流程到异常流程。
对于交互设计师来说,任务流程的主体一般是产品的用户,任务流程图反映的则是用户的行为。
拿滴滴和易到来说,打车就是主干流程,查看行程、查看优惠券、设置就是分支流程,做设计时应该先考虑打车流程,再去完善其它流程;用户正常打到车是正常流程,网络异常、高峰期打不到车等属于异常流程,先考虑正常流程、再考虑异常流程,而且异常流程一定要思考的全面。
产品的逻辑漏洞多半是由于异常流程没有考虑清楚,所以画任务流程图能有效的减少产品原型图的逻辑漏洞。
虽然流程图简单,但也有一套规则。按照规则来画,才不会被笑话。
流程图绘制规则

页面流

通过泳道图和流程图,把业务流程和各个功能的任务流程用图示的方式梳理清楚。其中任务流程图直观的告诉我们整个业务模型是怎样的、涉及到哪些主体,这些主体下面都有什么任务要完成;任务流程图展示了主干任务和分支任务,描述了一个任务的大致流程。
而页面流程图的对象是页面,页面是互联网产品设计最基本的单元,不管APP也好、H5也好、PC端也好,这些产品由一个个页面组成。页面流描述了用户完成一个任务需要经过哪些页面。
也就是我在哪,经过什么操作,能去哪。页面流有三个要素:页面、行动点、连接线。下面拿购物的页面流举例说明:
购物页面流
画页面流时一般只考虑用户的正常路径就行,如果需要指出异常流程,在正常流程附近画出异常流程就行。产品设计从需求分析到信息架构、再到业务流程——任务流程——页面流、再到最后的原型图(线框图)是一个从抽象到具象的过程,也是从概况到细分的过程。经过一步步的分析,逐步将想法变成实实在在的产品,这就是产品设计的魅力所在。而这其中流程设计起到举足轻重的作用,不可忽视。
本文由 @邹志楠 原创发布于人人都是产品经理。未经许可,禁止转载。

三种常见「产品流程图」是如何思考与绘制出来的?

「流程」较之于原型图是更为抽象些的东西。画个流程图怎么画?该画什么不该画什么?怎么思考?
流程分为哪些类?这些东西直到真正接触过之后,才慢慢搞懂,之前真是懵懂懵懂,产品这东西啊,没有让你动手实践,还真是欠些什么。

那先来说下什么是流程?

流程说白了就是先做什么后做什么。如果说所有的动作都是单独的个体,那么流程就是串联起这些个体的线,没有流程便无法实现我们想要做的事情。
这样是不是理解起来比较简单了?细想想,周遭的事情,大多都有流程这个东西。吃饭?睡觉?学习?是不是都有他的一个流程,如果颠倒顺序或中间缺少一环,就会显得奇怪。
工作时,我们要是搞丢某个环节或流程错误了,产品或是工作就会出现漏洞与事故。
那么产品经理日常中大概最多接触的是一下流程,他们包括业务流程、操作流程和页面跳转流程。
这些都是0-1岁产品经理该掌握的东西,他们多是围绕产品本身展开,理解起来并不困难。他们都是呈现给你的团队,你的下游的交付物,全团队都会遵照这个流程来行动。

再来解释下他们之间的区别?

业务流程
通常会由几个「角色」来组成,他会有一种流水线般的工作线,A搞定了,传给了B,B搞定他的部分,传给了C,C搞定后又要将结果传给A做。
简单的理解这种穿梭在各种角色中的操作就是所谓的“业务流程”。他组成了你产品能够运行起来的最根本的行为。如果业务流程走不通,那么这个产品就是不可用的。
操作流程
是什么?是用户要完成某件任务要经过的哪些操作。流程只说明用户的操作就可以了,这个相对简单一些,因为我们人人都是“用户”。比如登录注册流程、地图应用导航流程等等。
页面跳转流程
这一部分主要是让别人理解你网站的一个交互过程,让人不至于看懵。
这里面会设计到一些逻辑上的问题,比如一个提示弹框出现后,如果点击确定,下一步页面去哪里?点击取消呢?点击返回是返回哪里呢?这都是你要在这里解释清楚的事情。

拿外卖点餐产品当栗子,分别说明他们

首先从业务流程开始说起了,我在设计产品的时候常常从业务流程开始。我们要做一个叫“我要订餐”的产品。
现在我们需要一个流程将业务跑通,假象一下我们的产品是个第三方订餐平台,平台上有很多餐馆,用户通过我们的平台点餐付款,我们通知餐馆做饭,送餐等等。
我们首先要做的就是理清产品中有多少种角色,在脑子里想象下如果一个用户下单,需要穿梭过多少种角色才能完成它的下单流程,然后用软件或是纸笔来将流程画出。
画业务流程通常会用到“泳道图”这个是专门来表示多角色配合的一种流程。如下图,我随手画的,示意一下。
角色有三,用户,系统(后台),厨房(第三方商家)。
我们来跑一下这个短短的流程,如果「用户」选好了今天的饭菜,提交订单了,这时就将订单信息推送给了「系统」,「系统」在后台生成订单,用户的订单状态变为「等待付款」。(其实系统这部分用户是看不到的,但是产品经理需要想清楚。)
用户会来到支付页面,这时候做一个判断,用户是否为这个订单支付了费用呢?如果是,那么「系统」就会受理这个订单,将信息推送给第三方「厨房」,如果不是,那么用户就是取消了订单,订单状态变为「订单失败」。接受到订单的第三方厨房也会做一次判断,这个订单接还是不接呢?这是个问题~
我眼中的业务流程是个大局的东西,在思考他的时候也是着眼于整个系统的,你不在是一个用户,因为用户是不必知道后台的一些判断细节或是操作过程的,但如果你是产品经理的话是一定要清楚的。
流程中总是由一个动作展开,那么思考时,我们要对每一步都带着一个“如果……不……”会怎么样的心态,就会发现很多可以做判断的地方。如果支付不成功呢?如果厨房不接单呢?如果退款不成功呢?这样想下去你的流程细节就会越来越完善。
OK,回顾一下,业务流程的重点是:设定角色,跑通流程、用“如果……不……”穷尽判断,思考产品背后的判断逻辑。
沿用这个栗子,说说操作流程。
操作流程,顾名思义,就是用户对产品的一个操作流程,这个流程是为了完成某个任务。比如成功下单,比如登陆注册,比如退款等等。我又很简单的画了下面的图,这就是“用户下单”的操作流程。
他完全是以一个用户的操作角度来写,你也可以去画一下系统后台某种操作流程等等,他并不限于所谓的消费者用户。
在初画操作流程的时候,不要早早的去过分在意细节与逆流程,逆流程便是那些需要判断是否的那个“否”的流程。
第一次我往往都会用最理想的状态,将流程跑通,再去思考这里面会不会有那些“如果……不……”的细节。
最后是页面流程图
他算是比较好理解的了,这个流程我通常会在完成原型图完成后来制作,通常会用Axure来绘制,再加上一些文字上的注解。
业务流程与操作流程都在他之上完成,当建立起来操作流程,页面跳转的流程也就跃然纸上了,只是在做某些交互行为时要多加注意页面之间的逻辑、层级关系,做到跳转不歧义。
比如前几天我一个上了些年纪的亲戚来请教我手机网购的事情,我一步步教他如何选商品、注册、下单、支付,当订单提交后,页面定格在了。“恭喜您,下单成功”页面中,并给了一个查看订单和联系客服的按钮。他问我:“下一步怎么办,我还想买别的”。
这是页面跳转流程的问题呢?或是叫他用户体验,交互问题都可吧。
已经完成购物的用户,真的在那一刻想看“订单详情”吗?还是引导他去买更多的东西?这便是页面跳转引导流程上的思考了。
透过上面的案例,不难看出流程实际上就是“开始,结束,行动,状态与判断”的组合。一切流程都有启示的位置与结束的位置,我们在其中行动(与之交互),有时候一个行动我们需要判断是否要做,做完了又会变成一种什么状态。如此反复,就形成了所谓的流程。
认识了概念,看过了示例,如果你已经跃跃欲试了。

那么我们该用什么来绘制流程呢?

这里我会推荐先用纸和笔来做,先去多体验一下其他竞品的流程,把他们的流程记下来或是烂熟于心,然后在脑中去勾勒出自己产品的流程,逐渐将他们记录在本子上,试着去模拟一个用户在你的产品上使用的流程,当然也要去想后台如果来处理用户的一系列提交数据的动作,完成一整套的产品业务流程。
这可能很庞大,我们可以像做项目一样,将这些庞大的东西,细分打碎,通过完成一个个小模块来最终绘制完成所有的流程。

关于流程的思考

流程电子化只是换了一种形式表达而已,不必刻意去追求软件层面的创新;思考过,并且「想明白了」才是重点。
如果在其中你发现了这个行业的产品,都是这么做的一个流程,那么可以试想“如果都这样,那么他会不会是一个可以优化的机会呢?”
不盲目地确信你眼前看到的事实,不断去反思,自省,质疑,是打磨一款流程简洁、操作简单的产品的法门之一。我们其实都在通往合格的产品路上,共勉吧。
#专栏作家#
辛超,微信公众号:pmnote,人人都是产品经理专栏作家。九樱天下产品经理,关注社区共享经济领域,曾任蓝标集团策划经理,负责运营百万级粉丝微博账号,现转岗产品,擅长产品设计与运营。希望未来自己打造的产品,能让世界变得更好一点点。
本文原创发布于人人都是产品经理,未经许可,不得转载。

PM小技巧——流程图&产品原型

在规划产品功能时,产品经理需要和设计师一起将原本比较抽象的产品需求变得更加具体。一般来说,将抽象的产品需求具体化也可以分解为四个环节:确定产品需求范围、制作流程图、制作产品原型、设计产品视觉DEMO。
关于分析与管理产品需求的文章之前已经写过很多了,而产品DEMO是由专业的UI设计师进行设计展现。
简单地谈一下流程图与产品原型,二者不仅是产品功能需求的具体体现,也是后面进行DEMO设计的基础。
流程图=业务场景+逻辑思维+流程可视化
制作流程图的好处有很多,主要是体现在两个方面:

一是帮助产品经理梳理、完善用户操作流程。

基于流程图,产品经理通过模拟不同用户在不同场景下对流程中每个步骤的具体操作,便可以很方便地对整个流程进行评估,确定流程是否可以保障所有用户都能很好地完成整个任务。
因此,在进行制作流程图之前,我们是需要熟悉相关的业务场景,对用户整个流程的操作了然于胸,这要求产品经理在熟悉业务场景的基础上具备缜密的逻辑思维。

二是有效降低团队成员间的沟通成本。

在实际工作中,产品经理需要向很多人描述产品需求,借助可视化的流程图,沟通的效率会提高很多,毕竟一份步骤清晰的流程图要比一大段文字直观易懂得多。
个人认为,逻辑思维与人际沟通是产品经理最基本也是最重要的素质。之后就是将具体的流程进行可视化展示,这个就比较简单了。
之前去美团面试后端产品时,由于工作岗位涉及到逻辑、流程,面试时要求根据自己入学时的场景,画一张新生入学流程图。
恰巧当时还在研究生会,所以对相关场景还是比较熟悉的,画出来的结果面试官也比较满意。
下面是微博的后台管理系统,用Visio画的,由于时间比较紧张,下一层级模块的操作逻辑就省略了。
制作流程图的工具没有什么特殊的要求,可以用笔直接画在纸上,可以用Photoshop德国画图工具,也可以用专业的流程图制作工具,比如Visio。
无论用什么工具,制作出来的流程图都应该符合一些基本要求,比如直观易懂、布局清晰、逻辑完整、站在用户视角考虑等。
产品原型=用户需求+产品功能优先级+原型制作
在将抽象的产品需求具体化的四个环节中,原型制作是很关键的一个环节,因为它要将大量存在产品经理脑海中的信息转化为可视化图形。
产品原型是用于表达产品功能和内容的示意图。一份完整的产品原型要能够清楚的交代:产品包括哪些功能、内容;产品分为几个页面,功能、内容在界面中如何布局;用户流程的具体交易细节如何设计等。
概括来说,产品原型设计要涵盖三个要素:元素、界面、交互。
对于产品经理来说,通过用户调研、竞品分析确定产品功能需求范围后,制作产品原型有很重要的意义。

有助于完善、优化产品需求方案

在此之前,产品需求还停留在抽象、模糊的概念阶段,属于“空中楼阁”,而制作的原型已经很接近最终的成型产品了,产品经理可以模拟不同的用户场景测试规划好的产品功能,也可以分别以用户、交互设计师、开发工程师的视角审视原型,进而不断地修改产品原型,更好地完善、优化产品需求方案。

方便对产品需求进行评估

一旦产品需求进入开发阶段,再进行需求变更需要付出巨大的代价。相对于产品需求文档,使用产品原型进行需求评估更具有可操作性。
产品需求的评估包括产品价值、产品可用性、产品技术可行性三方面的评估。
产品需求在进入实际设计和开发之前,要进行详细的评估,确保产品功能符合用户的需求,对于用户来说是可用的,并且能够通过技术手段实现。

有效降低与团队成员的沟通成本

产品原型对产品经理的重要性还体现在它能够有效降低与团队成员间的沟通成本。
在实际工作中,产品经理需要向多人描述产品需求,而产品原型最大的优势是能够将产品需求以图像化的方式进行展现,使产品需求一目了然,大幅降低沟通成本。

如何制作产品原型?

毫无疑问,Axure是绝大多数产品经理的首选。