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