如何做好原型图和prd

相信做产品的对原型图和prd都是再熟悉不过的了，虽然说这两个“技能”不能说是做产品中最重饥敏要的两项，但是一定是做的最多的两项之一。这两点虽然非常基础，但是也不是那么容易做好的。来到公司之前我自己做过两个产品的prd和原型图，第一次是在学校团队做的社交软件。那时候写prd的时候没有模板，竟然也没有想过去找一个模板参考一下，当时就凭着感觉自己摸索了一套逻辑先写着，然后给团队里的研发小伙伴看，他们说能看懂我表达的意思就是OK的。那时候的原型图更是简陋，直接用墨刀整了个“草图”，虽说是草图，但是基本上整个风格和UI的图都是我找的，然后就直接用上了。后来去公司实习了，公司规模不大，prd有一个模板参考，但是不是很详细，我硬是把自己觉得更详细的prd（就是我自己摸索出来的那一套，现在看来就是“根本不能用！”）给带我的人看，可能他也觉得我写的比公司的详细，于是让我比对着公司的模板加入了自己的想法。当时我去之前是一个程序员画了原型草图，大家可想而知，那效果！然后我就在程序员面前摆弄了一番墨刀原型，在他眼里，我画的可美了（说明一下，那个部门第一次做APP，所以当时只有程序员，还没有产品）。就这样，自我感觉原型和prd做的还不错的我就来到了现在的公司.......整天被师父说“prd写的不全面，加，加，加！！！！”“原型图画的太丑了，改，改，改！！！”在此，我还是非常感谢师父的高要求，让我学到了不少（刚刚还在喷我文章写的，啧啧啧）。那接下来就来说说自己学到的如何写好prd和画好原型图。

Prd篇

一份完整的prd要做到全面：除了让程序员，UI和UE能完全看懂要做什么，要怎么做（逻辑要非常清晰），还得考烂卜枝虑到和产品，功能相关的所有边缘情况。说的通俗一点，就是让人在能找到所有与需求相关的东西的情况下还找不到任何可以拉出来扯皮的。因为产品狗要对自己的产品负责，你不做好就等着背锅吧。

一，首先从整体来看，要按功能模块来写。我以前自己摸索的是按页面来写，就是先描述这个页面是什么，有什么，有哪些控件，用户场景的使用流程是什么。一直以来我都觉得自己描述的又有逻辑又详细，一来就直接被师父否了。然而我弊冲并不是那么容易妥协的人，我得知道为啥我的逻辑有问题，你的好在哪。于是师父拿出了他经常说的“你居然敢质疑我！”说完之后就开始详细解释了：按照页面来写，如果不同页面功能有重合怎么办；其次按功能写是一个逻辑流，如果按页面来就会漏掉一些关键点，因为它没有一条清晰的线；最后很多控件不是我们设计的，是UE设计的，我们只需要把逻辑说清楚，不要抢别人活。好吧，我觉得说的很有道理，但是打翻自己的逻辑重新树立一套逻辑还是不容易的，所以当时琢磨了好久才能按照师父教我的逻辑梳理文档。

二，从细节来看，主要记录三个重要的方面

1，需求说明/修改：说明为什么做/修改这个功能。最开始写这部分的时候我很容易就写成了这是什么功能，为了让用户怎样怎样。后来在师父的点拨下才了解到是站在公司产品的角度上写为什么要做。知道为什么吗？因为程序员总是质疑产品，这个功能为什么做，意义是什么。（潜台词是：能不做就不做吧，我们事多着呢）

例子：当前防蹭网功能只能对已经连接过路由的设备进行“加入黑名单”的 *** 作，并不能对尝试攻击网络的设备进行真正的预防。

2，功能描述：说明用户可以做什么 *** 作以及可以看到哪些内容

例子：

（1）进入到防蹭网的已连接页面可以查看已连接设备的信息：①设备名称，②接入时间，③接入网络类型，④接入次数，⑤总陌生设备数和总接入次数

（2）点击对应设备进入详情页面；

a.可以查看信息：①设备使用历史流量曲线图，②设备上下线时间，③设备使用总流量，④设备总连接时长。

b.可以进行的 *** 作：①标记为家庭设备，②加入黑名单。

（3）进入黑名单列表，可以查看/移除已被加入黑名单的设备。

3，约束性描述：说明整个功能描述里面相关的规则，主要有显示规则，字段规则，防呆规则。这部分相对来说比较难，因为很多点都不容易想到。除了这些，还有很重要的：异常情况怎么处理，极值是怎样的，显示内容及其格式应该是怎样的。

例子：

1.设备列表显示规则：

a.已连接的设备列表为已连接的陌生设备，即不包括本机和家庭设备。

b.可显示/编辑在线设备和离线设备。

c.列表页最多有50台设备，当设备数超过50台以后，按时间顺序自动删除。

d.当前无陌生设备接入时显示：无陌生设备接入网络。

2.设备列表字段规则：

a接入次数：每次下线后再上线连接为1次。

b.接入次数超过99次显示为99+。

3.总陌生设备数和总接入次数：

a.按接入设备和设备接入次数的总和计算。

b.接入设备最多为50台，接入次数超过99次显示为99+

在开始写的时候很容易犯的错是将功能描述和约束条件弄混淆，但是弄清楚功能描述主要是站在用户的角度写的，约束条件站在开发的角度写的，多写几次修改修改就会好很多。

原型图篇

关于原型图其实能说的不多，因为每个人的审美不同，但是有些细节需要提一下。

1，这个也要根据公司的情况而定，比如公司有UI和UE的就不用特别注意美观，重点就应该放在重要的元素，完整度，逻辑清晰。反倒应该以简洁的界面为主（不要加入自己的设计想法，会误导别人的）。因为这时候我们的“用户”是UI，UE和开发，让他们理解有什么元素，怎样看的清楚最重要。如果在公司没有UI和UE的情况下，就需要注意界面的美观和交互了。

2，细节，比如去掉Axure里面那些控件的边框，对齐，颜色统一。

3，标注，prd里面很多重要的约束条件标注在对应的页面会更方便程序员开发。

4，没有时间就不要做酷炫的交互了，因为没用，没人看。甚至可以不用做交互，只需要有逻辑的把页面画全就好了。

其实不同的公司有不同的架构，所以对需求文档和原型图的要求是不同的，不过不管要求如何，都一定想清楚自己写文档的逻辑。还有逻辑也是可以优化的，不能死守自己的那一套逻辑，不好的就要改，让自己一直有进步。都说新人得踏踏实实做好手头上的事，所以看似很简单的文档和原型图就需要我们多用心做好，做好这一步了，基础就打踏实了，然后朝着寻找更好的需求努力！

说起合金d头这款游戏的话也是一代人的回忆了，在曾经的时候呢，这款游戏热度非常的高，吸引了大量的玩家告喊拦进行游玩，直到如今的话回过头来观看，我们也是可以发现，在合金d头系列当中呢，也是有着很多隐藏很深的彩蛋。

首先第一个的话渗察就是在外星人系列当中，当玩家使用女性角色与外星人进行对战的时候呢，如果不幸死亡，那么就会触发特殊溶解效果，这个时候我们仔细观察就可以发现。这个彩蛋的话就是人物的衣服会被融掉，同时我们也是可以看清楚人物的身材各种方面，所以说，这也是射击游戏当中的一个爆衣设定袜胡，在当时的时候肯定不会注意那么多，现在想起来简直是非常的羞涩呀。

还有第二个的话，就是在游戏当中的时候呢，大家肯定会发现在不同的情况下，经常会出现一个喜欢说教的老头，而这个老头的话原型原来就是游戏公司的社长，在当时的时候呢，也并不是非常的起眼，但是现在看来呢，果然是，并且因为在当时的时候呢，社长非常的喜欢说教员工，所以他也是将这么一个特征设计到了游戏当中，所以说，在游戏当中的时候呢，有着非常多以程序员为原型设定的彩蛋还是比较有趣的。

还有第三个的话，在一些场景方面呢，也是取决于现代的一些现实建筑。虽然在当时的时候并没有发现，但是你重新玩一遍的话，就可以知道，像吴哥窟还有埃及金字塔这样的场景，在游戏当中可以说是非常的多，总之，以上这些的话都是一些隐藏的彩蛋，还有一些呢，玩家们可以自行去寻找。 

---