产品新人写PRD应该避免的坑

标签: 产品经理 PRD 产品新人 产品需求文档 | 发表时间:2015-10-07 12:05 | 作者:IVY
出处:http://www.woshipm.com

产品入行半年了,大大小小的坑遇到不少,这些血泪经验是最宝贵的财富,一直告诫自己,要常总结、常反思,希望n年之后,再看到今天写下的这些东西,能有更多的感悟。今天主要说的是PRD中遇到的那些大大小小的坑,不一定适用全部情况,欢迎各位纠错,欢迎各前辈指导!

u=1923784364,3658206300&fm=23&gp=0

最近半年, 最主要的工作就是写PRD,PRD的重要性不言而喻。

在产品的整个开发流程中,PRD的作用有以下几个方面:

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

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

PRD承担字典的工作

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

PRD是打架必备。

测试和开发的天然属性决定了他们之间微妙的关系,很多时候bug的定义是似是而非的,很多时候涉及到用户体验的问题,而用户体验有带有很大的个人主观性,此时矛盾就出现了。当测试和开发就某个问题争论的面红耳赤,几乎要干架时,最后一句压场的话就是“别瞎bb,看PRD!”,此时要是PRD上有关于此问题的详细描述,那开发要么找产品经理改需求,要么只能自己改代码了。要是PRD上没有相关内容,那开发就可以傲娇的说“需求就是这么写的,你要改,先去找产品改文档!”。所以一般来说,测试是希望PRD写的越详细越好,这样他们的bug才提的有理有据,而开发希望提出的需求能够逻辑严密,但不太希望产品经理将所有的细节都规定死,毕竟产品对于技术的了解并不深。所以产品要注意把握好度,这点我自己还在不断的思考之中。

貌似现在也有很多公司不需要产品人员写PRD,但我觉得PRD应该是产品人的必备技能,他可以不要求你写,但你不能不会。作为一个新手,特别是一个没有技术基础的新手,写PRD时,是一个很好的梳理思维的过程。

刚开始写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必备技能,学着用数据说话,尽可能的考虑周全,有理有据,首先自己要很确定,才能说服别人。

产品这条路并不好走,也许在上海这个城市,我永远买不起房,永远买不起车,但希望,某个加班的夜晚,当我拖着疲惫的身躯,站在拥挤的地铁上的时候,听见旁边的一个少年拿着手机对另一个赞道:我kao!这款应用真的tm酷!我转过头去,发现那是我设计的应用。

 

本文由 @阿七 原创发布于人人都是产品经理 ,未经许可,禁止转载。


互联网人士必备微信公众号:woshipm,雷军和周鸿祎都关注了,如果你已经关注了,证明你已经很牛逼了。

相关 [产品 新人 prd] 推荐:

产品新人写PRD应该避免的坑

- - 人人都是产品经理
产品入行半年了,大大小小的坑遇到不少,这些血泪经验是最宝贵的财富,一直告诫自己,要常总结、常反思,希望n年之后,再看到今天写下的这些东西,能有更多的感悟. 今天主要说的是PRD中遇到的那些大大小小的坑,不一定适用全部情况,欢迎各位纠错,欢迎各前辈指导. 最近半年, 最主要的工作就是写PRD,PRD的重要性不言而喻.

基于axure的PRD协作

- - 幻风阁|kent.zhu'sBlog
大约1年多前我写了一篇《 基于axure的PRD写作思考》,其主旨思想是将文档版本的PRD与线框图及流程图结合起来,统一由axure来输出,降低PM与研发之间的沟通成本及交付物的传递成本. 当时这个文档是基于我做Web端产品设计的经验为蓝本完成的,这1年多来我从Web端完全转到Mobile端,还在继续的使用着这套方法.

基于Axure的PRD写作思考

- 超群 - 幻风阁|kent.zhu'sBlog
从半只脚迈入产品经理这个大门的那天起我就被2个文档的名称深深的纠缠着,他们是市场需求文档(MRD)、产品需求文档(PRD). 先不论你是什么方向的PM,这2个玩意一定会一直伴随你的Title跟着你. 这2个文档在不同的团队中有不同的叫法和写法,我也见过有团队的MRD其实就是PRD,不沾半点商业市场分析的边的,当然,这些不是本文探讨的内容.

PRD:淘宝有好货需求文档

- - 人人都是产品经理
编辑导语:随着移动互联网的发展,人们对网购的需求增加,用户需求呈现多样化和个性化. 本文是作者通过体验手机淘宝的有好货功能模块做功能业务上的拓展,通过用户调研提出优化方向,并生成产品需求文档PRD. 淘宝有好货位于首页正中间,能给宝贝商品带来庞大的流量,而有好货的slogan “1.3亿人推荐的品质好物”,进一步突出了有好货以精品为主的战略定位.

产品新人如何去设计产品?

- - 互联网的一些事-关注互联网产品管理,交流产品设计、用户体验心得
  你喜欢这个颜色吗?你喜欢这个操作吗?你喜欢这个内容吗?你喜欢这样的布局吗?产品经理随时随地都在想:“我要怎么做,我的产品才能让用户喜欢呢.   不仅是产品新人会考虑如何抓住用户,表现自己的产品天赋. 就是经验丰富的资深产品经理也会经常考虑如何提高用户粘性. 那么,作为一个新手,怎么样的产品设计能够让自己满意,老板认同,用户喜欢?作为一个新手,如何在“百万军师”中,找到属于自己产品的契机点和特色?.

产品

- - 人月神话的BLOG
最近一直在思考产品规划和产品设计研发的事情,原来谈的比较多的都是关于咨询和实施方面的内容,而对于软件和信息化行业来说,真正可持续的盈利模式仍然是有核心竞争力的产品,能够在垂直细分领域具备有定价权解决实际业务核心问题的产品. 有时候我们在考虑类似ERP类综合管理软件产品化的困难,但是实际在某个垂直细分领域,进行核心产品开发并实现产品化是完全可行的思路.

产品五问

- xiangqian - 阮一峰的网络日志
开发一个产品的时候,应该问自己五个问题:.   2、他们用这个产品来解决什么问题.   3、这个问题对他们而言有多重要.   4、我们的方法是否足够简单方便.   5、他们要付出的代价与所得是否匹配. 当我们对市场进展不够满意时,检视这5个问题比检视广告更有效. (上面这段话是白鸦在新浪微博里转发的,太重要太正确了.

产品三俗

- - 所有文章 - UCD大社区
有三种流行的产品要素“动态流、瀑布流、奖章”,我称之为产品三俗,容易因其流行而被滥用. PM选择它们有可能是因为“时髦”“标配”“别人都在用”,这很糟糕. 恰好动态流和奖章我都折腾过,多多少少吃过一点亏,总结如下. 动态流给产品带来的好处很多,比如以用户为节点来实现近乎于完美的信息分发网络. 但在采用这个设计之前,首先要理解,在用户层面上其本质是“订阅”,而用户接受动态流的根本原因是,订阅的方式提高了他获取优质内容的效率.

产品经理

- - 人月神话的BLOG
再谈下怎样能够算得上一个合格的产品经理,一个人不是说你能够有产品构思,能够画点原型,能够做团队和项目管理就是产品经理. 苏杰原来有本书叫《人人都是产品经理》,看了后大家可能会觉得做一个产品经理是挺容易的一件事情,但是自互联网提供和设置了大量的产品经理岗位后,产品经理这个词基本就烂大街了. 我们如何来界定一个产品经理,如果简单点来讲可以理解为 根据自己长期的项目和运营实践,通过自己的敏捷洞悉能力和分析能力,能够将当前的市场需求或潜在的市场需求转化为具体的产品需求,并能够核心的定义产品功能模型和价值输出,同时能够通过项目和团队管理的能力,凝聚一个小组形成一个真正的团队,将自己的产品构思付诸于最终产品实现的人.

产品原则和产品评审团

- - 技术改变世界 创新驱动中国 - 《程序员》官网
文 / Marty Cagan  译 / 黄捷文,唐丰能. Marty Cagan是享有世界声誉的产品管理专家,曾经担任网景副总裁、eBay产品管理及设计高级副总裁. 本文是他回顾自己二十多年来从事软件产品管理工作的总结和经验分享,描述了产品开发需要遵循的产品原则以及成立产品评审团的必要性. 产品原则是对团队信仰和价值观的总结,用来指导产品团队作出正确的决策和取舍.