产品人写PRD应该避免这些坑

一、在产品的整个开发流程中，PRD的作用有以下几个方面：

• PRD指导其他部门进行工作的准备工作

测试根据PRD写测试用例；开发经理根据PRD写开发文档；UI根据PRD和原型设计。

• PRD承担字典的工作

测试人员可能更多的是根据测试用例工作，而开发看的更多的是开发文档。但当大家发现某个细节在测试用例或者开发文档描述不清楚或者难以理解时，就会翻出PRD查找相关内容。PRD在这个时候是承担了一个字典的功能。

• PRD是打架必备。

测试和开发的天然属性决定了他们之间微妙的关系，很多时候bug的定义是似是而非的，很多时候涉及到用户体验的问题，而用户体验有带有很大的个人主观性，此时矛盾就出现了。

当测试和开发就某个问题争论的面红耳赤，几乎要干架时，最后一句压场的话就是“别瞎bb，看PRD！”，此时要是PRD上有关于此问题的详细描述，那开发要么找产品经理改需求，要么只能自己改代码了。
要是PRD上没有相关内容，那开发就可以傲娇的说“需求就是这么写的，你要改，先去找产品改文档！”。
所以一般来说，测试是希望PRD写的越详细越好，这样他们的bug才提的有理有据，而开发希望提出的需求能够逻辑严密，但不太希望产品经理将所有的细节都规定死，毕竟产品对于技术的了解并不深。所以产品要注意把握好度，这点我自己还在不断的思考之中。

二、做到一下这些，瞬间觉得文档简洁了许多

刚开始写PRD的时候，不知道有些功能可以整合在一起说明，每次都罗里吧嗦的全部重新说一遍。
比如，分享功能，应用里很多地方都涉及到了，每一次涉及分享，我都会把分享的机制从头到尾说一遍，其实这就很啰嗦，文档的文字本来就够多了。
所以，建议将一些在软件里反复涉及的功能提炼出来统一说明，当后续涉及到的时候，简单阐述一下就行，不用再重头说一遍。

我的经验是，对控件及一些通用的机制进行统一说明，会使文档简洁省力一点。

在文档的一开始，最好有一个单独的模块说明应用内使用的控件，说明这些控件的类型以及每个控件对应的操作方式，在这个模块统一说明之后，在其他模块涉及此控件时，只要简单阐述一下就ok了。

下面列举了一些常用的控件。

模块一：控件说明

输入框
●若输入框有默认提示，点击输入框，弹出软键盘。
●当输入框内不为空(空格除外)时，默认显示消失。

软键盘的弹出及退去机制
●当输入框内必须输入的为数字时，弹出数字软键盘。其余时候，弹出文字软键盘。
●当在软键盘以外区域，点击或者向下滑动时，软键盘退去。

小黑块提示
●显示*秒，然后自动消失。

选择弹框
●弹框上有操作按钮。
●点击弹框以外的区域，弹框消失。

手机返回键(安卓)
点击手机上返回键，返回上一层，并弹出相应提示。

Home键
按home键，程序改为后台运行，再次打开软件时，则回到按home键时的页面。

在文档的一开始，最好有一个单独的模块说明应用内使用的控件，说明这些控件的类型以及每个控件对应的操作方式，在这个模块统一说明之后，在其他模块涉及此控件时，只要简单阐述一下就ok了。下面列举了一些常用的控件。

同样，很多通用的机制也能整合在一起，比如加载机制、缓存机制、网络判断、中断机制等， 以下是我自己整理的几个通用的功能。

模块二：通用功能

缓存机制
每一步操作、每一个页面切换之后，都要想得到的数据需要缓存么？缓存到哪里？清理缓存的时机是什么?

网络判断
●一般当涉及到下载或其他很耗费流量的操作时，会进行2/3G网络还是wifi网络的判断，当判断出是非wifi状态时，会进行提醒。
●其他需要向后台请求数据时，只进行简单的网络状况是否良好的判断，当网络状况不良时进行提示。

中断机制
除退出登录外，要考虑出现什么情况会导致用户中断操作。中断操作会有什么影响，比如是否要保存操作进度等等。

常见的几种情况如下：
●来电
●Home键，退到后台运行。
●按返回键(安卓)
●页面上有暂停使用的功能，比如倒计时、音频播放过程中的暂停按钮。

虽然APP千差万别，但不管设计原型还是写PRD时，只要涉及到页面和控件，有些东西还是相通的，下文整理了一些要考虑到的方面。

页面的相关注意点

●此页面的使用场景是什么，用户进入此页面目的是什么?我们设计此页面的目的的是什么?我们希望用户长时间停留此页面么?
●前置条件：有几种方式进入此页面;不同的身份进入此页面时，操作权限有差别么?
●退出此页面的机制。常见的有：左上角的返回按钮，返回上一层;按手机返回键(安卓)也返回上一层。
●操作手势：比如在左右侧抽屉，左右划通常可以返回主界面;比如顶部有切换Tab，是采用左右划切换还是点击切换;还比如有些应用双击可放大页面，两个手指按住并同时向中间滑动，表示缩小页面，比如长按可能会弹出复制及粘贴的选择框。
●身份不同、页面的显示内容不同

比如被踢出群组后，在被踢出人的聊天页面和其他人的聊天页面，显示内容是不同的;再比如，管理员和普通成员的操作权限不同，所以进入同一页面时，显示的内容也不同。

默认框架（常常忘记！）
当页面有好几种状态时(比如2张图片和3张图片时，页面的状态就是不同的)，要定义默认状态，及定义页面的默认框架。
进入页面时先显示默认框架，向后台请求数据后，根据后台数据，页面再调整为对应的框架。

数据为空时的默认图片（常常忘记！）
上一条定义了页面的默认框架，但仅有框架是不够的，还必须定义框架中的默认显示图片，此图片会打包进入安装包，网络状况不好，向后台请求不到数据时，就会显示默认框架和默认图片。

显示机制、排序机制、刷新机制
确定app要适配的屏幕大小，iOS支持到什么版本，安卓要适配的分辨率是多少。
然后要形成自己的直觉，适配的最小分辨率的屏幕最多能放多少按钮，现在的设计方案放在要适配的最小屏幕上，会不会太挤。
当某一行字数太多时，一定要想这么多字放不放的下，放在一起好不好看。
是考虑翻页还是瀑布流?

排序机制。
一个页面显示多少?按照哪些因素进行什么排序?

刷新机制。
一次刷新多少？如何刷新更多？自动刷新还是手动刷新？当刷不出新内容时给提示了么？
常见的手动刷新方式：右上角有刷新按钮，点击，手动刷新。
常见的自动刷新：再次进入此页面时刷新;设定一个时间值，每隔一段时间刷新一次。

控件的相关注意点

●控件是指例如按钮、选择框、切换tab、滑动条等等之类的可操作的部件。
●控件的各种状态出现的前提条件是什么？不同身份进入页面时，按钮的状态一样么？
●控件的状态定义？比如，比如提交按钮，要定义清楚什么时候可点，什么时候不可点
●控件的位置、大小是否合适？待操作按钮在当前界面中是否明确?重要、频繁触发的功能按钮是否在手机的可操作区域？
●控件的操作方式有几种？每种操作的结果是什么？用户能找到隐藏的比较深的操作方式么？需不需要加用户引导？

常见的有：点击、长按、左右划

操作过程中的状态改变
●加载：状态改变的等待时间是否超过2S左右，如果太长是否需要加入加载状态
●读取
●缓冲
●操作进度显示：如进度条、

操作过程中的继续操作
考虑按钮操作过程中的继续操作会造成什么影响?操作进度需要保存么?需要进行提示么?
常见的继续操作：取消、切换、返回、点击其他区域、再次连续的点击此按钮

操作过程中的中断
（参考 通用功能 “中断机制”）

操作之后
●是否出现了合适的提示？出现的提示的类型：选择轻(tip/小红点)、中(Toast)、重(提示框)优先级别是否恰当
●操作后按钮状态的变化
●操作后出现的各种结果：成功、失败、空值

思考对操作之后出现的结果，再次进行操作，会出现什么情况?
思考特殊情况对此按钮的操作带来的影响：
●此按钮的操作对网络的要求是什么?wifi还是2/3G网络?网络的判断逻辑是什么?网络不好时，进行合适的提醒了么?
●此按钮要求登录么?如果未登录能进行操作么?需要进行登录提醒么?
●多次连续的点击，会造成什么影响?是否给予反馈?
●操作之后得到的数据需要缓存么?缓存到哪里?清理缓存的时机是什么?
●一些操作实施后，引起的变化是什么时候显示出来?即可显示?此刻不显示，再次进入此页面时显示?还是此刻不显示，再次进入应用时显示?

比如，聊天记录删除后，返回聊天页，是立即清空聊天记录还是再次进入时清空?
总的来说，PRD属于操作层面的技能，要尽量有理有据，逻辑严密。

曾听到过一种说法：产品er的门槛在入行之后。深感认同，产品经理近年来是一个被炒得很火的职位，没经验、不会技术，不懂运营，都能成为产品，产品经理听起来大小也算一个经理，貌似光鲜亮丽，可实际情况却不是这样。

小公司，技术为王，产品的权限其实很小，大的战略方向有boss定(对需求实现细节指手画脚的boss真心很不少)，很多时候boss直接拍脑袋，这个按钮摆这里，那个按钮摆哪里，抄抄微信吧，抄抄陌陌吧……
有时候你真的会很沮丧，但没办法，想办法说服别人，也是PM必备技能，学着用数据说话，尽可能的考虑周全，有理有据，首先自己要很确定，才能说服别人。