盘点PRD中易遗漏的三类非正面需求
- PRD中不提双击的,则一律将该控件的双击事件都定义为无效。
- 只在需要双击的时候才定义双击事件。比如抖音,双击视频画面则为点赞,单击则切换【播放/暂停】。
3. 哪些不是目标场景或目标用户
比如业务规定,主播在直播间获得打赏的虚拟物品,可以对应领取指定的实物商品。那么假设,某主播积攒了上百个同一虚拟礼物,并且要同时全部领取。
但是实物库存不够,主播以“平台不守信用”为理由投诉平台,该怎么办?
办法很多。要么就规定每次只能领取n个(n在试运营阶段确定);要么发现库存不足的时候,提前发出延迟供应的免责声明;要么就通过客服下线解决(比如兑换同价值商品或现金)。
总之,在这件事上,不把这种场景作为产品设计的考虑对象。即不为其开发对应的产品功能,也不考虑其他办法解决该问题带来的不良的用户体验。
因为根据边际效益,或者说产品定位来说,这种场景下的这号人就是排除项。既不是我们鼓励的现象,也不是能为产品带来价值收益的场景,同时花费精力只能让产品失去重心。
产品经理在对待类似这种情况时,要判断出这是不是我们的目标用户和场景。如果不是,需在方案评审时或者在需求背景描述时候加以解释,并果断转换解决方案。
二、需求的异常项
异常,主要包括目标App本身的异常、手机系统环境引发目标App的异常,和周边平行应用引发目标App的异常。
1. App本身设计的异常
举个例子,电梯中打开App,到达初始页面【首页】,界面显示在加载。我们知道,这是网速问题。
这时候点击【我的】菜单,想看草稿箱。但是发现无法打开【我的】。退出重启,依然如此。
【我的】是本地文件,不依赖网速,却为啥也打不开呢?
其实是因为代码这样定义的:打开App,要做一次初始页面的加载,没加载好,就不会允许其他操作。
这就导致了无需加载的【我的】页面,虽然不依赖网速,但是因为依赖网速的【首页】没完加载,所以“殃及池鱼”,【我的】也打不开了。
因此,作为产品经理,对于这种初次加载App的规制,就要做一个最长加载时间的设置。比如,若2s仍旧加载不出来,则切换到无网情况下的机制展示(无网络情况下可以查看页面)。
2. 外部环境导致的异常
以系统的定位功能为例,正常情况下,若定位系统开启,那么打开App,定位功能就会为App提供当前位置,并展示在页面。
但是若手机定位不开启,那么APP的位置就无法获取。
这时候就需要产品经理考虑,在这种手机GPS异常(系统设置带来的异常)情况下,位置显示什么?比如是显示空、还是图标。
同样,如果手机未联网,或者网络不通畅导致的加载失败 ,就该提示“加载失败,稍后再试”。
如果App检测到断网了,或者网速不好,就该更准确地提示“网络不佳”。
3. 平行应用影响导致的App异常
比如,当手机开启蓝牙,并且被另一个手机连上的时候,就会在手机顶部展示一行状态:1个连接。
这时候实际手机界面被这一行挤压了。
遇到全屏播放的界面,就会出现下图这样:顶部Tab页签下移,视频画面不居中,底部菜单下移。
App是否有考虑过这种情况下的界面兼容呢?如果没考虑,那么就会出现这一合理场景下的异常bug。
又比如,一个语音聊天应用,当按住home键切出去的时候、来电话的时候、当用户执行其他应用的时候等,该怎么规定呢?
作为产品经理,抛砖引玉一个方案例子:
a.【语音聊天】时 home键切出来,不影响聊的功能。
b.【语音聊天】时 不管是否切出去,若来电话(电话未挂断的情况下) 则双方屏蔽语音,但不挂断。同时给对方toast提示:对方忙碌,马上就好!
c.语音聊天时 切出去,看视频、听歌曲、打开其他应用(如微信)进行视频等,都不影响语音聊天。(是否影响到效果,玩家自行处理)。
三、默认值设置
1. 默认头像
这就像是统一制服一样,不能因为这个孩子没准备衣服你就让他裸着出场。所以要确定一个这样的图。
这个头像可以是灰色底图,比如花椒的就是。也可以定制带产品元素的,比如映客的。
2. 默认昵称
好处就是万一用户懒得写,也不至于空荡荡的。
产品经理设计一个昵称库,随机给用户分配昵称,有时候还有意想不到的惊喜感。
个性签名也是同样的道理。
3. 默认提示
在无数据的页面,比如【好友列表】,如果不告诉用户这里确实没数据的话,用户可能会怀疑是不是App故障导致的呢。
所以产品经理一般都会给予一个默认的全局通用的提示,比如“暂时无数据哦”。
4. 默认封面
比如相册, 在网速不好的时候,加载不出来,那么怎么办呢?黑洞洞的不好看,所以也需要产品经理确认一个默认的封面或者数据背景图。
这样大家一看就明白了,哦,是没加载出来啊。
5. 其他默认项
默认项总体上就是通用规范范畴的。远不止列举的这几项。产品经理应事先就做全局设计,确保默认项一致、通用,且不遗漏。
总结
一个产品可以拆解梳理出一份PRD;但是反过来,提供这份PRD给开发,却往往不能逆向地输出同一个产品(假设UI一样)。
这就是bug的诞生,和测试的必要性。
因此在确认PRD的时候,就像素描,不仅要高光区,还需要阴影区。
产品经理在说完正向的要什么之后,还要说清楚不要什么、异常情况下怎么办,以及默认怎么办。只有将细节说完备,才有可能让需求完整落地。
作者:唧唧歪歪PM;公众号:唧唧歪歪PM(ID:jjyypm)
- 基于需求文档(PRD)的功能用例设计
- 产品经理之产品需求文档PRD-全栈工程师熊盼
- 如何正确的写产品需求文档(PRD)
- 产品设计(2.6)PRD写作 – 需求文档(PRD文档)
- 如何撰写一份合格的产品需求文档PRD?
- [转]产品需求文档(PRD)的写作
- 2012 IT热门人才需求类型盘点
- 如何写好PRD(产品需求文档)+范例
- 2.5产品功能需求PRD
- 产品需求文档(PRD)的写作方法
- PRD:倒推今日头条需求文档 - 推酷
- PRD产品需求文档
- 应工程师需求,今天来盘点一下常见总线类型(干货版)
- 了解产品设计中的BRD、MRD、PRD、FSD需求文档
- 2012 IT热门人才需求类型盘点
- 产品经理如何写PRD文档-产品需求说明书
- 产品需求说明书 PRD模版
- (10.3.3)第六期 产品需求文档PRD模版
- 产品需求文档五分钟轻松搞定!这可能史上最全PRD文档模板
- 做完一个没有需求文档,没有产品PRD,没有UI,没有测试,只有开发主导的项目后的体会。