画原型前要了解的产品套路(三)- 任务与流程
画原型前要了解的产品套路(一)
画原型前要了解的产品套路(二)- 用户画像
画原型前要了解的产品套路(三)- 任务与流程
画原型前要了解的产品套路(四)- 细枝末节
画原型前要了解的产品套路(五)- 面向开发的原型
你有没有遇到过这样的情况,需求方说,我要做一个微信一样的产品、我要做一个美团一样的产品、我要做一个××一样的产品!这个时候,作为一个产品经理,内心往往是崩溃的。
做一款产品,说一个功能类似的竞品能让你大致了解需求的模糊模样,但是真正的着手点不是先去研究竞品怎么做的,而是好好调研这个产品的目标用户的任务和流程。
对任务和流程的梳理,就是帮助我们接上“需求”和“创意”之间的那条逻辑线。然后我们再着手把一个想法拓展成一个产品、一个平台、一个系统。
试想,如果做微信的时候产品经理想的是做一个QQ一样的产品,那就没有今天定位不同于QQ的微信。所以,在制作产品的细节之前,尽量不要参考同类的产品界面设计。
以下,我们以做一款在线会议软件为例来说明。
拆分任务
任务与流程,即什么任务,在什么地点,使用什么工具,完成什么任务。通过一系列步骤完成热舞和流程的梳理,最终目的是帮助用户,完成核心任务。
每个人都有TA自己的方法去完成一件事情,通常我们会把这件事拆分为一系列按照时间顺序排序的小任务,然后依次执行,即拆分任务。
首先,明确角色。梳理在整个任务流程中涉及的角色,每个角色承担了哪些任务,然后用时间轴的方式,将角色与任务串联成一个完整的任务流程,这样整个流程完成,谁在什么时间做什么事就一目了然了。
注意,这里梳理的是从组织到结束的“会议”流程,而不仅仅是“开会”的任务流程,因为只有跳出来将会议这个需求设计到的所有环节都梳理清楚,看到每一条和用户相关的道路,才能方便我们之后围绕“开会”这一核心任务,搞清楚前后逻辑关系,知道不同用户角色产生某些行为的前因后果,也更能帮助我们发现不一样的机会点。
(PS:插播点自己的经历,之前有做过一个后台的权限申请、开通需求,其中涉及到用户的管理员、权限审核开通人、财务人员等,刚梳理的时候一脸懵逼,怎么整都是乱的,功能之间出现交叉,权限设置混乱,后来经大神指点,采用了角色、任务、流程的方法进行梳理,整个需求就非常清晰了,设计方案自然而然就出来了。)
任务和流程梳理清楚后,还有一个要做的工作,那就是问自己“这个环节是否是必要的,可不可以删除,会影响用户完成任务吗?”这样反复的推敲,最后得到一个最精简的任务流程。
我并不是想说非要去掉什么,而是希望你形成“我们还能删除什么”,而不是“我们还能添加什么”的思维方式。
任务精简之后,检查任务的先后顺序,或者合并某些任务,以便任务流程在时间上更优,不会出现浪费的时间空挡,或用户在执行任务过程中的无谓的等待某一个流程结束才能继续。
以会议软件为例,梳理清楚了线下开会的流程,接下来就是产品替换某角色,比如会议软件替换场地、显示器等资源;系统替换人工,比如系统自动记录会议录像、自动联络相关用户参会等。
串联事件画面
通过上面说的任务拆分和流程梳理,我们的到来了产品的核心流程,作为一款app,我们需要不同的界面承载这个流程的各个环节,这个时候我们就开始基于各环节制作相应的app界面原型,将这些做好的界面按照任务流程顺序排列,一个app的框骨架基本上就有了。
在这一阶段,可以邀请用户进行一次可用性测试,来验证这个流程是否流畅,如果你出了几套方案都可以实现这个流程,那么不妨多跟用户探讨一下哪种方式更好。
决策时,请选择平庸的方案。
这里所说的平庸,是指对用户而言操作成本低,易于理解的设计方案,这种方案一般采用的是常见的典型操作,并且具有高度的扩展性,而不是一些看起来很巧妙、很酷,但是并不“实用”的功能。这让我想起了那本大家都知道的书《Dont't make me think》。
通过上面的步骤,我们这一阶段产出了一个低保真原型。这个原型我们还可以拿去和开发、运营做一下评审,避免逻辑上的漏洞和运营工作上可能需要提前准备的一些支持。
最后,强调两个思考方式:
1、关注核心任务流程。
2、做减法,多去考虑“如果没有这个环节行吗?”
以上,来自Gara《绝密原型档案》的读书笔记,欢迎留言交流。
文/烤鱼吃辣椒
关键字:产品经理, 流程
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!