工作了也有一段时间,总算对PRD这玩意儿有个懵懵懂懂的认识,市面上教我们写PRD的文章大多是含糊其辞遮遮掩掩过于流程化和理论化,现在我大概了解到撰写的套路,结合我自己的案列在此给大家分享一篇实践干货型PRD.
首先来介绍下说明文档的生成流程:
1.需求确认
2.梳理逻辑,确认产品所需功能
3.绘画原型,添加说明
需求确认
需求就是做产品的动机、目的,其核心是为什么人解决了什么问题.
这句话牢记于心,逻辑大方向的梳理就很难出错,用句装逼的话说那就是"勿忘初心,方得始终".
我们要学会如何辨别伪需求和真需求,如同那个在业内说烂了的段子一样"用户需要一匹马,但实际上他只想更快地到达目的地",很多时候用户是不知道自己想要什么的,他们只会表达想要的结果(功能),而我们需要从中抽丝剥茧,找出真实需求.
需求来源方式:
1.版本的长期规划
现在都流行MVP,先上线基础功能的一期初版,后面在根据已有市场的反馈和版本规划慢慢进行二期三期的需求确认.
这种需求一般都是真实需求、强需求,且优先级强烈.
2.运营部门、同事的需求.这种需求通常与活动、KPI一并到来
"哎,你看Uber有这个邀请码,我们也搞一个呗,拉新肯定有效"
"我们的商城价格怎么没有小数呢?这有小数多好啊"
第2种需求来源,当时就要问清楚,为什么突然要做这个功能,目的是什么?
先确认需求的必要性,不需要那就抛弃,需要那就先思考,能否用当前可用的模块或功能去完成需求,如果不能,那就添加到需求池并加以排序.
3.用户的反馈 or 数据分析得出的结论
需求来源3就比较有意思,"用户的反馈"类似与来源2类似,要进行分析归纳.
"数据分析得出的结论"与来源1类似,通过百度指数、GA、GrowingIO等数据支持和已有的市场反馈进行分析,从而得来需求.
4.PM的滴水不漏和天马行空.大部分需求都是对已有产品细节的完善.
前者靠经验、产品的体验测试:
"这个搜索算法要优化一下,特定关键词增加特定商品展示几率"
"个人中心显示逻辑不对啊,怎么一打开就是修改地址"
后者靠思考、学习、类比:
网易云音乐的云盘、微信的摇一摇、微交互的崛起.
这次我的需求来源方式是1,即——版本规划.
此次的需求是增加"账户明细"模块,为用户和财务双方提供便捷的对账功能.
梳理逻辑
做这个模块是由于To B业务的特殊性,我们60%的客户是选择线下付款的,货物直接送到用户手中而不收钱款,在月末统一结账,所以金额是有账期的.为了避免用户和销售人员无意义的扯皮(财务对账依据ERP,不以web为标准),因此推出账户明细功能.
梳理逻辑从需求出发,先不要画原型,先不要画原型,先不要画原型!
梳理逻辑就要考虑需求的使用场景(为什么用这个功能、什么时候用这个功能)、使用方法(怎么用这个功能、要用那些功能)、字段数据(需要提供什么信息).
拿这次我要做的需求举例子:为用户和财务双方提供便捷的对账功能.
具体的功能就是:
1.用户下订单选择支付方式,选择支付宝微信交易,用户的授信额度不变,使用线下付款,即货到月结,授信额度对应的减少.
2.然后生成每一笔的交易流水,方便客户和销售人员对账.
3.同时可以支持运营的活动,变相的实现订单改价、返现、充值等功能.
那如何对账(梳理逻辑)?
1.分析用户使用状态
对于用户而言,他要看到每一笔的收支金额、收支类型、购买时间等关键信息.
对后台而言,在对账这一模块,是不需要添加什么功能的,搜索用户加筛选时间就OK,因为对账的信息本质就是订 单列表中的一些核心字段,所以后台直接筛选订单就可以查看用户的所有交易流水.
在运营功能性这一模块,要添加返现、充值、退款、提现等操作.(其核心是对余额这一字段做增减变化).
2.有哪些核心字段?(该步骤推荐使用MindManager等工具枚举字段信息,避免遗漏)
3.明细信息生成规则
由于业务的特殊性,所以交易流水生成规则不像C端,以支付状态为准,用户付款,交易流水生成.
一开始的打算是准备以提交订单为准,用户一提交订单,就生成一条新的交易流水,根据交易流水中的支付信息对 余额进行操作.后来发现这种判断方式太过草率毛躁,有很多的问题,比如:
"用户订单提交错了但是他自己不取消去提交新的订单怎么办?"——后果:交易流水会有过多的无效信息
"如果采用这种方法,后台如何判断用户流水?"——后果:无法判断,不知道这条流水用户到底要没要
最终我使用的是:通过订单状态来生成交易流水,即:用户提交订单后台发货,用户的账户明细才会生成新的交易 流水,如此一来以上的问题便通通都解决了.
绘画原型
关于如何绘画原型这里就不展开篇幅一一叙述了,下次另开文章详细讲解,这次就简要的说说绘画原型的要点:
1.对齐对齐对齐,整体设计语言一致
对齐我认为是原型的第一要素,可能很多人都嗤之以鼻,一个原型而已,表达我想要的就行了,低保真足矣,对齐何用?
但我的理解是一个对齐的原型有助于UI的快速开发,不用在UI上浪费太多的口舌,其次审美好点的PM(比如我,我就是这么不要脸~~~)直接上色高保真分分钟的事好吗?然后直接交付给开发,UI都省去了(也就想想别当真,毕竟难度太高)
整体设计语言和对齐一样,整个原型的通用要素一致,如按钮都是矩形的、顶栏都是蓝色的、间距都是一致的等.这样方便UI制图,原型一给,跟他说照着图片上色,毕竟他不是我小棉袄,不懂我的心,我也不用过多操心,后期的毛病较少,省时间.
2.追求完美的心态
有的时候你认为原型很完美了,但是在你Boss的眼里,呵呵,呵呵呵.
毕竟这是人的缺点,对自己做的东西总是趋向于正面评价,看不到缺点.也别说一秒变小白这么高端的事情了,原型制作完毕,等个1、2个小时,时间充裕的话明天在看,你可以发现有很多可以优化的地方.
从一个原型初稿到最终版经历个8、9次是很正常的.
3.多上上设计的网站,多看看潮流设计
没有审美,那就培养审美.这里推荐几个网站:
不会设计原型那就借鉴竞品、同行,这是上手的最快方式,别不好意思.
撰写文档
最最重点的部分,撰写文档,下面我就先说说它的要点:
1.逻辑清晰,条理分明
PM最重要一项能力就是逻辑,而写需求文档则完美的体现了一个PM的逻辑层次.
说一个故事简单,但是说一个起承转合跌宕起伏的故事那就难了,而写需求文档也是如此.
先写前端、再写后台.
先写模块、再写功能.
先定义字段、再说明生成逻辑.
这三句话是核心中的核心(如有不对,欢迎指正)
2.格式一致、还有对齐
虽然我是双子,但是写文档的时候我就秒变处女(不是处男吗,废话当然不是).
格式体现了你的工作态度、你的专业程度,甚至是你的工作能力.
就算你是瞎BB,开发哥哥看到这么美丽的文档也不会说啥了(反正我是不信)
3.语言直白、通俗易懂
不要自己制造些云里雾里让人看不懂或者有误会的词组词语,多用大白话.
这方面别学苹果,动不动就bigger than bigger,你要真这么写了,开发会拿着他的mbp让你知道什么叫pain than pain.
格式一致逻辑清晰语言直白,只需要注意这些,撰写一份优美直观的说明文档不再是问题.
写了这么多,估计你们还是迷糊的,啥也不说了,冒死上工作图.
被Boss看见我就炸了.
还是王炸.
这是word版本的,也是我所使用所热爱的(瞎说,明明是Boss要求的).
word版本更集中于逻辑的说明,语言简练,描述集中.
Axure版由于原型的存在,所以直观易懂,毕竟一图胜千言.
Axure的PRD模板如下(由@臻龙 PRD文档删减而来),欢迎关注私聊索取
说了这么多,不准备点个赞吗,少年
未经允许,谢绝转载,更拒绝抄袭.