要活学活用,之前说的产品设计的内容,不要用一套自我主义思维打天下,强调下产品结构的几种特点:矩阵结构【一个页面阐述大量的内容,并不是有大量的分层,多个维度来统计能功能】,线性结构【某个骨干流程按照某个线的方式,某个场景往下串】,层级结构【按照用户自行选择,需要干的事情,做的层级,1.足够偏,功能足够的多。2.层级足够的深,每次选择的足够少,统一认为第二种的用户体验比较好】。不要小看产品的结构设计,这是产品经理的基础。结构设计是思考一个功能第一想的问题,不先想界面长什么样子,先想是什么层级,什么结构的产品,然后在想有几个界面有几个判断。开始今天的内容,画原型和写PRD,主要是PRD和原型的对应关系,核心是说说PRD。
主要说了界面交互,低保真原型的设计。
PRD里面讲的逻辑限制开发了代码,这块就去查某个表,做某个参数,定义的变量都写出来了,觉得很崩溃,照这样写出了问题算谁的,明明理解了业务,有别的方式不这么做,用更好的处理方法,出了bug算谁的?PRD到底写成什么样的,描述业务好不好。
早期的PRD不叫PRD,叫开发规格,真的很限制人的,PRD是产品设计的第三个环节,根据原型设计进行讨论,修正原型的正确性,也可以跟研发进行评判,对整个系统的开发工作量进行估值,需求文档往往是后置的,一般来需求文档就是需求评审之后,代码就开工了。在原型设计之后研发就会做一些开发的准备。PRD也不能当饭吃,一堆人在写PRD,写了这些也不能产生价值,写这些文档干什么用呢。
交互设计、视觉设计【需要了解场景进行设计】、项目经理【PRD认领,符合PRD管理规范的】、开发【开发的基本,开发需要PRD中将业务逻辑讲清楚】、测试【依据PRD出测试用例的,怎么进行测试,测试用例的变更和新增】、其他产品经理【讲述可能有遗漏不如直接看PRD】、其他需要了解业务逻辑的人。
2.需求文档的作用是什么?
准确、直观、完整传达产品需求,保证各角色沟通有依据,保证产品质量控制有标准,存档。
让项目参与者明白为什么启动该项目,如果来此竞品分析,分析下竞品,竞品实现的功能是什么样子的。
2.项目目标
让项目参与者共识目标,找到价值感。目标尽量量化。上线后验证目标达到情况的依据。
3.编写人
修订日期、修订人、修订说明、修订原因、修订文档版本号。
拆分成最小的功能点功能点之间相互独立方便参与者理解需求,评估工作量
拆分:一定要拆出来一个功能的组合。一定有个优先级最高的就是产品的灵魂,需求点。P0级的功能.P0是灵魂,没有它就不是这个产品。P1和P2是对用户体验有绝对性意义的东西。P3是对产品的存活有决定性作用的东西,拉新留存。P4是锦上添花的作用。功能拆分的时候不光光的讲有几个按钮,几个值,首先优先级。是不是拆分出来的每一个功能列表。
为什么需要逻辑展示?弥补与程序员的种族差异,帮助自己梳理思路。不免需求遗漏,考虑不周。
多角色流程图(泳道图,跨职能流程图:多角色,多系统,多模块流程)
单角色流程图(基本流程图:单角色,单系统,单模块流程)
流程图:基本元素
基本结构:顺序结构
选择结构
循环结构
页面流程,这是UED和前端最喜欢看的流程图
想不到那么多情况怎么办?善用工具,帮助整理思路,表达清晰。向测试学习,多看测试用例,善于总结。
数据需求的采集标准
数据采集的类型基础数据,交互数据,用户路径
业务数据,服务端存库,用户行为数据,前端埋点。
如果没有BI支持,需要茶品经理自己定义埋点事件,不同的数据统计工具,不同的埋点的规范
可能出现的风险点和策略
PS:PRD是一个文件,文件是写给人看的,文件什么样不取决于产品经理想写成什么样,取决于读者。大家认为好才好,为别人写的不是为自己。文档是核心:以表达为目的,让查看的人清晰易懂,文档完整性很重要,文档表达方式灵活:axure、word、wiki、脑图、表格,逻辑严密,表达清晰。产品经理技能宏观至战略,又能微观至一个文本框的各种边界和异常