各种工作场景中的PRD编写技巧
编辑导语:需求文档的撰写在一定程度上可以帮助产品经理理清思路,推动业务项目的更快推进。然而不同场景下,需求文档的撰写往往需要针对工作中的复杂情况进行调整。本篇文章里,作者总结了几种常见工作场景中需求文档的编写技巧,一起来看一下。
在现实的PRD编写工作中,相信很多同学都有各种各样的问题。比如:时间不够用、完善度不高、历史设计文档找不到、没有一份文档能完整描述线上产品、文档太大编辑卡、页面太多开发无法快速找到更新内容……
而无论是网上的文章,还是线下的培训班,大多数都是教大家如何写一份完整细致的需求文档,但这样的文档是无法应对工作中复杂情况的。
想要解决现实中的各种问题,需要根据不同的场景制定不同的文档编写策略和技巧,本文梳理了7种工作中常见的场景及相应的文档编写技巧供大家参考。
一、场景1:从0开始/大功能改版/增加大功能模块
解决方案:word类型PRD+原型设计文档(重功能、流程和规则,弱视觉和交互)。
场景特点:功能性内容较多,重点在于介绍功能的结构、描述、逻辑和规则。所以通过word文档的纯文本内容用以描述功能,能让开发人员快速了解众多功能。
用户场景流程图可以在Axure中绘制,功能结构图可以通过脑图工具绘制(Xmind/MindManager等)后导出成图片放到原型文档中,详细的功能设计和规则通过Axure绘制原型表达。
这个阶段的设计应该弱化视觉和交互层面的设计,尽可能的减少视觉交互规则,将重心放到功能上,当功能满足需求上线后再逐步优化视觉交互。以下图片仅供提供思路,需要完整模板请留言:
二、场景2:小版本迭代
解决方案:原型设计文档(带功能需求描述+跳转)。
场景特点:需求相对较少,往往是针对某一个小点的优化,大多是在原有功能基础上修改,或增加很小的功能内容,所以不需要长篇大论,直接用Axure绘制原型文档注明修改部分,并在首页写上版本号和时间,以及相关的功能需求描述,加上页面跳转链接即可。
三、场景3:历史设计文档丢失或不全面的情况小改版/没有产品储备的项目投标
解决方案:原型设计文档(功能需求描述+截图修改、注释)。
场景特点:在历史文档不完善的情况下,需要一边对照线上系统,一边对照历史文档,进行编辑修改,费时费力,所以只需要截取线上产品图片,在此基础上修改说明即可。版本和需求描述参考场景2中的需求列表即可,如果是大改版,还是建议重新画原型吧。
对于没有产品储备的项目投标,招标文件基本都有大致的功能需求描述的,相当于命题作文,投标文件中也会详细介绍功能,所以没必要再额外写word类型的产品需求文档,需要的是快速输出demo演示方案,只需要截图修改即可。
四、场景4:体验优化迭代
解决方案:原型设计文档(重视觉交互规则描述)。
场景特点:功能层面没有改动需求,不需要功能描述,重点在于交互视觉的规则描述,仅仅需要在原型文档上结合界面详细的编写即可。故提供一种逻辑梳理框架,供大家系统性的梳理规则思路。
信息&限制:描述区域内所包含的字段,以及各个字段的限制规则,例如必填、长度、字符限制等。
操作:描述区域内所支持的操作行为,例如单击、向左滑动、向上滑动等,并描述操作后的反馈。
状态:描述区域内包含几种状态,每种状态是如何触发的。
排序:描述区域内内容的排序规则如何, 例如按时间倒序等。
五、场景5:公司有现成的模块或组件/或对接别人公司的产品
解决方案:原型设计文档(重点描述对接规则)。
场景特点:不需要过度关注各自产品内部功能的规则,重点在于描述对接部分的逻辑和数据规则。
六、场景6:完整版设计文档
解决方案:word类型PRD+功能结构图+用户场景流程图+原型设计文档(整合各个版本的设计文档,附加版本迭代记录)。
场景特点:主要用于文件归档,便于后续入职人员,能够快速对产品有整体详细的认知。“word类型PRD+功能结构图+用户场景流程图”这3块就不重复了,前面有。主要是原型设计文档如下图:
七、场景7:客户演示原型Demo
解决方案:原型设计文档(重高保真和主流程的交互)。
场景特点:主要用于客户或给领导演示系统效果,在不调用研发资源的情况下最低成本的演示产品效果,重在视觉和交互的动态编辑,而不是规则编写。
高保真原型就不多赘述了,网上一搜一大堆。只要会用Axure绘制交互效果,并把主要图片和文本内容换成贴近主题的即可。
八、总结
想要又快又好地完成产品设计工作,就需要针对各种场景,具体问题具体分析,没有任何一款PRD是可以同时满足所有场景需求的,希望本文能对大家有所帮助。
如果你也有遇到过这些问题,或有更好的方案,欢迎留言~
作者 @无疑路
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!