1.4 产品原型及需求文档

产品经理从用户需求出发，依据产品设计逻辑和流程将用户需求转化为产品原型和需求文档后，研发人员才能够根据产品原型和需求文档开始研发工作。所以，产品原型和需求文档既是产品设计流程的结果，又是产品研发流程的开始。

1.4.1 产品原型

原型图，也被称为线框图，是产品经理将用户需求转化为产品解决方案的重要载体，是产品经理与研发人员进行沟通的重要工具。根据原型图与真实页面的仿真程度，可以把原型图分为高保真、低保真两类；根据原型组件交互描述的详细程度，可以把原型图分为高精度、中精度、低精度三类原型图。

（1）两类保真度原型图。

高保真原型图在布局和画面上尽可能还原了真实的页面状况，能够很好地体现出真实效果，用户体验较好，但是实现成本较高，需要花费大量的精力和时间处理，适用于产品方案已经确定的阶段。低保真原型图布局和画面的仿真程度较低，有时甚至使用笔来简单勾画出草图，方便讨论和修改，适用于产品方案构思的初期。

（2）三类精度原型图

除了按照原型图对真实页面的仿真程度进行分类，还可以按照原型图交互细节描述详细程度进行分类，分为高精度、中精度和低精度原型图。

高精度原型图：高精度原型图详细展示原型中各组件的操作细节和交互细节，往往使用大量图文说明来描述产品细节和设计意图。

低精度原型图：低精度原型图使用页面流程图等简易方式，快速展示主要操作逻辑和流程，集中力量展示关键组件的展示逻辑。

中精度原型图：中精度原型图介于高精度原型图和低精度原型图之间，各个组件的操作交互细节描述的详细程度也介于两者之间。一般而言，典型的中精度原型图包括页面布局、导航栏、关键组件、文案说明等内容。

（3）两种分类的区别和联系

高保真、低保真原型图和高、中、低精度原型图既有联系又有区别。高保真和低保真原型图是以原型图对真实页面的仿真程度进行划分的，高、中、低精度原型图是以原型图组件操作交互描述详细程度进行划分的，两者的划分标准不一致，这是两者的区别；但是实践中，一般高保真原型图对于组件操作交互的描述也会特别详细，而低保真原型图为了满足快速交流的需求，仿真程度较低，同时组件交互描述也往往较为粗略，所以高保真原型图往往也是高精度原型图。

1.4.2 需求文档

产品设计是一个将用户需求由抽象概念转化为具象化产品的过程，经常需要借助文字或图像进行展现，这就是产品需求文档（Product Requirement Document，PRD）。PRD主要是给设计、研发等相关人员阅读的文档，目的是告诉这部分人员产品页面内容、交互规则和输出结果等详细信息，像是一份详细的产品功能需求说明书。

1．PRD概述

PRD是产品经理用来跟技术开发人员和其他相关人员进行沟通的辅助文本工具，由产品经理负责撰写。这里有两点需要注意。

第一，它是文本工具。这也就是说，相对于口头沟通，PDR能够使沟通过程和沟通意见落在纸上，同时也为后期沟通提供了文字记录，便于查询。

第二，它是辅助沟通的工具。PRD不是用来划分责任归属的，而是用来辅助沟通的。大量的沟通还是要通过产品经理和技术开发人员口头交流来完成，PRD只是把沟通的关键性结果做一个留档和备份，便于后期随时查询使用。

一般说来，一份完整的PRD至少包括3个部分：需求描述、功能描述和变更记录。

2．需求描述

需求描述是告诉技术开发人员和相关人员“为什么要设计开发这个功能”，是产品存在的基础和前提。很多产品会越设计越复杂、越设计越臃肿，就是因为产品经理设计添加产品功能时并没有严肃认真思考每个功能的需求情况，经常灵光一现随意增加产品功能。产品需求根据对象的侧重不同可以区分为：业务需求和用户需求。

业务需求：业务需要表达的是组织或客户高层次的目标。业务需求侧重描述组织为什么要开发该款产品或者希望通过这款产品达到什么目标，它通常表达的是项目投资者、产品购买客户等的需求。

用户需求：用户需求是指产品的功能满足了用户某个场景下的使用需求，解决了用户的某个问题。这主要是从用户角度来定义和阐述的需求，描述了用户能使用系统来做些什么。例如，用户需要对产品的全球销售情况有一个直观和宏观的印象，这就需要给用户提供一个可视化界面，直观地展示产品全球销售的关键信息点。

3．功能描述

功能描述规定了开发人员需要在产品中实现的软件功能，用户可以使用这些功能来满足其业务需求。功能描述既可以从人和系统的旁观者角度来描述，也可以从产品角度来描述。前者叫用例描述，后者叫功能点描述。实践中，功能点描述多采用在Axure原型图旁边注释的方式，而用例描述更多采用PRD方式来详细论述。

无论是用例描述还是功能点描述，其最终目的都是希望研发人员能够快速清晰地理解产品功能需求。所以，一般包括以下内容。

交互规则：交互规则是指使得产品元素状态发生改变的规则和规范，既包括用户交互规则，也包括元素状态自动变化的规则。例如，用户操作产品页面上各种交互元素和组件（筛选按钮、滑动条）使得产品状态发生改变；或者系统自动设定了元素状态变化规则，如电商平台自动设定了打折时效期，一旦过了该段时间，商品价格自动复原等。

数据规则：数据规则主要是指数据产品展现层与数据库进行数据交互的规则。例如，用户通过注册页面输入信息并存储在数据库中，那么就需要指明注册页面包括的字段、每个字段的类型及长度等内容。

4．变更日志

变更日志的编写并不复杂，但是一些产品经理常常因为怕麻烦而忽略了，这往往给产品研发带来不小的隐患。

产品需求变动其实是很正常的事情，但是如果需求变动没有及时记录，那么可能会出现这样的情况：产品经理想表达的是A，结果表达成了B，技术开发人员听到的是B，理解的内容却是C，最后因为客观限制把产品做成了D。如果及时把需求变动记录在PRD上，那么技术开发人员和产品经理沟通就不仅限于当时口头沟通的“一瞬间”，而是有了可以进一步细致讨论的基础和材料，使得双向细致的沟通成为可能。

另外，如果产品需求变动不及时记录，一段时间后可能会因为遗忘导致各种问题。现实中，很多时候产品需求发生了变化，产品经理即时与技术开发人员进行了沟通，但是忘记将变化结论记录在PRD中。一段时间后，产品经理或者技术开发人员可能就遗忘了这个变化，导致最后上线产品跟预期效果不一致。

最后，产品原型不可能一步到位。凡是有实践经验的人都应该深有体会，每次产品原型进行更改后，如果不及时记录更改的地方，技术开发人员肯定是“头大加火大”。因为他们完全不知道你修改了哪些地方。这些情况下，及时更新日志就显得很重要了。有了更新日志，大家一看日志就知道产品经理改了哪些地方，进而直接锁定修改目标，大大提升研发效率和开发进度。

因此，一个合格产品经理一定要养成及时记录变更日志的良好习惯，也要对变更日志给予足够的重视。