产品经理成长系列（六）——产品设计之原型和需求文档-技术圈

产品原型是产品经理日常工作中必不可少的一样东西，画原型、讲原型基本会占据产品新人一天的绝大部分时间。

产品原型是将抽象的想法、需求转化为具象产品的过程。产品原型是开发、测试的指南。好的产品原型，能将产品功能一目了然地表达出来，提高了产品的开发效率，降低了团队之间的沟通成本。

现在的互联网节奏越来越快，越来越多的互联网公司采用了敏捷的开发方法。这时冗余而细致入微的需求文档会成为包袱，所以现在公司普遍的做法是将产品原型和需求文档合为一体。但这并不意味着需求文档就能直接被忽略，产品原型和需求文档应该是互相补充的关系。有时，原型不能很好表达出来的，可以用文档加以补充，比如订单的状态流转。而有时刚好相反，比如简单的交互动效。

对于绘制产品原型，很多产品经理都有一个误区，就是上来不管三七二十一就开始画。其实在正式绘制原型前，还是有一些必不可少的准备工作要干的，比如将需求转换成产品功能、梳理产品架构、整理业务流程、确定产品框架。

需求转换成产品功能。首先要将用户需求转换为一个个的功能点，按照功能模块进行分类，并用思维导图的方式呈现出来。

梳理产品架构。产品架构的梳理，之前已经专门写过了，具体的大家可以看《产品经理成长系列（六）——产品设计之产品架构》。

整理业务流程。对于业务流程的整理，能让产品经理完整的把控产品的业务逻辑。具体看《产品经理成长系列（六）——产品设计之业务流程》。

确定产品框架。绘制原型前的最后一步，就是把产品的大体框架确定下来，也就是产品的一级页面有哪些，二三级页面等待。

准备工作完成后，下面就开始正式绘制原型了。一般来说，产品经理绘制原型采用线框图的方式就可以了。

线框图是一种低保真度的设计产物，通常用灰黑白颜色来创建，它只描绘了基本的UI。线框图是产品的骨架结构，不要给其添加太多的细节。一般通过在线框图旁添加标注来加以补充说明。此处的标注也就相当于传统的需求文档，下面就具体说说这种需求文档应该包含哪些内容。

变更记录。在需求原型评审完之后，一般来说产品经理都会对产品原型进行修改（有的是产品逻辑考虑的不完整，有的是技术方案无法实现）。由于一个版本会包含很多的功能点，产品经理改动原型后不罗列出来的话，开发测试就很难发现其修改了哪些地方。

版本说明。主要用来说明该版本包含了哪些的主要功能。为什么要做这些功能？即描述需求的背景。

信息结构。将一个产品版本要做的功能点，用思维导图的方式罗列出来。不需要过分细致，不需要把页面中所包含的信息元素都一一罗列出来。

流程图。对产品经理来说，主要就是业务流程图。梳理流程，一方面可以帮助产品经理查看产品的功能逻辑方面有没有缺漏的，另一方面可以将需求内容以更直观可视化的方式呈现出来。

交互说明。原型中页面和控件的交互说明，主要包括交互动效，页面或控件点击后的跳转，控件的触发方式（点击、长按、左右滑动、上下滑动）以及操作前、操作中、操作后的变化，加载方式（自动刷新、异步加载、分页加载、手动刷新）。对于一些通用的交互说明，可以做个全局说明。

异常错误描述。用户在使用产品过程中，会触发一些异常或者错误流程，比如订单支付失败。常见的异常错误包含：网络异常，无数据，用户输入错误、系统崩溃。

状态。对于页面和控件来说，会存在一个默认状态、操作后的状态以及异常状态。比如意见反馈功能页面，默认状态是由几个内容输入项（反馈内容、反馈类型、图片、联系号码）组成的，操作后状态是反馈成功的提示，异常状态可能包括提交失败、输入内容不符合规范等等。

数据。数据包括内容的取值范围（比如订单列表取最近一年的数据）、字段的输入限制（手机号限制11位纯数字）、内容排序逻辑（时间排序、距离排列、评分排序、综合排序）、缓存机制、数据加载方式等等。

产品经理成长系列（六）——产品设计之产品架构

产品经理成长系列（六）——产品设计之业务流程