论程序员的产品设计文档
程序员如何写好产品文档，读取产品文档
最近设计了一套系统，由于本人是程序员，对产品东西不太了解，因此复盘一遍，我认为在整个项目组，真正能产生对抗的并不是项目中的任何部分而是每个人的态度
在任何项目立项阶段，都离不开需求收集阶段，产品方案设计阶段，产品设计文档既贯穿了整个项目过程，又给整个项目提供了基础思维。也是产品验收的标准产品设计文档并非一成不变，也不能经常变化。
产品文档的作用
方案设计
方案记录
产品方案设计的要素
- 用户使用产品流程 （整体流程）
a).整体产品流程说明 产品定位
b).产品使用场景 投放形式
c).产品角色定位 使用形式
- 重点流程拆解
- 功能模块拆解
- 疑点&难点，拆解比对
- 整体流程模拟，推敲异常场景
- 系统场景建设
产品方案设计辅助工具
原型工具 axure
流程图 visio
文档 word
脑图 xmind
产品需求收集阶段
产品需求收集阶段，需要记录用户使用场景，了解该场景下空缺是什么，
在整个落地场景中，产品要做什么，形成文档。
规划出基本的功能大点
使用xmind规划大点
产品流程设计阶段
1.产品流程各角色流转文档
画出整个场景中，有可能出现的角色，已经确认角色，标识出各个角色应该如何交互
2.产品各功能大点进行规划
根据需求收集之后功能大点，进行一次排序规划出各个功能点的基本职责
3.产品各功能模块流转图
结合用户，场景各角色，设计出用户在在各功能点交付流程图
4.产品投放形式推敲（产品形态）
根据产品特性，产品使用角色， 用户群体，设计出C端产品的投放形式。
如 微信平台，自建APP， 支付宝小程序，百度小程序，知乎，抖音，今日头条 。
在确认产品形式之前，要考虑产品未来规划，用户群体的落地，以及针对于不同平台的投入力量，包括时间，和人力成本
投放群体 > 时间优先级 > 人力成本
5.产品系统设计
根据产品规划出，哪些是C端功能，哪些是后台功能，哪些外部系统交互功能
列出业务系统边界功能点
6.产品业务系统整体交互流程图
在功能点和大框架都明白的前提之下，就可以从头梳理一下需求，出详细设计的整体流程图了，针对于整体流程图，尽量细节到各个功能点。各个功能点进行拆解。
7.各业务系统流程设计
拆解开每个系统流程图，功能点，包括用户在整个系统中是如何流转的。如何交互的，系统需要获取什么信息，落地什么信息都需要想明白。
8.各业务系统功能点拆解
9.重点难点技术推敲
10.原型设计
原型设计，出了要体现整个产品的页面交互流程之外，针对于某些特定功能，要能具体到一些关键字段
产品文档整理阶段
流程设计之后，就可以编写产品设计文档（PRD）了，产品文档机构应该有以下结构
1.文档设计，文件名需要体现版本号
|
文档操作历史 |
||||||
|
版本 |
日期 |
创建/修改人 |
变更描述 |
状态 |
||
|
1.0.0 |
20200110 |
XX |
|
新建 |
||
|
变更描述：新建、修改、增加 |
||||||
|
评审记录 |
||||||
|
评审时间 |
参与评审人员 |
评审结果 |
备注 |
|||
|
|
|
|
|
|||
|
|
|
|
|
|||
|
|
|
|
|
|||
|
|
|
|
|
|||
|
|
|
|
|
|||
|
评审结果：待修改、已通过 |
||||||
|
文档目录 |
||||||
2.文档应该流程图与文字相结合描述
3.需求简述
4.需求目标
5.需求背景
6.整体流程图，整体流程说明
7.各系统流程图，流程图说明
8.重点流程说明&原型
注意点 ：
尽量避免模棱两可的文字描述和流程图 ，不确定的地方需要单独标注，一起讨论解决
一些重点业务名词解释，一些常见问题体现
产品自评审阶段
整个文档复盘，是否有遗漏流程，进行补充