奇趣闻 > 数码科技 > \

产品小白须知:如何用原型体现你的专业度?

原标题:产品小白须知:如何用原型体现你的专业度?

笔者从整体上讲了画原型这件事的要点,以及如何通过画原型体现出产品经理的专业性。

记得面试产品时,面试官曾经提过一个问题:“ 你觉得身为产品经理,你的专业性是如何体现的?

如果只是会画画原型,写写文档,那么你一年和十年的产品经验,其实没什么区别。

后来在工作中,也会经常想起这个问题,会反思“身为产品经理,我该如何体现我的专业性?”也有了一些自己的收获感悟,以后再说。

今天主要是针对产品入门的新人,比如0-1年的产品经理。解决如何尽可能完善地画原型问题,不至于因为疏漏太多被频繁Diss。如果你正好有这个困惑,OK,看这一篇就足够了。

一、比画原型更重要的,是在画之前想清楚要做什么

很多小白刚入门的时候,包括我自己,会特别注重体验,特别是一些细节交互、页面展示,觉得一个好的产品应该是外在完美无瑕,内在赏心悦目。

其实,出现这种情况大概率是这个阶段的产品经理,除了外在体验层,其他的也说不出点什么,比如业务流程、底层逻辑、商业模式这些高大上的内容。

有一个建议,可以帮助小白稍微进阶一步:就是要有意识地让自己变成以目标为导向的产品经理。

不论是负责一个功能模块还是负责一个整体项目,你的每一步行动一定是有很明确清晰的目标驱动,而不是我觉得应该怎么样,我认为这样会更好。

以目标为导向,会让你从细节中抽离出来,更关注整个流程的关键节点,有助于把精力花在关键节点上。宏观角度看问题的产品经理一定比微观角度看的成长更快一些。

再说画原型,不用在意是画上草稿纸还是使用Axure/Sketch/墨刀,找一个你认为顺手的就OK,绝没必要太过于重视。 工具的目的是为了让你提升使用效率,而不是深入的学会使用工具。

因此,在画原型之前,你的脑子里应该很清晰的知道你要画什么,你每一个主页面需要哪些元素,主流程是什么样的,原型只是将你的想法可视化。所以, 产品经理的价值脑中想法是99%,原型呈现是1%。下面我们直接进入画原型阶段。

二、画原型的步骤及检查清单

讲这部分内容之前,有两个想法,产品经理应该早点知晓:

  1. 即便是最牛逼的产品经理,也无法输出滴水不漏的原型。所以,原型在输出时,有所遗漏是再正常不过的事儿了,要接纳它,没必要因为这个而否定自己。这个很重要。
  2. 最终影响一个产品/功能成败的,是你是否打中用户的那个点,是否解决了用户某个问题。所以,多花精力在主流程的关键节点上。只要主流程不频繁发生变更,那剩下的就是些细枝末节的完善。

所以, 画原型,第一步把主流程捋顺画出来,剩下的就是查漏补缺,达到相对完美状态的原型,是专业性体现的第一步。

主流程就不多说了,如果产品小白主流程有问题,那说明基本的业务能力不过关,不是这里可以解惑的。接下来我就重点介绍下从哪几个方面查漏补缺。

1. 页面所有元素,都一一列举,有明确的规则和说明

这是产品设计输出文档时,养成的习惯。一一列举,可以最大化防止漏掉细节内容。特别是对于产品小白,可以用这样的方式开始你的工作之旅。

2. 考虑文本最多展示几行、最大字数极限、超过极限该如何处理

即便是信息化的今天,文字仍然是最核心的呈现内容。因此,只要是文字,就需要考虑文字的行数/字数/极限值处理,如果能形成约定俗成的规范当然更好了。否则测试在这些小问题上追着你不放,就很尴尬了。

3. 页面的每一个元素都要想清楚是否支持动态可配置

考虑到以后的扩展性,每一个功能区域是否动态控制显隐,元素内容是否可灵活配置,文案是否支持动态修改。这些都是在产品设计时需要考虑的。

当然,一般情况下,大家约定俗成的是不可动态配置,因此,需要动态配置的时候,一定要明确标出来。否则做到最后想改动,可就没那么容易了。

4. 考虑可触发区的状态:业务场景不同,状态也会不同

主流程一定是正常状态,但是业务场景不同,状态也不同。比如最基本的可触发、不可触发,还有随着业务进程不同,展示不同的业务状态,这个要想全,作为对主流程的信息补充。

  • 业务状态:行为发生前/行为发生中/行为发生后
  • 数据状态:有数据、无数据
  • 时间状态:未开始/进行中/过期下线
5. 考虑设备、版本、平台三个系统级别的影响

设备:是否要兼容平板电脑、小屏手机,是否存在横竖屏切换。基本就这两个关键点。

版本:这个很重要,因为很多产品小白很容易忽略。在设计的产品是否要兼容老版本用户,如果无法兼容,是否会影响老版本用户的使用。如果需要兼容,当下的设计是否能支持到,是否有强制升级的必要。特别是在做原有功能优化重构的时候,这个问题更需要慎重考虑。

平台:这个考虑多见于H5开发。因为需要用一套代码适用于多个平台,要考虑H5与APP的平台差异性。比如返回方式、分享触发,以及体验的流畅性。

6. 是否有必要新手引导,换一个视角审视功能

对于新用户,是否有必要做引导说明,从而达到了解新功能、快速上手的目的。

7. 让人头疼的网络问题,也是必须考虑因素之一

考虑到 网络慢、网络加载中、加载超时、中断、重新加载、4G与WIFI切换等等一系列情况下出现的场景并设计出合适的解决方案。当然,这个在做过一两次后,一般可以形成一套约定俗成的网络处理方式。像这种全局页面都涉及的规则,单独拎出来会更清晰。

8. 登录状态与用户角色

考虑到业务是否有必要区分登录用户与游客用户,在何时触发登录。业务的用户角色是否存在多样性/阶级性。多样性指平等维度下,不同的角色。比如护士、医生。阶级性,比如普通用户、VIP用户等。

9. 反馈提醒机制是否完善

比如常见的toast反馈提示、二次确认机制等。这个就不赘述了。

10. 是否过度设计,每一个元素是否为必须元素

从用户视角看整体功能,是否页面每一个元素都为必须元素,是否存在为了设计而设计的嫌疑,是否真正做到了MVP,是否可以让整体功能更加极简。

基本上做到上述金十条,你被Diss的概率能降低很多很多,接下来是画完原型之后,会有很多的后遗症。因为,画原型只是第一步,如何让你的原型被更多相关人员所熟悉认可,并且能够按照原型输出你预期的产品效果,才是最关键的一环。

三、画完原型的后遗症,最佳解决方案

需求交付后,就到了产品最常见的一个环节——改需求。

改需求无须避讳,原因很多——或是业务调整,或是自己的疏忽大意,或是大boss的突发奇想,太多了,所以很正常。

而且, 你细品,其实产品被Diss,不能说80%,起码有50%不是因为改需求本身,而是因为改需求的同步或者处理方式。

好吧,这个数据也是拍脑袋定的,关键是如何解决这些后遗症。

以下是几点很实用的建议,源自本人总结的血泪教训:

1. 改动任何一个地方,一定要着眼于全局,充分考虑这个地方对全局带来的影响

这个很重要,特别是需求评审-交底之后,只要有改动,第一时间一定是先考虑影响面。甚至有些影响,需要核心研发人员参与评估。

2. 涉及到后端控制台设计,一定要先和控制台的使用者(大多数是运营人员)沟通,毕竟能直接接触到服务用户

这个可能没有太多的借鉴意义,但是,如果能一步到位,做出运营人员操作流畅的内部配置控制台,本身有助于产品工作效率的提升。

3. 产品没有标准答案,但是也绝不能模棱两可

画完原型后一定有很多不确定的地方,一定要提前确定好——可以从目标导向去考虑,也可以参考竞品。实在不行可以找同事商量,上司敲定。

但是,切忌模棱两可,没有明确的结论。

把结论交给研发、测试去猜、去盲目做,是产品最愚蠢的决定。

产品,是要给用户确定性的。

这个很重要,这里面的用户就包括了和你合作的UI、研发、测试,也是衡量一个人是否靠谱很关键的一个因素。

4. 改动同步给每一个人,是原型输出后优先级最高的事情

当完成需求交底后,就意味着你的原型进入执行阶段。

当执行阶段有改动,比改动本身更重要的是如何同步,否则后期的撕逼无穷无尽,你也会被印上不专业的标签。

而同步的方式,至少要做到当时忘记之后仍可追溯,因此写在原型里/写在说明里/发到群里@相关人员。

放心吧,一定会有人没看到而遗漏。因此,最好的方式就是邮件同步相关人员并在群里提醒。 大家因为改动未同步带来的情绪要比改动本身大很多很多。所以,不需要惧怕被贴上频繁改动需求的标签,而是第一步先确保把同步工作做好。

如果改动影响较小,那当然OK,同步后皆大欢喜。如果改动了主流程相关,一定要及时与研发交涉,以便提前得出对排期的影响。这个对整体进度把控很重要。

5. 产品经理要带些锋芒,学会否定别人的想法

在这个人人都是产品经理横行的时代,如果你按照上述步骤做了自己该做的原型方面的工作,仍然有人各种不满和抱怨,甚至对你的原型内容提出质疑。

不要怕, 产品是质疑成本最低的工作。吐槽质疑再正常不过,如果合理,虚心接纳。如果不合理,直接否定。这个职业,本身要带些锋芒。

END

好了,这篇文章到这里就结束了。回顾产品经理之路,恐怕大多数人花最多精力的就是画原型和跟迭代了。因此,如果是小白,可以读读,提升自己的基本功,不断成长。如果不是,也可以读读,对照自己的日常工作,提升下专业度。

希望这边文章能通过我被Diss的教训,帮大家尽可能减少被Diss的次数。

新年快乐!

本文由 @御风而行 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

显示全文

相关文章