nba在线观看免费回放-官网在线

产品经理流程图设计思路和绘制方法初讲

时间:2020-12-05 11:57

  流程图是产品设计的内涵,是关于任务流程与相关联逻辑关系的设计,是一组将输入转化为输出的互相关联作用的活动。其中包含不可或缺的元素节点有对象、输入、动作、输出。对象就是执行用户。输入可以理解为前提、前置条件。动作就是用户操作,可以是点击、输入、划屏等等。输出可以理解为结果和动作的目的。产品设计中输入和输出的形式并不局限,可以是事件也可以是动作。

  流程图是产品设计的内涵,是关于任务流程与相关联逻辑关系的设计,是一组将输入转化为输出的互相关联作用的活动。其中包含不可或缺的元素节点有对象、输入、动作、输出。对象就是执行用户。输入可以理解为前提、前置条件。动作就是用户操作,可以是点击、输入、划屏等等。输出可以理解为结果和动作的目的。产品设计中输入和输出的形式并不局限,可以是事件也可以是动作。

  在思考输出时不能仅仅考虑用户端的输出结果,同时要思考后台可能产生的比如数据的变化,在相连的环节中,通常上一个环节的输出为下一个环节的输入。因此流程图目的是将流程逻辑表达清楚,即什么对象在什么前置条件下执行了什么操作产生了什么结果。

  流程图的优点包括如果流程准确,那后面的原型,需求文档,评审就容易了。流程图对于你自己,同事和以后接手的人很容易交接。可以让中途参与者快速的进入工作状态。

  流程图的作用包括功能优化,看之前业务流程,找改进点。独立功能设计,看用户操作以及信息的流向。并从这个流程图中分离出比如考核指标、交互设计质量。涉及到复杂的用户和信息交互处理。比如一个平台涉及到发起方、需求方、审核方三个群体,同时还要考虑发布前、发布中和发布后。这种相对独立复杂的功能需要业务流程图去揭示其中复杂的用户和信息交互逻辑。

  因此一个功能需求点设计,必须有流程图参与到逻辑思考当中,否则一定会出问题的。比如下面项目评审会议场景模拟。

  研发:“你知道这个手机号码合法性判断,究竟包含什么判断?你知道一条短信多少钱吗?被投诉怎么办?”

  测试:“验证码的异常,不能只写异常啊,究竟有哪些异常?你这都不写清楚,我怎么做测试用例。”

  产品经理:“要啊要啊,谢谢你啊。”(在测试的鄙视眼神中,你竟然还谢谢人家)

  测试:“谢我做什么?这不是产品应该想明白的事情吗?我是测试,不是产品经理啊。”

  UI:“刚才研发提出了那么多意见,你这个肯定要更改需求,我先不做了,等你确定了吧,省的改来改去,都是无用功。”

  BOSS:“就一个注册功能,翻来覆去几次了?你……”(然后老板黑着脸走了,心里盘算着,还得在招聘个合适的产品经理。)

  以上场景经常出现在刚转行没几年的产品经理工作当中,由于工作和项目经验不足,规划设计的原型,流程不清晰逻辑思维混乱。常会被项目团队其他成员吐槽和责难。因此产品经理在规划设计过程中要用大量的流程图去完善和自我验证逻辑的合理性。

  在项目评审会议中,为了说明一个问题产品经理也需要抛出各种流程图解答团队其他成员有疑问的地方。包括业务流程图,任务流程图以及页面流程图。通过这些流程图把原型所包含的流程和逻辑关系给清楚明白无歧义的表达给我们的项目团队每一位成员。

  一般涉及多个主题,比如电商涉及到买家、买家、仓促、物流,购物前,购物后等。会把不同模块放在各个泳道中辅以带箭头的线去跨泳道指出逻辑关系,侧重开发团队沟通架构。

  假设领导给你一个任务“让你一封信送过去给vicky,让她去会议室找总经理转交给他,如果总经理不在会议室,就拿回来还我”。

  首先拆分下四个关键要素事项、角色、信息、异常。事项指送信整个这个任务,角色指BOSS、你、vicky和总经理,信息就是信件,异常指如果总经理人不在怎么办。

  接到任务我们首先分解出主线。BOSS→你(附带信息“信”)→vicky→(附带信息“信”)问总经理在不在→在→把信交给总经理→流程结束。

  主线完成后我们要考虑异常情况,即副线如果总经理不在流程怎么流转。问总经理在不在→不在→把信拿回来→BOSS→流程结束。

  因此任务流程图的规划包含1、明确角色与任务,2、明确开始于结束节点,3、明确流转顺序,4、定位出全部异常情况,5、不同情况下的结束节点,比如上面例子任务完成信息传递结束点是总经理,但是另一种情况任务流程完成信息传递结束点却是BOSS,6、最后优化调整,做到流程简便快捷。流程图绘制完成,要先自我审查校验流程图是否合理逻辑是否清晰。

  三问自己是不是优化调整到最极致。流程图的规划设计一定是先繁后简,先想最全的然后在逐步优化,做到流程即简单便捷又完整。

  研发、测试关注点:信息流向,异常判断。UI、UE关注点:界面、字段、动作。

  画好流程图先从临摹,从最简单的登录注册开始。正所谓山水临百遍其形在心间。一定要和技术多交流,只有技术能给你指出很多你想不到难点。

  举个登录实例,这个功能为了让用户登录,因为现实情况任何互联网产品只有登录了用户才能获得更多的使用权限。

  任何流程都有主线和副线之分。主线指用户在没有犯错的情况下从头至尾的走完流程。副线是指用户犯错后或者叫遇到异常情况后引导用户走完整个流程的线路流程。

  首先我们要基于用户场景去思考操作主线。用户触发开始机制→输入账号和密码→成功→登陆页面。

  副线我们要尽可能的考虑异常情况,并且思考异常情况出现情况下的解决方案。解决的原则是能系统解决的问题绝不能麻烦用户,必须用户介入才能解决的尽可能减少步骤。

  解决方案:如果电话号码位数错误,前端直接判断,并给出提示。如果不是后台提示。最佳方案是不是可以系统自动记录用户的账号。

  解决方案:考虑用户场景最佳方案是,用用户正在使用的手机注册或者直接第三方社交软件登录。但他会牵涉到另一个问题,如果用户原账户有资金或购买的服务怎么办?所以这样考虑也不是最佳,最好能设计快速找回密码流程。

  解决方案:考虑用户场景是正在使用手机,所以最佳方案是短信验证码,然后用户重新设置密码。

  把能想到的所有周边异常情况在草稿上画一画考虑完整后开始用Visio绘制流程。

  通过这个案例我看流程中1、事项:所要包含的信息,即要完成的事情是什么。2、角色:单泳道任务流程图基本上就只有一个用户的操作流程即什么样的用户会走完这套流程。3、信息:指用户操作过程中产生的数据信息怎么流转。4、异常:出了异常问题该怎么处理(容错率)。在这个登录例子中事项指用户登录。这个图仅标识出用户单个层面完成的任务的流程所以也是任务流程图。他的信息层面是指用户输入的账号和密码,异常是指用户忘记密码之后怎么帮助用户找回或者重置密码。图画到这里就可以清楚明白的交代用户登录的逻辑以及出现问题后纠错逻辑。在实际工作中我们就可以用这个图加上原型去和技术开发沟通具体的开发工作了。

  这个图从用户角度讲是完成的,但是从业务角度讲还不完整。他只是反映了用户这个层面的操作逻辑,但不能反映整个业务逻辑。比如用户输入完账号和密码,后台肯定要验证对错,需要验证是电话号码对不对,不对怎么办?电话对了,密码不对怎么办?再比如用户重新修改完密码后台数据库肯定也要同步更新。这样用户在“我”里面看到的一定是最新的密码。

  因此在实际工作中,如果产品经理和技术沟通的是整个业务逻辑层面工作就必须绘制业务流程图。把前台和后台的关联逻辑都给交代清楚了。

  在这个登录业务流程图里,就清楚的涵盖了前后端业务逻辑。他指出了数据库需要匹配用户电话号码和密码,如果没有匹配上需要用户重新输入。也指出了用户重置密码的逻辑。需要验证手机号并发送验证码,用户需要填写验证码才能重置密码,重置后数据库里更新为最新的密码,然后用户就可以再次用新密码来完成登录。所以如果我们和技术沟通的是整个登录业务逻辑,就不能仅仅用任务流程图,要把反映整个业务逻辑的业务流程图给绘制出来。

  一个复杂业务需求不仅仅对应一个功能点,他是由多个功能组成的,举个例子订餐APP例子,业务需求用户下单,那功能需求就包括用户角色“选菜品”、“付款”、“下单”,商家角色包括“核验订单”、“配餐”,物流角色包括“接单”、“送餐”,用户角色“收到”完成流程,此外后台还要有账户生成与信息记录的功能等。

  可见一个业务需求通常涵盖多个功能需求,涉及前端展示和后台记录等多个部分,所以业务流程图通常复杂详细,尽量能够涵盖各种异常情况,每种异常情况都有相应的前、后台流程逻辑方案。因此首先要搞清复杂业务在产品线各个阶段和功能模块间的流转。