快好知 kuaihz

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

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

产品经理属于接力的第一棒,一旦最开始的方向错了,那么即使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就好了”,开发人员不是产品经理,你才是。

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

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:所思  所思词条  原型  原型词条  所想  所想词条  一些  一些词条  经验  经验词条  
原型

 Axure 组件重写系列(三):...

在学习了本文的中继器表格之后,你将会十分完美地解决原生表格组件覆盖不到的功能区。一起来看。表格应该是我们非常熟悉的一种数据格式了,在实际开发中,它也是作为系统的...(展开)

原型

 用原型写需求文档-后台系统篇

作者整理了一套后台系统原型模板,与各位PM分享,希望给大家的工作带来些帮助。后台系统的原型模板早在做APP模板前就已经使用了很长一段时间。后台原型不需要也不适合...(展开)

原型

 Axure RP 9 教程:记录...

本案例制作一个可拖动的条形进度条,同时可以显示当前位置的百分比。一起来看看~实现效果:自由拖动进度条记录当前进度条的百分比顺便记录下你的颜值实现逻辑this.r...(展开)