在产品投入生产开发之前，所有的工作成果都以文档的形式体现出来，文档是新产品开发最重要、最有价值的工作内容，包括业务文档、市场文档、设计文档和功能细节，如图5-11所示。广义来说，产品文档包含产品战略和战术。策略是指:目标市场、客户定位、竞争对手、产品理念、价值主张、产品定位、商业模式等。战术是指竞争战略、产品创意、创新设计、产品结构、核心业务流程、具体用例描述、功能和内容描述等。
图5-11与产品设计相关的四个文档
1.商业文件
BRD业务需求文档是指基于业务目标或价值描述的产品需求的内容文档(报告)。其核心目的是在产品投入研发之前，将其作为决策和评估的重要依据。作为报告的撰写者，你必须让高层知道你的报告会展现出什么样的商业价值，如何以强有力的论据说服企业批准你的项目，并为其慷慨投入R&D资源和市场费用。如果说珠三角的质量直接决定了项目的质量水平，那么BRD的作用就是决定你项目的商业价值。优秀的BRD文档能让决策者完全被你的报告观点所吸引，也许财务总监会被报告中呈现的低投入高产出的经济效益预测所诱惑；也许技术总监会因为项目涉及面广而头疼；也许公司的副总裁因为这份报告看到了未来一年业绩快速发展的广阔前景…
BRD要求产品经理(产品设计师)充分利用市场调研、用户调研、需求分析等各种设计方法，对报告进行充分阐述。，就像珠三角一样。内容和格式要求直观精炼，要点突出。一般都是短小精悍，没有产品细节。产品经理通常需要将业务文档上报给决策者讨论。报告会的主要内容如下。
会议开始，产品经理是否应该先向与会领导介绍产品应该做什么？(解决了什么问题或者满足了什么用户需求)
你为什么这么做？说说背后的原因(背景，市场空，竞争对手，环境)
你要怎么办？(产品规划、模块规划、R&D计划、运营计划)
需要多少资源？(人工成本、硬件和软件成本、运营成本)
最后能得到什么好处？(带来收入，用户，拓展市场，抓住市场机会，满足未来三年的战略规划等。)
这样做有风险吗？(开发失败？失去市场机会？失去机会？但是竞争对手呢？没有收入？没有用户？与公司战略相悖？)
2.市场文件
MRD市场需求文档是一个产品项目从“准备”阶段到“实施”阶段的第一个文档，它的作用是“在市场层面解释一个产品”。本文档重点定义产品的市场、客户、购买者、用户和市场需求，并通过原型可视化。该文档的质量直接影响产品项目的开发和公司产品战略意图的实现。本文件在产品项目中起着承上启下的作用。“向上”是对积累的市场数据的整合和记录，“向下”是对后续工作的方向说明和工作指引。文件的主要内容如下。
市场描述:目标市场、市场规模、市场特征、未来3-5年发展趋势、当前市场存在的问题和机会。总的来说，我们在这里会得到一个有市场商业价值的结论。
l用户描述:分析目标客户的共性、共同的用户特征(要求准确:年龄、收入、地域、学历)，通过用户画像建立虚拟用户角色:可视化、用户名、用户技能、与产品相关的用户特征、示范场景、用户在时间地点完成的某件事的故事。从技术层面分析市场，通过对用户心理的案例分析，洞察影响用户使用的主要因素【张1】(动机和目标不一致)。
l产品定位:我们用什么样的产品来满足用户或用户市场；针对什么用户，做什么。
l产品价值:解决目标市场和用户的核心需求(核心价值具有最高优先级)。
l产品架构:整体结构，不是功能结构。它是产品的核心目标、市场定位和产品定位的直接体现。
l产品路线图:以时间为节点，以任务为导向。
l产品功能需求:用户注册、留言等。
l非功能性需求:有效性、性能、可扩展性、安全性、健壮性、兼容性、可用性、用户体验等。
3.设计文件
PRD产品设计文档就是把我们要做的事情变成一个清晰的“图纸”，让R&D的人员看到这个“图纸”，知道我们要做什么，需要做到什么程度，大概需要什么技术，并能对成本做出一个估算。不同平台、不同行业的产品设计文档不一样，但思路都差不多。以这里的网站为例，设计文档一般包括网站结构图、线框图、网页描述表。产品设计文档伴随整个产品生命周期，帮助产品团队与R&D团队和高层领导达成共识，然后定义R&D计划，指导R&D过程。不同的公司，不同的产品，会有自己不同的需求和模板，但是这里我想提醒大家一些需要注意的点。
l保持简短:对于产品设计文档来说，重要的是保持简短，因为越简短，包含的错误越少，越容易阅读，越有可能带来简洁的设计。但要在穷尽的基础上简洁，不要为了简洁而忽略一些细节。在产品设计中，每一个小细节对产品的质量都非常重要。所以一定要认真仔细的思考。
l消除错误:错误的文档会耗费R&D团队大量的时间，甚至会导致大规模的变更。在这个时候，没有人会为R&D感到高兴，而且一个接一个会想把你撕碎。有点夸张了。但心里肯定有一万个“操他妈的”！同时，这也会让产品团队在R&D团队面前看不起。当然，你也不必太在意。毕竟没有错误的文档，就像没有错误的代码一样，是不存在的。我们要做的是尽可能的消除误差，让误差变得可以承受。错误有很多种，包括产品逻辑错误(最致命的)，需求冲突的多个错误，错别字等级别的低级错误。在撰写产品设计文档时，产品团队应组织评审会议，对相应的产品逻辑进行充分的讨论和测试，并通过审批的方式进行检查。
l不对别人(主要是R&D人员)的工作指手画脚:就是不要在设计文件中提到一些技术性的东西。比如存储在数据库的新表中，连续存储，优化查询效率。不要提这样的要求，你很可能会在细节上犯一些错误。己所不欲，勿施于人，别人在你的领域里对你指手画脚，你会很恼火。如果是技术专家，可以私下交流。不要把应该写在技术文件里的东西写在设计文件里。
l以适当的方式表达需求:选择一种适当的方式来呈现特定的信息是产品经理的一项重要技能，在面对R&D团队和最终用户时应该用到。如何把我们的要求表达出来，让R&D或者客户能够快速有效的理解，这一点非常重要，不仅可以提高工作效率，还可以避免很多因为理解不当而导致的错误。理解不一致是常见的错误，不同领域的人要求理解不当也是常见的。选择恰当的表达方式非常重要。比如用叙述性的文字说不清楚，我们就会用表格或者其他东西，有时候还需要选择一些图形工具。
l使用肯定性语言:在产品设计文档中，使用肯定性、确切的语言，不要使用“也许、可能”等词语。我们提交的最终文件都是确切的、可执行的，所有模糊的东西都要剔除。如果有你不确定的事情，在做决定之前把它放在房间里充分讨论。
l不要忽视沟通:很多产品新人在写产品设计文档的时候都是埋头工作，写完之后再出去沟通，这样有99%的概率文档会被大幅修改，相当于做了无用功。所以，在写设计文档的时候，不要忽视与团队的沟通。
4.详细功能
FSD功能规范定义了产品功能需求的所有细节，是一个可以直接让工程师创建产品的文档。FSD基于BRD、MRD和PRD。从这一步开始，它开始与发展挂钩。产品UI和业务逻辑的细节要确定，文档要细化并保持更新。功能是对所有产品功能的描述和规划。以互联网产品为例，包括以下内容。
l简述:介绍这个功能的用途，包括它的来源或背景，能解决什么问题。
l场景描述:产品在什么情况下会被用户使用，即用户场景模拟。这也是产品经理讲“好”故事的必要条件。
l业务规则:每个[张2]产品在开发过程中都有相应的业务规则。应该清楚地描述这些规则，以便开发人员和测试人员可以直观地理解这些规则，而不会产生歧义。业务规则必须完整、准确且易于理解。如果业务规则描述涉及页面交互或页面修改，建议给出页面草图或页面截图，说明要修改的内容。此外，还建议说明页面的输入框和下拉框的内容格式、长度、控件之间的关联性，以及何时可见、何时不可见、灰显或亮起来的条件都在文档中说明。方便读者理解商业规则。
l界面原型:前面提到，说到页面交互，产品经理需要设计页面原型。原型设计通常需要产品经理和UI设计师协同工作。建议的做法是，产品经理可以设计一个页面框架，把页面上要呈现的字段，它们的特点，以及页面上要使用的场景，向交互设计师解释清楚。之后，交互和可视化设计师完成产品的原型设计。
用户描述:说明产品的用户，可以并入简要描述。
l前提条件:这个要求所依赖的前提条件。比如上传照片的时候，需要一个有图片的文件。
l后置条件:操作后触发的后续处理。
l主流程:把主流放在最后才有意义。结合以上，对主要流程做一个描述，对各个功能流程做一个逐点的描述(这个很重要)。
我看过很多prd(包括FSD)。文档中既没有前置条件，也没有后置条件，只解释了主要流程。但在描述主流程时，只有一个主趋势，让人感觉PRD成了操作手册。其实分支的引入很重要，开发和测试中提出的各种问题都和分支定义不清有关。一份合格的PRD不仅要描述主流程，还要阐述分流程中的各种问题，并给出解决方案。PRD的特点必须清晰全面的说明需求和各种异常情况的处理，而不是等到开发和测试阶段发现问题后才给出答案(虽然PRD不能100%覆盖所有可能性，但最大限度的思考所有业务问题是我们在编写PRD时必须遵守的原则)。另外，在描述功能需求时给出的方法中不能出现“可能”、“或者”等词语，必须是清晰准确的描述。如果有其他方案，建议写“备选方案”。产品构建初期的备选方案可以为功能实现提供更多的选择。方案确定后，可以在单据中注明这次使用哪个方案。
