流程图|4个原则，带你写出被程序员夸赞的产品原型

在产品工作中，原型算是接触最频繁的文档之一。是否能画出能被大家理解的原型，是一个产品经理的基本标准之一。那么问题来了：如果要画出沟通更高效，还能让程序员测试大佬称赞的原型，怎么做？

文章插图
最近在审核团队其他产品经理交付的原型方案时总是发现不少产品同学对一个原型应该写什么、应该怎么写并没有一个清晰的定义和标准；这也导致了在研发过程中总是避免不了被开发吐槽：“我就是按照原型做的”—但因为原型本身没有定义清楚对应的功能说明导致最终上线的内容并不是产品经理原本想要的效果。
为了规范产品同学的原型制作规范，我整理了4大原型制作原则，只要根据这些原则来填充原型内容，保证写出让开发在内心默默赞许“牛逼”的原型方案。
一、关于产品原型本身的分析在介绍产品原型的设计原则之前，先让我来分析一下原型这个产品本身。按照需求分析的公式拆解，一个完整的需求是由目标用户、使用场景和用户在该场景下想要完成的目标构成的，那么产品原型这个需求就包含了这样几个使用情景：
1. 弱使用场景a、产品经理接到运营的需求后给出对应的解决方案，并用原型的形式向运营确定这种解决方案是否能达到运营的设想；
b、完成整体的产品方案后，向上级领导进行汇报，确认领导们是否认可整体的方案设计思路或细节。
2. 强使用场景a、产品经理在需求宣讲会上以产品原型为依据，对开发、测试、设计人员进行需求宣讲，以便所有项目内成员对需求有大体上的了解；
b、开发、测试、设计人员在需求宣讲后依据产品原型对工作量进行拆分并安排工作任务，以便所有项目成员能准确的评估项目完成时间进行科学的工作划分；
c、开发人员在实现过程中，以原型为依据进行技术开发，以便最终上线交付的内容是符合项目整体目标的高质量产品。

文章插图
由此可以看出：一份产品原型最主要的使用者，就是配合产品经理一起完成上线目标的研发同学们；而一旦因为产品经理在最初的产品原型设计阶段出现了漏写、错写或想不清楚该怎么做导致频繁的需求变更，就会拉长整个团队的工期，也会在研发同学心目中留下“不专业”的负面印象。
二、撰写产品原型的4大原则遵守以下原则来撰写你的产品原型，一定可以帮助你避免因为原型写的不规范而被程序员（当然也包含其他阅读产品原型的其他人）吐槽的尴尬。

文章插图
1. 边界清晰性原则所谓边界清晰是指让当前阅读这份产品原型的人能清楚的意识到，哪些是本次研发项目的内容。这个原则看似简单，但在实际的工作场景中经常会出现因为边界定义不清而导致的分工不明确，任务拆分不清晰。

若一个产品是已经上线过的产品，那么此后的产品需求基本上是在已经上线的基础上进行迭代优化 —-在已有产品上做改动时，需清晰的标注哪些是新增点、哪些是修改点、哪些是原有不修改的部分；
若产品包含多边用户时需准确的说明当前产品的用户是谁，不同的用户对于的操作权限是否有区分；
在进行移动端产品设计时，需明确标注每个板块的开发方式是原生还是H5

2. 内容完整性原则一个完整的产品原型至少要包含哪些内容呢？
一般日常迭代的小型需求至少需要包含的内容有：

背景说明 – 让所有的项目参与者明白为什么要做这个需求，这个需求是想要实现怎样的目标？
需求清单 – 需求包含哪些内容？
流程图 – 需求通过怎样的方式闭环？
功能界面 – 具体的需求是怎样的？
需求标注 – 要怎样实现需求的效果？

【 流程图|4个原则，带你写出被程序员夸赞的产品原型】项目型的原型中还需要包含该项目的顶层设计和版本规划，便于让所有项目参与参与者知晓整个项目的发展全貌和达成路径，对齐整体的思想高度；
当不得不对需求进行内容变更的时候，需要加上修改记录。
1）背景说明
最简单的方法就是套用5W1H原则交代需求背景

Who：谁我们的用户？产品或功能为谁设计？
What：用户可以用这个产品或功能能做什么？产品或功能为用户解决什么问题？