原型图一般会包括前台C端页面鲜活go小程序和B端管理后台页面两个大的部分，对于一些比较复杂的功能或产品，可能还会更多。
04.写好PRD的细节PRD的细节应该包括但不限于以下部分内容：需求背景、需求描述、具体功能点的流程图、WBS、页面及功能说明、交互接口、迭代记录、其它部分等。
4.1 需求背景
简单了说就是：现状是什么样，为了解决什么问题，期望达到什么目的。
- 现状：定性 定量描述当前遇到的问题，如50%的用户在注册页面跳出。
- 方案：所提供的解决方案概述，加入一键登录和手机验证码注册(登录)。
- 目标：3个月内注册跳出率降低至20%。
比较大的需求或功能可以展开了说，比如要阐述为什么要做这个需求，是新增的功能还是已有功能的优化和完善？是为了解决用户的哪些问题，满足用户的哪些需求？亦或者是公司高层的拍脑袋决策？
这个需求才做到什么程度，达到什么阶段性的目标？这样才便于PRD阅读者快速了解整个项目的梗概。
- 电商平台上线1年多以来还没有一套客观可量化的评价系统来对卖家进行约束、促进和规范。
- 电商平台：需要这样一套评价系统来了解经销商的真实经营情况和买家反馈情况，约束卖家诚信经营、督促其用心服务，提高服务水平和质量；同时也可以为后期搜索和推荐/排序等功能奠定基础。
- 买家端：可以根据评分和评价来选择卖家，进而督促卖家提高服务质量和配送效率，可以获得积分或虚拟货币奖励。
- 卖家端：可以帮助省级总经销商了解下级经销商真实的服务/配送情况，便于对下级经销商做评估和考核；同时也可以帮助经销商了解业务员、配送员真实的工作情况，便于发现工作环节中的缺陷和不足，进而对各职能部门进行约束、规范和促进。
4.2 需求描述
简单了说就是：到底做什么，有哪些大的功能模块或者通过哪些方式来实现前文业务背景里面描述的问题。此处的篇幅不宜过长，但需要通俗易懂，避免使用过多专业术语。还是以XX电商网的评价系统为例。
完成评价系统的基本业务模型搭建，运营平台可以查看经销商的所有评价信息和评价数据统计。
交易平台：
- 买家可以针对已完成订单进行评价。
- 买家可以查看评价、可以追加评价。
- 评价管理：卖家可以查看评价数据统计。
运营平台：
- 评价数据统计：可以查看全部经销商的评价数据统计。
- 评价内容管理：可以查看所有买家对卖家进行的评价和评论信息，可以按照名称或订单号、评价时间和满意度等信息进行筛选/搜索，可以对有图片的评论进行审核。
- 中长期目标：评价系统在具体业务中的运用，比如评分和评价内容在商品或者商家详情页显示，在搜索结果中影响排序结果等。
4.3 流程图
俗话说一图胜千言。有些功能无论你通过怎样的文字来进行阐述或者说明，都不如几张图来的简洁明了。产品经理在平时描述业务流程时常用的图有流程图、时序图，学有余力的话还可以了解一些泳道图、类图等。
下面是在XX电商网终端店用户在注册审批时用到的泳道图，仅供参考。
下面是货到付款订单增加买家取消功能用到的流程图，仅供参考。
4.4 WBS
WBS是工作分解结构Work Breakdown Structure的英文首字母缩写，其是项目管理重要的专业术语之一，WBS将交付成果和项目工作分解成较小的，更易于管理的组成部分的过程。
我之前项目上的WBS是长这样的，将所有的功能点罗列并形成表格形式，使阅读者对于此需求的功能点总体上有个基本的了解，以下是订单结算页优化的WBS。
4.5 页面及功能
PRD的主体部分，详细的描述此需求包含哪些页面，每个页面的布局，具备哪些功能和页面元素，每个功能的规则是怎样的。PRD的读者通过这部分的阅读，可以说基本清楚此次需求到底是做什么的，详细的规则是怎样的。
这个时候我们一般以页面为维度来进行详细的需求说明撰写，撰写的时候一般是从上往下从左往右的方式来写，如下图所示。
