Record

区块链记录你的初心
营销地产创业创新求职面试Word技巧金融职场工作区块链Excel教程财经PPT教程产品运营
产品设计流程系列:业务流程和流程图介绍

产品设计流程系列:业务流程和流程图介绍

设计产品流程

产品设计流程系列:业务流程和流程图介绍 也许我们经常会碰到这么一副画面:很多产品经理在梳理好了产品架构的脑图之后,都会火急火燎打开原型设计工具Axure,开始进行原型设计工作去了。三下五除二就基本将产品线框图给画完了,然后就屁颠屁颠地跑去和研发工程师过需求,讨论的时候会发现:不是这里有个小问题,就是那里有个逻辑没想明白,整理整理返工,结果下一次又发现有一个流程没有考虑清楚,这样来回反复几次才能将一个产品需求和原型界面给讨论清楚。 其实,这样的场景出现的频率还比较高。想想自己第一次去和公司开发沟通的时候,也是碰到了这样的情况,被开发喷这里逻辑不对,那里漏了一种分支情况的思考,当时那个囧啊,真想找个地缝钻进去。后来才知道,在设计原型之前,其实还少了一个关键的步骤,那就是确定产品的业务流程,梳理产品的流程图。 什么是流程图 从字面来理解,流程图=流程+图。流程,是指特定主体为了满足特定需求而进行的有特定逻辑关系的一系列操作过程;而图呢,就是将这些流程进行显性化和书面化的一种表达。 流程图有时也称作输入-输出图,某种程度上来说,流程图是一种沟通性质的图形化语言。一般会使用一些标准符号代表某些类型的动作,如判断用菱形框表示,具体的操作行为、活动用方框表示,开始和结束用圆角矩形框表示。 但比这些符号规定更重要的,是必须清楚地描述产品业务流程的顺序及使用逻辑。从产品经理的角度来理解,流程图其实就是一个用户使用产品的过程,基本的三要素是“从哪进—做什么—从哪走”。比如用户打开一个电商APP,会有这样一个使用产品的过程: 「搜索商品」→「查看商品详情页」→「加入购物车」→「生成订单」→「开始支付」,以及支付之后的「确认收货」 用户从电商商城的首页进入,通过搜索来找到自己想要购买的商品,了解后将其加入购物车,购买了自己想要的商品,支付结束后便离开APP,待收到商品后又回到APP进行确认收货。 可以看出,只要产品用户在使用我们产品的过程中有其自身的目标和任务,产品流程就会存在。产品经理要做的,就是通过一系列步骤完成任务和流程的梳理,最终目的是帮助用户,完成核心任务。 而且制作产品流程图不仅可以帮助产品经理梳理、完善用户操作使用流程,还能有效降低团队成员间的沟通成本。在实际的工作中,产品经理需要向很多人(尤其是开发人员)描述产品需求和原型界面,借助可视化的流程图,沟通的效率会提高很多,毕竟一份步骤清晰的流程图要比一大段文字直观易懂得多。 常见的流程图分类有两种,一种是业务流程图(Transaction Flow), 一种是页面流程图(Page Flow)。 对于产品经理来说,用的比较多的自然是业务流程图,页面流程图一般是设计师那边使用比较频繁。在工作中,我们经常能够看到两种业务流程图,一种是单纯的用户操作行为流程图,这种流程图往往只涉及一种用户角色,不需要进行跨部门或者跨功能完成某项任务,如下图所示: 另一种则很好区分,俗称为“泳道图”,在样子上也挺像游泳池里的泳道,可以有横向的泳道,也会有纵向的泳道。泳道图在某些文档里会被称为“以活动为单位的流程图”,浮在泳道中的都是一个个活动。泳道图是处理多角色、多系统、多模块的复杂需求的最好方法,它的本质就是希望可以通过角色、系统、模块的划分将复杂的功能梳理切割清晰,因此多模块之间的关联尽可能单一,实际中也很少存在多联系线条的情况,因此如果泳道之间多条关联,最好自己反思下是不是之前的功能模块架构切割的不太合理,导致绘制出来的图不够简洁。 如何确定产品流程 讲完了基础的东西,接下来我们来梳理下,该如何确定产品的流程。 首先我们要设计的是产品的核心功能流程,也就是用户的核心使用路径。拿微博进行举例,微博用户的核心操作路径是这样的: 路径一:登录微博——查看微博动态--转发、点赞、评论微博 路径二:登录微博--发表自
解决复杂思考之流程图:如何规范并描绘易于理解的流程图?

解决复杂思考之流程图:如何规范并描绘易于理解的流程图?

流程

解决复杂思考之流程图:如何规范并描绘易于理解的流程图? 一、背景 最近负责公司流程再造这个项目,这个项目的背景是:为了跟上公司业务的发展,要将公司已有内部系统中的业务流程功能全部梳理和重构,解决大部分历史遗留的混乱问题并增强扩展性。系统由两个ERP系统和一个CRM系统及一些独立工具构成,包含销售、运营、市场、财务、人事、客户管理等模块。 在推进工作的过程中,不断的遭遇了大量问题并努力解决,这次主要聊一个由于系统的复杂性,影响概念设计及沟通交流的问题。由于系统本身既庞大又结构复杂,且设计时需要协调沟通极多的的部门负责人与项目干系人配合,而他们对于软件工程或组织系统的认识水平又参差不齐,就导致很难在统一的概念上进行沟通,尤其是在业务层面到开发层面的鸿沟,着实给我造成了许多困惑。 二、问题分析 仔细细考后,基于易理解性和工作流合理性提出以下几点假设原因: 与业务部门来说,更多的关注从自己视点出发的内容,甚至可能完全忽视与自己工作相关的其他部门工作流程。例如,销售人员可能根本不在意财务人员怎么审核资金到账,而只在乎完成签约销售立刻获取自己的业绩。而于此相反,财务人员就更关注,资金到账的信息一定要自己牢牢匹配确认以致牺牲时间的延迟。 抽象的概念图表达方式并不容易被所有人理解。这些图抽象的能力让我们在设计上得心应手,却让一些没经过训练的非专业人员难以接受。 业务概念与系统概念的严重脱节。例如在现实业务流程中需要业务管理人员审核的过程,在系统内部的概念却是客服审核。类似的许多功能与概念极度脱节,以至于业务人员也仅熟悉常用的小部分功能。 我自己对于系统复杂程度的低估,没能完全穷举出系统内的所有相关流程。接手这种唯一的文档就是代码,又遍布历史遗留问题的复杂系统,真的就差把自己埋坑里了。 而其中第一点问题从解决真实问题的角度适合引入系统论思考,第三点问题则正是项目立项之初就明确需要解决的问题,第四点就只剩降低我的自我效能感这一个用处了。 于是这篇文章将主要从第二点问题出发,同时引入第一点问题的影响因素,记录我的思考、逻辑及解决方案。也就是,如何规范设计流程并描绘让各部分干系人都更易理解的表达。 (这里不聊为什么选择用图的形式表达,我认为信息可视化是在制作难度和可理解性中最平衡的沟通方式。) 三、问题研究 1、图的类型 先来熟悉一下惯用的几种作图方式,流程图、泳道图、时序图、用例图、原型图,不过下文的图并没有按照严谨的UML方式作图(现在连开发都不用严格的UML了吧?),仅作参考使用。好,开始一个个分析优缺点,仔细研究问题。 流程图 优点:逻辑、概念清晰,且很容易做颗粒度把控。 缺点:更多表达系统的行为,较为忽视人