比如说以前在做BT下载的时候，因为我是女生，不常下载，所以根本不知道BT下载是要先下一个种子，再由种子文件去下载对应的内容。对于这些影响功能流程的环节，我们还是需要自己去找相关的专家来帮你解决，没有什么更好的办法。

很多时候我们会自动跳过需求转功能流程这个环节，认为需求反正已经很清楚了，或者是有其它的竞品可借鉴的，拿到需求之后，就直接就开始画原型了。结果就是好多功能流程在进行交叉的时候，会变得非常的混乱，不知道怎么把这些流程和功能往圆心里面塞。

我推荐大家要先做加法，用思维导图和流程图，先把你能想到的所有功能和流程图全部都列出来、画出来。然后再做减法，优化掉流程中多余的或者是可以省去的环节，用最少的流程完成功能，从而确定产品最终的路径图。

原型憋不出来怎么办？

有了功能和流程图，还是不能把原型编出来的情况也大有人在。因为原型并不仅仅是我们看到的一张图，它还承载着产品的架构设计、交互设计，需要考虑用户体验，产品的扩展。你的产品是用导航布局、标签布局还是网页布局，都需要在原型制作前就考虑清楚。

TOP10应用

在这里我要跟大家分享的是，有了功能还做不出原型来的，通常是产品用的太少，见识太窄。上图显示的是APP全球IOSTOP10的应用，大家看一下，你熟悉几个。

看到图标能对应出产品名称吗？能说出这些产品大体的产品框架吗？也许这些APP你都见过，也都用过，但是你不一定了解，或者没有完全理解，或者是没有思考过这些产品的架构，没有形成自己的方法论。只是停留在见面层面这种粗浅的APP体验认识上，会让我们在产品原型设计时，尤其是借鉴他人的产品设计时，犹豫不决，徘徊不进。

比如同一个功能，因为A产品是这样做的，B产品是那样做的，那么到底模仿或者借鉴哪一个，你心里就没有底了。

怎样才能让自己熟练地在原型中将功能和流程串联好呢？最好的方法就是动手练习，比葫芦画瓢，还是笨方法。

使用频率较高的APP

大家可以看到图片上的这些产品，都是使用频率挺高的一些常用产品，试着用一遍这些产品的所有功能，因为很多边角功能，或者是一些边界功能，大家平常可能都不会用，但是你在做产品设计的时候，其实是会用到的。然后自己绘制一次原型，看看能否全部连起来，如果不行的话，就再试一次，如此反复，经过多次的练习，我相信一定能掌握好做原型的基本能力。

这里需要提醒的是，原型不是只是图，还有文字和交互逻辑。这些产品上面的每一个文案，你能一字不差的画出来吗？

什么样的PRD文档才算是合格的？

产品功能和原型方案有了，就要形成需求文档，传递给项目组成员进行后续的实施。但是我们总会遇到需求文档PRD理不顺的问题，不知道怎么写才能让别人看得懂，不知道怎样才算合格的PRD。有些同学比较纠结于需求的展现形式，到底是用word，用PPT，还是PS。

展现形式是可以多样化的。怎么简单怎么容易表达就怎么来。能用一张图的需求，没必要搞一个文档。我认为word虽然是最规范的文档形式，但也是效率和效果都最低的需求文档呈现方式，因为放图、放交互都不是很方便，查阅起来也不是很方便。

所以选择自己最合适的工具做需求的产品形式即可，不用太纠结于某一种。

不同的表达方式差异

需求文档最注重的是表达方式。比如上图，左边是一个像流水帐一样的需求表达方式。这种方式没有人可以耐心的看下去。右边是像处女座一样有条理结构性的输出的，让内容结构化，让需要查阅的同学一眼就能够找到自己想看到的信息，便于检索。

5个方面判断需求文档是否合格

一般我们用这几种框架的方式来分解功能，把所有的功能说明全部都覆盖到，才算是完成了整个需求文档。

第一个是按照在系统中所说的位置来分解功能。比如说先说前台的页面，再说用户管理后台的页面。

第二个是按照功能的主次来分解，先说核心功能，再说次要功能。

第三个是按照页面的布局来分解，从上往下，从左到右进行描述。

第四个是按照场景来分解，比如先说初次使用的，再说非登陆用户的，或者是已登陆用户的。

第五个是按照用户操作的步骤来分解，比如下载前、下载中、下载后。

最终只要能使文档阅读者读懂，就算是合格的PRD。

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!