经验分享|在设计原型时,我的一些所思所想

零基础学产品,BAT产品总监带,2天线下集训+1年在线课程,全面掌握优秀产品经理必备技能。了解详情

最近参与一个项目,在前期的讨论与规划中算是一个比较复杂的项目,当我把功能拆分开,定下第一期的要做什么的时候,却发现已经没有什么难度了。不经怀疑这段时间自己到底干了些什么……是不是又打酱油了?于是,在这里简单罗列一下自己在设计原型时候的一些所思所想。本文适读对象:初级产品经理。

产品经理属于接力的第一棒,一旦最开始的方向错了,那么即使UI做的有多出色,开发有多顺畅,结果终归是失败的。这大概是产品经理这个职位的第一重压力,在你的设计之后跟随着是UI、开发、测试多个部门,期间消耗的可不是你一个人的人月。

所以,在接到一个需求任务时,首先要做的不是打开axure 吭哧吭哧的开始画图。

第一:明确需求

要搞清楚需求的提出者是谁?服务对象又是谁?

搞清楚这两个角色,主要的目前就是搞清楚这个需求到底要怎么做。

提出需求的角色会有很多,boss、自己、产品同事、运营、客服……

不同的角色往往会从自身的角度去考虑并提出需求。想要完美解决这个需求,就需要站在同一个角度去看问题,若是角度错了,设计方案也就偏了。

不同行业的需求满足的对象也是不同的,to b、to c、to vc……

  • 若是对内部人员,就需要优先考虑好内部的操作逻辑,提高使用效率,必要时还需要考虑各种权限控制。至于界面样式是否好看,并不是一个重点。
  • 若是对外的用户,那么操作流程、交互体验、不同状态下的信息反馈,这些都是需要考虑的。
  • 若是金融行业,还需考虑营造安全感、风险控制等等。

了解需求的紧迫程度

在接手需求时必须要提前了解好时间节点、紧迫程度,毕竟功能开发不是你一个人的事情。要是时间紧迫,而你又把功能设计的超级复杂,害的开发、测试需要长时间的通宵加班,这锅可就得你背着了。

举个栗子:运营MM想要蹭热点做活动,给你提了一个活动需求。时间紧迫,热点又不等人,这该怎么办?

原型设计、UI出图、前后端开发、联调、测试……一个功能开发需要经过这么多环节,除开前后端开发还可能并行开发外,其他环节基本都是线性进行的,任何一个环节失误都会导致整个项目的延期。

所以,在项目前期我们就应该对这些资源的调用、风险的预期,有个大概的认知。倘若加班加点的赶工,最后还是没在这个时间点上完工,这就比较尴尬了。浪费了大家的时间不说,也很打击士气,降低你的影响力。

既然时间这么紧迫,风险这么大,干脆不做好了?

当然可以,这也算是为开发的兄弟们争取到了喘息的机会。这种情况一般在讨论过程中就推掉了,开发人员可能都感觉不到到你做出的贡献。而你,则成功的在运营眼里打上了“不配合”的标签,再也没有运营MM会来找你聊天啦……

那么,究竟该如何做?

我想大家平时都会被叫做产品经理、产品,而不会被叫成“画原型的”,就是因为我们不仅仅画原型啊。产品经理不是画原型的,不是需求的传递者,而是需求的解决者,功能设计、原型方案仅仅只是解决需求的一种方式而已。

活动本身有没有简化的空间?现有的功能里面有没有可以利用的地方?是不是可以采用第三方去实现?若是需求本身没有问题,那么它就应该有解决的办法。

第二:流程设计

先把流程理清楚再去设计原型,这一点应该算是一种共识了,也就不在这边赘述了。就来简单说一说流程设计的好处都有啥:

1、拆解需求,整理思路

接到一个需求之后云里雾里的无从下手怎么办?画脑图、画流程图呗,一般产品岗都会要求掌握visio、脑图这些工具,这些可不是用来凑数的。

梳理流程,将复杂需求拆分成子需求,将子需求拆分成功能点。拆分完成,思路也就清晰了,也许连原型的设计方案都已经有大半个腹稿了。

2、优化流程,减少不必要的返工

我们最开始的想法往往不是最优的解决办法,最优解总是需要经过多次思考、辩证之后才形成。若是什么都没理清楚,就草率画原型的话,等自己想明白了可就得返工重新画了。

所以,比起后续重新花费精力去返工画原型,还不如前期多思考、多画画流程。

3、直观,容易表述

现在也有很多原型图通过连线来表明跳转流程。这种方式在逻辑不复杂的功能上使用还可以,能够直接看的懂。若是功能复杂一点,线条多了,自己都不一定搞得清哪跟哪。

流程图可以作为一个大纲,不至于讲着讲着就把话题带偏了,表述的逻辑也相对会清晰些。在需求评审中,先将整体流程讲明白,可以流畅的引出详细的功能说明,也有助于开发人员理解整体项目。

就个人的习惯来说,与设计原型相比,前期的准备、流程的设计往往需要花费更多的时间。(PS:也可能是拖延症的错觉)

第三:原型文档

原型、文档这两部分就不刻意拆开了写了,这两者的边界已经变的有些模糊。目前很多PRD文档都在用axure进行编写,而axure8更是自带了一个便签的控件,用于在原型上添加说明描述。

关于原型绘制工具

目前我接触的原型主要是通过axure、墨刀去设计的,当然也有使用sketch去画,更有甚者是直接在excel上画的。只要能将一个需求表述清楚,就算是画在白板上也是可以。

是否需要高保真原型?

曾经有人问我axure里面轮播图的效果怎么实现?

说来惭愧,虽然我一直用axure画原型,但是对axure里面的功能却是只学了点皮毛。诸如中继器之类的,甚至连玩都没玩过。于是,先问了一句:“这个制作了是给谁看的?”

在我看来,原型的使用对象有两种:boss、开发人员。若是给boss用来宣讲等用途的,无可厚非,原型当然是越精致越好。而我们接触较多的一般都是开发人员,他们更多关心的是如何实现、而不是盯着原型看动态效果……如何快速的制作、如何将功能说明清楚才是其中的关键。

所以轮播图怎么实现?做再多动画效果,远不如将这一块注明成轮播图,并写明轮播频率、方向。

如何写文档?

我一直把产品文档当做是迷你的产品在做。文档的主要目的是将一个需求拆解成实际可开发的东西,它的需求就是能够让开发清楚的知道该做什么。

写文档其实没有什么固定的规范,几乎每家公司都会有自己的一套模板,只要能够让开发人员看的明白就是优秀的文档。现在网络上可以找到很多的文档模板,已经提供了丰富的大纲和编写思路,剩下的就是根据公司的实际情况和流程去做些调整。

下文为我在编写文档过程中的一些简单归纳:

  • 文档中的用词、描述应该统一口径,并使用专业名称。
  • 文字描述应该简洁,不要有冗余的对话。
  • 一段描述最好只用来说明一个功能点。
  • 通过编号等形式,使文档有条理,不容易遗漏一些规则。
  • 做好版本管理,及时增加修改记录,保留历史版本。

完成文档之后,可以时常接受一些开发人员的反馈,进一步完善编写方法,毕竟这个迷你产品的服务对象就是这些开发人员。

你是否已经想明白了?

心理学里面有一种叫——墨菲定律,放在这里大概意思就是:自己没有想明白的地方,最后一定会出问题。

仅管我们画了原型图,但这也许只是这个功能的冰山一角,判断条件是什么、数据怎么处理、异常状态怎么提示……完整的功能远没页面上显示的那么简单。

很大程度上,原型并不是独创出来的,而是多个app样式拼凑出来的。在拼凑页面的同时,就需要考虑对方为什么要这么做?内部有怎样的操作逻辑?把这些想明白了,才能在评审、开发过程中对答如流,真正实现你想要的功能。

切记不要说:“参考XXX app就好了”,开发人员不是产品经理,你才是。

以上,是一个野生产品经理对于原型的一些不成熟的想法,若有不正确的地方,还望指正。

 

本文由 @诃息 原创发布于人人都是产品经理。未经许可,禁止转载。

祝给予赞赏的伙伴,2017年发大财!
6人打赏

评论( 1

写下你的想法
  1. 写的通俗易懂,就是错别字太多。请谅解

    回复

推荐阅读