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

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

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

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

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

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

今天主要是针对产品入门的新人，比如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协议。