从零开始-产品需求文档(PRD)撰写
如何撰写PRD文档
如何撰写PRD文档撰写PRD（产品需求文档）是一个重要的过程，它有助于明确产品的目标、功能和特性。
以下是一个关于如何撰写PRD文档的简要指南。
一、概述（Introduction）在PRD文档的开头，应该提供一个概述部分，介绍产品的目标、市场定位和背景信息。
这是为了让读者了解产品的背景和关键信息。
概述部分应包括以下内容：1.产品的目标和目的：明确产品的主要目标和整体愿景。
2.市场需求：描述市场对产品的需求和机会。
3.用户群体：定义产品的目标用户和受众。
4.关键成功因素：列出产品成功的关键因素。
二、功能需求（Functional Requirements）在PRD文档中，功能需求是最重要的部分。
这部分应清晰地描述产品的功能和特征。
以下是编写功能需求部分的步骤：1.功能列表：罗列出产品的所有功能点，并对每个功能进行描述。
2.优先级排序：对每个功能进行优先级排序，以确定产品开发的重点。
3.用户故事：描述用户在使用产品时的场景和故事。
4.流程图：使用流程图或原型图明确展示产品的工作流程。
5.数据模型：定义产品使用的数据模型和数据库结构。
6.界面需求：明确产品的用户界面需求，如布局、设计要求、主题等。
三、非功能需求（Non-Functional Requirements）除了功能需求外，PRD文档还应该包括一些非功能需求，以确保产品的性能和质量。
以下是非功能需求的一些示例：1.性能要求：定义产品在不同场景下的性能指标，如响应时间、负载能力等。
2.安全要求：明确产品对于数据安全、用户身份验证等方面的要求。
3.可扩展性和可维护性：描述产品的可扩展性和可维护性，以便未来能够方便地进行更新和扩展。
4.兼容性：说明产品的兼容性要求，包括不同操作系统、浏览器、设备等。
5.可用性和用户体验：定义产品提供良好用户体验所需要的要求和指南。
四、项目计划和里程碑（Project Plan and Milestones）在PRD文档中，应该包含产品的项目计划和里程碑，以确定产品的开发时间表和关键日期。
产品需求文档(PRD)撰写方法
产品需求文档（PRD）撰写方法第一步：做好准备工作你要做的是一个让人无可争议的产品，为了做好他，你必须做好前期的准备工作。
你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。
你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。
这里有很多的工作需要你去完成,在“成功的产品背后”这篇文章中有详细的描述。
建立良好的交流也非常重要，它会影响着产品团队。
如果你的准备工作做的够好，你也会变得越来越有信心和说服力。
第二步：确定产品的目的任何一个好的产品都开始于一个需求。
你必须清楚的了解这个需求，你的产品如何达到这个需求。
产品经理需要提出一个清晰、简明的价值主张，让它很容易被接受，要让产品团队、管理人员、用户、市场人员清楚的明白这个产品到底是什么意图。
虽然这听起来很简单，但是也只有少数产品才有这样的价值主张。
考虑“velevator pitch ”(电梯间演讲、电梯行销)测试。
假设你在做电梯的时候遇到公司CEO，他问你产品的意图是什么，你能在电梯到达之前回答这个问题吗？如果不能，你就还有工作需要做。
也许是你的说明没有针对性，他可能表现出来和其他产品做的没有什么明显区别；也许你提出的观点不能和你的用户产生共鸣；也许你解决的是一个非常规的问题，可能你想应用一种技术。
这个价值主张可能需要满足公司的产品战略。
注意你不需要阐述太多的细节，从某些方面来说，一个有价值的观点应当是越简越好。
产品需求需要确切的指出这个产品发布的目标，同样的这个目标也有优先之分。
例如，你的目标可能是：1）易用，2）零售价不足$100，3）和前期产品很好的结合。
然后你需要说明如何去测算。
对于“易用”这类项目，你需要明确指出产品可用性达到某个水平。
这是通常用目标用户来定义。
可用性工程师能测算出你的产品对目标用户的可用性，也测算出可用性问题的严重程度，同样你可以说明没有重大的可用性问题。
prd需求文档 实例撰写指南
prd需求文档实例撰写指南以prd需求文档实例撰写指南在软件开发过程中，产品需求文档（PRD）是一个关键的文档，它描述了产品的功能、特性和用户需求。
撰写一份清晰、准确的PRD对于项目的成功至关重要。
本文将为你提供一份PRD需求文档实例撰写指南，帮助你准确地表达产品需求。
1. 引言在引言部分，你需要描述产品的背景和目标。
包括产品的名称、定位、目标用户以及市场需求等信息。
同时，还可以简要介绍项目的目标和项目团队的组成。
2. 需求概述需求概述部分是对整个PRD的概括性描述。
你需要阐明产品的核心功能和主要特点，以及解决的问题和优势。
同时，还可以列举产品的关键功能点，以便读者能够快速了解产品的主要特点。
3. 功能需求功能需求部分是PRD的核心内容，描述了产品的各个功能点。
每个功能点需要清晰明确地描述其作用、目标用户、操作步骤以及相关的输入输出。
同时，还可以提供一些使用场景或示例，以帮助读者更好地理解功能点的用途。
4. 非功能需求非功能需求部分描述了产品的性能、可用性、安全性等方面的要求。
例如，响应时间、并发用户数、数据安全性等。
这些非功能需求对于产品的性能和用户体验至关重要，需要详细描述清楚。
5. 用户界面设计用户界面设计部分描述了产品的界面风格、布局和交互方式。
你可以使用文字描述界面的整体风格，以及各个界面元素的位置、尺寸和样式。
同时，还可以使用示意图或线框图来辅助描述界面的布局和交互方式。
6. 数据需求数据需求部分描述了产品对数据的要求。
包括数据的类型、格式、来源以及处理方式等。
你需要清晰地描述产品需要的数据，并提供数据示例或数据字典，以帮助读者更好地理解数据需求。
7. 运行环境运行环境部分描述了产品的部署和运行要求。
包括操作系统、硬件配置、网络环境等信息。
你需要清晰明确地描述产品的运行环境要求，以便项目团队能够按照要求进行开发和测试。
8. 需求优先级需求优先级部分描述了各个需求的重要性和紧急程度。
你可以使用描述词汇如“高优先级”、“中优先级”和“低优先级”来表达需求的优先级。
如何写PRD(产品需求文档)
如何写PRDPRD是每个产品人员最经常看到的文档，还是有很多产品的朋友问我PRD怎么写，如何才能表达清楚意思。
其实PRD并没有规定的格式，每个公司都可以根据自己公司的实际需要来写适合自己产品团队的PRD。
PRD（Product-Requirement-Document，产品需求文档），这对于任何一个产品经理来说都不会陌生的一个文档，一个PRD是衡量一个产品经理整体思维的标准，一个PRD可以看出一个产品经理在某个领域的专业性，同时也可以反应出一个产品经理的整体产品思维。
产品经理的整体思维体现在：1、提炼核心需求2、思考满足核心需求的方式3、评估方式优劣选定方案4、思考功能概要5、思考支撑功能和关联功能6、细化设计功能7、子功能（功能间迭代）PRD其实就是将以上的思维整体走向写出来，同时将产品的思想提炼出来，用文字表示给开发者，给UI、给视觉、给老板……PRD给的是一种思想，将产品的整体思想和核心需求灌输给产品的相关人员，都说PRD是个承上启下的功能，因为上接MRD，下对MRD进行技术性的描述。
网上已经有太多互联网公司的PRD文档，淘宝、百度、腾讯等这类大型互联网公司都有自己的PRD规范，适合企业的需要的PRD才是真正PRD。
以淘宝的PRD为例，讲解一下PRD的主要内容。
1、文件命名（编号）文件的编号很关键，因为产品迭代过程会有不同的文件版本，一般命名规则“公司名+产品名+PRD+D1.0”（以第一版为例），这样命名有利用版本号的迭代，如果是小的产品需求变动可以直接命名为“公司名-产品名-PRD-D1.01”，如果涉及到功能需求增加可以命名为“公司名-产品名-PRD-D1.1”，当出现产品第二版时，可以命名为“公司名-产品名-PRD-D2.0”。
2、修订控制页一般有这么几项：编号、文档版本、修订章节、修订原因、修订日期、修改人。
编号只是为了给个修改的顺序，文档版本显示的当前修改的内容是在哪个版本中出现，修订章节是具体到哪个章节哪个功能模块的修改，修订原因说明此功能修改的问题所在。
产品需求文档(PRD)的写作方法
产品需求文档(PRD)的写作方法无论我们做什么事都讲究方式方法，写产品需求文档(以下称PRD文档)也是如此，之前我通过五篇文章分享了自己写PRD文档的一些方法，而这一篇文章主要是对之前五篇文章进行整体的摘要介绍，帮助大家快速了解写作流程。
产品需求文档(PRD)的写作五篇章：1、写前准备(信息结构图)2、梳理需求(产品结构图和用户流程图)3、原型设计(手绘原型,灰模原型,交互原型)4、撰写文档(PRD文档)5、用例文档(UML用例图、流程图)1、写前准备(信息结构图)：在写PRD文档之前，我们需要先罗列出产品功能的信息内容，这一步是将想法逐渐清晰的第一步，也是帮助我们接下来规划功能的辅助信息，同时也可以辅助服务端技术人员创建数据库。
因为这是第一步，所以我们不需要罗列的很详细，在之后的步骤里，我们会逐步改进和完善信息内容。
例如一篇文章的信息内容主要有：文章标题、文章正文、文章作者、发布时间、所属分类。
初始的功能需求只有这些信息内容，但是在之后的功能规划中逐渐更加细致的考虑时，可能会增加或者删减，因此第一步我们不用刻意的追求信息的全面。
罗列信息内容的方式有很多种，文本形式、思维导图形式等等都可以，最主要的是能够清晰易懂，我最常用的方法就是思维导图，因此我称这一步为信息结构图。
2、梳理需求(产品结构图和用户流程图)：当我们对产品的信息结构了解后，我们就需要规整脑海中的产品需求，让想法更加结构化，因此这一步是梳理产品的需求。
我们首先要罗列出产品的频道及页面(产品结构图)，其次再基于产品结构图梳理出频道及页面中的功能，并延伸构建出用户的操作流程(用户流程图)。
以上两步是为了让我们在撰写产品需求文档之前能够对产品有一个全面的了解，类似鸟瞰式的一目了然，也方便调整完善。
3、原型设计(手绘原型,灰模原型,交互原型)：当我们逐渐清晰了产品的需求后，并梳理了产品的各个频道及页面，那么这一步就要开始验证这些想法的具体界面表现和方案的可行性了。
prd文档编写
prd文档编写PRD文档编写概述PRD（Product Requirement Document）是产品需求文档的缩写，是产品研发过程中最重要的文件之一。
PRD主要用于记录产品的功能需求、用户需求、市场需求、技术需求等信息，以便于团队成员在开发过程中对产品进行准确的理解和开发。
PRD编写的目的是为了明确产品的核心功能和用户需求，以便于团队成员在开发过程中有一个共同的目标，并且能够根据PRD进行开发和测试。
同时，PRD也可以作为与客户沟通和协商的重要工具，帮助客户更好地理解产品。
PRD编写流程1. 收集需求在开始编写PRD之前，需要收集各方面的需求信息。
包括市场调研、用户调研、竞品分析等。
通过这些信息可以更好地了解用户对产品的期望和市场上同类产品的优劣势。
2. 确定核心功能在收集完各方面的需求信息后，需要确定产品的核心功能。
这些功能应该是满足用户需求和市场竞争力所必须具备的。
同时也需要考虑技术可行性和开发难易度等因素。
3. 编写PRD文档在确定了产品的核心功能后，需要开始编写PRD文档。
PRD文档应该包括以下内容：（1）产品概述：包括产品名称、定位、目标用户、市场需求等信息。
（2）功能需求：包括产品的核心功能和次要功能，以及各种功能的具体描述和实现方式。
（3）用户需求：包括用户对产品的期望、使用场景、使用习惯等信息。
（4）市场需求：包括市场上同类产品的优劣势分析、竞争对手分析等信息。
（5）技术需求：包括开发工具、技术架构、数据结构等信息。
4. 审核和修改完成PRD文档后需要进行审核和修改。
审核人员应该是团队成员中的高级开发人员或者项目经理。
他们应该对PRD文档中所有内容进行仔细审查，并提出修改意见。
修改意见需要及时反馈给编写者，以便于尽快完成PRD文档的最终版本。
5. 发布完成审核和修改后，PRD文档可以正式发布。
发布后需要通知团队成员，并且将PRD文档作为开发过程中的重要参考文件之一。
PRD编写注意事项1. 确定清晰明确的产品目标和用户需求PRD文档的核心是明确产品的目标和用户需求。
产品需求文档PRD的写作方法
产品需求文档PRD的写作方法产品需求文档（Product Requirement Document，简称PRD）是产品开发的核心文档之一，它是产品经理对于产品特点、功能需求以及设计要求的详细描述。
一个好的PRD可以帮助产品团队清晰明确地了解产品的目标和需求，从而更好地进行开发和交付。
下面是PRD的写作方法：1.确定产品定位：首先需要明确产品的定位和目标用户群体，包括产品的市场定位、目标用户的特点、产品的核心竞争优势等。
这些信息将为后续的功能定义和设计提供基础。
2.产品目标和需求分析：在明确产品定位后，需要明确产品的目标和需求。
这包括产品的核心功能、操作需求、性能要求等。
可以通过用户访谈、竞品分析等手段来收集用户需求和评估市场需求。
3.功能定义：基于产品目标和需求分析，产品经理需要明确每个功能点的定义和详细描述。
可以采用用户故事的方式来描述功能，即从用户的角度来描述每个功能点所解决的问题和带来的价值。
4.产品设计：在明确功能需求后，产品经理需要与设计师和工程师合作，进行产品的界面设计和架构设计。
界面设计需要根据用户喜好和用户操作习惯来进行，架构设计需要考虑产品的可扩展性和性能。
5.数据定义：产品可能需要存储和处理大量的数据，因此需要明确产品的数据需求和数据模型。
这包括如何收集数据、存储数据以及对数据进行分析和展示等。
6.项目规划：在产品需求明确后，需要对项目进行规划和时间安排。
产品经理需要搭建项目团队，明确开发阶段和交付时间，并及时跟进项目的进展。
7.风险评估：在PRD中需要对可能遇到的风险进行评估和应对策略的制定。
风险评估包括市场风险、技术风险和运营风险等。
8.PRD的版本控制：在产品开发过程中，需求可能会发生变化，因此需要对PRD进行版本控制，以便于团队成员及时了解需求的变动。
9.PRD的沟通和协作：PRD是产品开发过程中的核心文档，因此需要与团队成员进行及时有效的沟通和协作。
产品经理需要与设计师、工程师、测试人员等团队成员交流和协商，确保需求的准确理解和实施。
如何写PRD(产品需求文档)
PRD不同于SRS（System Requirement Specification），SRS是系统需求分析说明书，是以相当技术化的语言撰写的，主要给研发人员看的。
2.2.2 Goal 目标是什么
产品定义是产品管理的核心工作。
通过产品定义：
使得公司内部所有与业务相关的部门（高层领导、研发、销售、支持等部门）都能基本清楚我们到底要做什么产品，从而统一大家的思想和行动。
产品定义的PRD文档，为研发部需求分析组接下来出SRS文档提供了基本依据。
2.2.3 How 怎么做
产品管理部门根据市场研究结果，和各个业务相关部门沟通，发挥自己的创造力来进行产品定义工作。
如何写PRD（产品需求文档）
文档分为两轮
第一轮：
1，文档使用方：UI设计师
2、内容：
.根据战略层定义出来产品功能范围，
.说明此产品的目的，方便UI设计人员更好的理解产品
.产品基本流程
.详细的设计框架图，推荐用axure,简单效率高
.详细文案
3、格式：
html，visio，或word，如果PS用的不熟练，不推荐使用，会影响工作效率。
上面是要UI设计人员出来高保真原型图，
第二轮：
文档使用方：开发人员
用高保真原型图来对开发人员写技术需求说明
有了高保真原型图，开发人员看的最明白，我们只需要写好详细的逻辑功能结构和详细的流程图
2.2 产品定义 Product Definition
2.2.1 What 做什么产品定义，即定义产品到底要做成什么。一般来说，比较正规的做法是撰写一份称之为 PRD（Product Requirements Document）的文档，该文档一般可以包括以下内容：
如何编写产品需求文档(PRD)
如何编写产品需求文档（PRD）PRD是Product Requirement Document的简称，翻译为：产品需求文档。
该文档是产品由“概念化”阶段进入到“图纸化”阶段的最重要的一个文档。
编写PRD是一个产品经理最为基础的工作内容，也是一个产品经理最基础的能力。
不夸张的说，通过一篇PRD文档就可以体现出一个产品经理的基本功是否扎实，这直接影响到整个研发团队的效率。
我常年从事To B系统产品的工作，因此本文的内容也仅针对To B系统的PRD文档，并不完全适用To C的系统产品。
想写出一篇优秀的PRD文档，需要搞清楚如下4个问题：1.PRD文档的编写目的是什么？2.PRD文档在编写前需要做什么？3.PRD文档在编写的过程中有哪些是需要注意的？4.PRD文档编写完成后如何使用？一、PRD文档的编写目的是什么编写PRD文档最为重要的目的就是：协调各个相关角色，将产品高效正确的“生产”出来。
PRD仅仅是为达到这个目标，产品经理经常使用的一种工具，只要是能够高效的完成最后的系统化产品，那么PRD具体的内容、形式也没有非常严格的标准。
从这个目标出发，我们能够看到这样几个关键词：各个角色、高效&正确和生产1.1 各个角色这里的角色是涉及到整个产品研发过程中全部相关的角色，每个角色在这个过程中负责的工作和关注点有所不同，PRD中需要照顾到所有参与角色的关注点，To B系统产品在此过程中主要涉及到的角色如下：●领导（产品总监等）：这个角色的人一般不会太过关注PRD的细节，重点会看一下，做这项工作的原因、解决问题的影响范围、成本、以及最终给客户和公司内部提供的价值。
当然，这些内容如果在PRD之前就使用其他的文档说清楚了，PRD 文档中就不需要写了，我也建议在PRD编写之前，通过产品提案等方式，把这些内容全部确定好，达成一致。
●UI&UX设计师：这个角色的人一般会重点关注在一些页面的元素上，设计师会根据页面的元素进行视觉和交互设计，所以，PRD中已经要写清楚页面的元素以及这些元素的含义，并且说明最终用户在页面上大大致操作过程。
PRD需求文档模板
PRD需求文档模板PRD (Product Requirements Document) 需求文档模板是一种用于记录产品需求的文档。
以下是一个可能的PRD模板，包括产品概述、用户需求、功能需求和非功能需求等部分。
1.产品概述产品概述提供了对产品的整体目标和作用的简要说明。
-产品名称：[产品名称]-产品目标：[产品目标的简要概述]-主要优势：[产品与竞争对手相比的主要优势]2.用户需求用户需求部分描述了产品应为用户提供的核心功能以及用户期望解决的问题。
-目标用户：[产品所面向的主要用户群体]-用户问题：[用户在使用类似产品时遇到的问题]-解决方案：[产品将如何解决用户问题，提供哪些功能]3.功能需求功能需求部分列出了产品的具体功能或特性，以确保产品能够满足用户需求。
-功能1：[功能的具体描述]-子功能1：[功能的子功能1]-子功能2：[功能的子功能2]-功能2：[功能的具体描述]-子功能1：[功能的子功能1]-子功能2：[功能的子功能2]4.非功能需求非功能需求部分描述了产品的性能、可用性、安全性等方面的要求。
-性能要求：[产品的性能要求，如响应时间、处理能力等]-可用性要求：[产品的可用性要求，如易用性、用户界面友好性等] -安全性要求：[产品的安全性要求，如对用户数据的保护等]5.约束和限制约束和限制部分说明了在设计和开发产品时需要遵守的约束条件和限制性要求。
-时间限制：[产品的上线时间限制]-技术限制：[在开发过程中可能遇到的技术限制]-资源限制：[在开发过程中可能遇到的资源限制]6.使用案例使用案例部分描述了产品的典型使用场景，以便开发团队更好地理解用户需求。
-使用案例1：[使用案例的详细描述，包括用户角色、行为和期望结果]-使用案例2：[使用案例的详细描述7.需求优先级需求优先级部分提供了对各个需求的优先级排序，以帮助团队在开发过程中确定重点。
-需求1：[需求描述]-优先级：[高/中/低]-需求2：[需求描述]-优先级：[高/中/低]请注意，以上是一个可能的PRD模板，具体的需求文档根据产品和项目的实际情况可能会有所不同。
正确的写产品需求文档(PRD)
正确的写产品需求文档（PRD）宗旨：通过工具—把思想有逻辑、有细节的合理的组织到一起！互联网行业，蓬勃兴起，很多从事产品工作。
不管是生手、新手、老手还是高手，我也想和大家分享一下产品需求文档的一些心得，希望能帮助大家(pa/pm)更好的提高自身水平、提高工作效率。
我这里只是简单的从需求的实施环节进行描述。
之前的需求的调查、需求的获取、需求的比较分析取舍等等都不再阐述了。
1、熟悉项目发生的相关业务行为。
言下之意，就是说：我们要做的是什么项目，我们这个项目主要是做什么业务，具体业务我们怎么通过更合适的框架、平台去实现它、支撑它。
简而言之，得要求：面向业务（对象），进行业务行为（设计），也是需求的开始，推荐工具：Ration rose ★★★★说明：通过use case 可以很容易，很清晰的将整个业务员系统直观、规范的表达出来，按照模块建立各个package,从而将复杂的业务通过case直观的表现出来。
工程师看的明白、产品人员也看得明白。
2、将业务，从产品层面肢解开来，做到抽丝剥茧部分与整体统一很笼统的说，就是；流程问题流程就是逻辑，你只有制定合理的、符合业务实际情况。
符合系统实现（可实现、容易或稳定实现）的流程，才会更好支持日后的业务系统和管理系统服务实际的业务。
不管是进销存、还是SAP原理其实都是相通的。
推荐工具：Visio 2007 ★★★★★说明：Visio是个老掉牙的工具了，从微软手里出到了07版本，它该有的模型都有了，通过visio 你可以直接的把整站流程框束在文档上。
不论你开发怎么样的系统，需求什么样的环境，都可以一一标明出来。
你的流程图的好坏直接会影响工程师实现你指定产品的实现方式。
所以强调一点，产品人员要熟悉计算机开发，熟悉人机交互，熟悉一些常用的开发方式，这样有助于很好的和团队做融合，更好的框架更容易扩展。
3、把项目条目化，条理化，目录结构具体规定好。
有了上面主要的CASE和流程的保障，接下来就应该要从系统的功能方面做条目化的规划制定了。
新版从零开始-产品需求文档(PRD)撰写.pdf
1、写前准备(信息结构图)在写PRD文档之前，我们需要先罗列出产品功能的信息内容，这一步是将想法逐渐清晰的第一步，也是帮助我们接下来规划功能的辅助信息，同时也可以辅助服务端技术人员创建数据库。
因为这是第一步，所以我们不需要罗列的很详细，在之后的步骤里，我们会逐步改进和完善信息内容。
例如一篇文章的信息内容主要有：文章标题、文章正文、文章作者、发布时间、所属分类。
初始的功能需求只有这些信息内容，但是在之后的功能规划中逐渐更加细致的考虑时，可能会增加或者删减，因此第一步我们不用刻意的追求信息的全面。
罗列信息内容的方式有很多种，文本形式、思维导图形式等等都可以，最主要的是能够清晰易懂，我最常用的方法就是思维导图，因此我称这一步为信息结构图。
当我们初次接触产品需求文档时，首先会从网络上寻找产品需求文档模板，希望从中了解和学习具体的写作要求，但实际上，现在网络上绝大部分的PRD文档都是与实际工作不相符的，或者说是复杂的。
前几天一位从事产品类工作的朋友，发来一份他写的产品需求文档目录截图给我(下图)，当时我就郁闷了，这些类目更像是MRD文档，而不是PRD文档了，因此我决定写几篇讲述写作PRD文档的文章，分享一些我关于PRD文档的见解和写作方法。
PRD是英文Product Requirement Document的缩写，中文的意思是产品需求文档，具体的名词介绍大家可以询问Google。
PRD文档是基于BRD、MRD的延续文档，主要用于产品设计和开发使用，因此阅读这份文档的人群绝大多数是设计与技术人员。
在这类人群中，设计师更多依赖于原型进行交互或视觉的设计，因此看这份文档的人就会偏向于技术人员。
相对于技术人员，他们不太关注产品的商业需求和市场愿景，因为在进行产品讨论立项时，产品的定义就已经向参与设计和研发的人员宣讲过，因此技术人员更多的是关注界面、功能、交互、元素等等内容，因此PRD文档是一份详细的产品功能需求说明文档，是产品文档中最底层和最细致的文档。
prd的撰写
prd的撰写如何撰写一份高质量的产品需求文档（PRD）产品需求文档（PRD）是产品开发过程中至关重要的一环，它起到了桥梁的作用，连接了产品经理、设计师、开发人员等各个角色。
一份好的PRD应该准确地描述产品的需求和目标，以及实现这些需求和目标的方法和计划。
本文将介绍如何撰写一份高质量的PRD。
一、概述在PRD的概述部分，需要明确产品的名称、版本、所属领域、目标用户群体等基本信息。
同时，也要简要描述产品的背景和目标，以便读者能够快速了解产品的背景和意义。
二、需求分析在PRD的需求分析部分，需要对产品的需求进行详细的分析和描述。
首先，要明确产品的核心功能和特点，以及它们对用户的价值和意义。
然后，根据用户调研和市场研究等数据，结合用户需求和竞争对手的分析，确定产品的功能需求和非功能需求，并进行详细的描述。
在描述需求时，可以使用恰当的段落和标题，使文档结构清晰、易于阅读。
三、用户界面设计在PRD的用户界面设计部分，需要对产品的用户界面进行详细的设计和描述。
首先，要明确产品的整体界面风格和布局，以及各个界面元素的设计原则和规范。
然后，根据产品的功能需求和用户调研等数据，进行详细的界面设计，并给出相应的界面原型图和交互流程图。
在描述界面设计时，要注意使用丰富的词汇和准确的语句，以确保信息的准确性和清晰度。
四、技术实现方案在PRD的技术实现方案部分，需要对产品的技术实现进行详细的描述和规划。
首先，要明确产品的技术架构和技术选型，以及相应的开发平台和工具。
然后，根据产品的功能需求和非功能需求，规划产品的开发计划和进度，确定相应的开发任务和资源分配。
在描述技术实现方案时，要注意避免使用公式和复杂的技术术语，以确保文档的易读性和理解性。
五、测试与验收在PRD的测试与验收部分，需要对产品的测试和验收进行详细的规划和描述。
首先，要明确产品的测试策略和方法，包括功能测试、性能测试、安全测试等。
然后，根据产品的功能需求和非功能需求，编写相应的测试用例和测试脚本，进行测试环境和测试数据的准备。
产品需求文档(PRD)撰写方法与技巧
五、Axure原型图描述功能
在Axure编辑界面，选择要说明的元件，然后键入你要说明的内容
发布以后，鼠标点击黄色描述标签，就能形象化的在功能中看到具体的需求表述了哟 ！
六、Axure说明到处成为Word文档
Axure导出说明文档，需要产品经理对Axure默认的导出规则有一些了解，然后再制作原型需求 图的时候，就要考虑到Word导出后的一些规则，需要摸索一下，熟练以后，还是很好用的。
产品需求文档（PRD）
的撰写方法与技巧
2019年11月17日
产品需求文档（PRD）写作方法与技巧学习目标
• 深刻理解三大文档的写作目的与应用场景 • 理解并掌握PRD文档的用途与作用 • 理解并掌握PRD文档：
– 写作思路 – 写作方法 – 写作格式
一、什么是PRD文档
• 产品需求文档(Product Requirement Document，PRD)的英 文简称
• A路线：妖怪多 • B路线：神仙多 • C路线：美女多 • 经过分析，唐僧决定选择C路线，所以才有了三打白骨精，路过女儿国等经典故事（开个玩笑）
• PRD-获得了授权，而且已经确定了要走的路线，剩下的就是打造装备（产品）了
– 要把装备的需求给工匠（研发人员），就需要把你（PM）对装备（产品）的要求讲清楚 • 金箍棒（需要能缩短到耳朵里面，直径1毫米，长度6毫米，需要金色，重量必须控制在1KG） • 九齿钉耙（必须要9个齿，废话啊，黑色，齿长8里面，把手长1.5米，直径2.5厘米） • 于是工匠（研发人员）根据需求，打造出了旷世的武器
• BRD>MRD>PRD是一个逐步论证并得出结果的过程，是产品经理思维升华的过程， 是这三个文档三位一 体的过程。
三、PRD文档面向的对象
产品需求文档(PRD)—初级篇
NO.1 产品需求文档（PRD）概述PRD是英文“ProductRequirement Document”的缩写，翻译为中文就是“产品需求文档”，主要用于完整描述产品需求，向研发部门明确产品的功能和性能以及作为产品文档归档。
PRD的面向对象是：产品经理：可以通过产品功能描述自查清单来系统的梳理产品功能点和描述，更加透彻和完整的梳理产品；同时，产品经理可以通过PRD和其他人员进行高效的沟通。
交互设计师：通过功能点及其描述自查来检查自己的交互稿是否遗漏特殊情况、异常情况、极限情况等。
开发工程师：检查自己的程序开发是否符合PRD中的相关要求。
测试工程师：PRD中的功能描述和用例转化为测试用例的一部分，进行产品可用性测试。
NO.2 PRD的主要内容一份完整的PRD文档主要包含两部分内容：一是对项目的介绍，包括项目概述、项目价值、项目背景、词汇表、运营计划等；二是整份文档的主体部分，对产品需求的详细描述，包括功能需求和非功能需求等。
NO.3 产品功能的描述用户界面和功能描述是PRD最重要的两个部分，用户界面主要是以产品原型作为载体，用直观图形的形式展现产品的功能，功能描述则是在用户界面的基础上，以文字的形式诠释产品功能的细节，使开发人员更清晰地明白产品功能性能的要求。
对产品功能进行描述，一般需要两个步骤：第一， 梳理产品功能描述部分的整体结构，有规律地将产品功能分成多个较小的功能单元。
比如，在产品功能具体的分解时，可以按功能在系统中的位置、按业务流程、按功能主次、按功能所处界面位置等进行分解。
第二， 以用例的形式描述分解后的产品功能。
用例指的是在不展现系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。
它的好处是可以将产品功能需求与产品设计彻底分离，不用考虑具体的系统设计与技术细节。
下面是一个关于“会员中心”用例图的展现形式：除了用例图，还需要一个与之对应的用例表，规范的用例包括用例名称、用例编号、角色、描述、基本流程、备选流程、异常流程、后置条件、备注等。
prd撰写技巧
prd撰写技巧PRD（产品需求文档）的撰写是产品开发过程中的关键环节，它详细描述了产品的功能、特性和需求。
以下是一些撰写PRD的技巧：1. 明确目标与受众：在开始撰写PRD之前，明确文档的目标和受众。
不同的受众（如开发人员、测试人员、项目经理等）需要不同详细程度的信息。
2. 使用清晰、简洁的语言：避免使用模糊或行业特定的术语，使用简单易懂的词汇，确保团队成员能够快速理解。
3. 结构化内容：PRD应该有清晰的章节和结构，例如概述、产品功能、非功能性需求、数据要求等。
4. 定义用户流程与界面细节：描述用户如何使用产品，包括流程图和界面细节（如布局、按钮、输入字段等）。
5. 详细说明功能需求：对于每个功能，列出其目的、输入、处理逻辑和输出。
对于复杂功能，可以添加流程图或屏幕截图来辅助说明。
6. 考虑异常情况：除了正常流程，也要考虑异常和错误情况的处理方式。
7. 说明性能和安全要求：如果产品有性能或安全方面的要求，应在PRD中明确说明。
8. 保持更新：当产品需求发生变化时，及时更新PRD。
确保团队成员始终使用最新版本的文档。
9. 征求反馈：在完成初稿后，向相关团队成员（如设计师、开发人员等）征求反馈，以便进一步完善PRD。
10. 使用版本控制：对于大型项目，建议使用版本控制工具（如Git）来管理PRD的多个版本。
11. 遵循规范格式：遵循公司或团队的规范格式，使PRD更加专业和易于阅读。
12. 不断迭代与优化：根据项目进展和团队反馈，不断优化PRD的结构和内容。
遵循这些技巧，可以帮助您撰写出更准确、专业的PRD，从而更好地指导产品开发工作。
产品需求文档PRD模板
产品需求文档PRD模板1.产品概述1.1产品介绍：简要说明产品的功能、用途和目标用户。
1.2产品目标：明确产品的核心目标，并制定相应的指标以衡量产品的成功。
1.3产品背景：解释产品的市场背景和竞争环境，以及推动产品开发的原因和动机。
2.用户需求分析2.1用户群体：描述产品的目标用户群体，包括其特点、喜好和需求。
2.2用户痛点：总结用户在当前情况下面临的问题和困扰。
2.3用户需求：列出用户对产品的期望和需求，尽可能具体明确。
3.产品功能需求3.1核心功能：列出产品的核心功能，满足用户需求，并可衡量产品的成功。
3.2附加功能：列出额外的功能，增强产品的吸引力和竞争力。
3.3功能优先级：确定各个功能的优先级，以便在开发中进行合理的资源分配。
4.产品界面需求4.1用户界面：描述产品的用户界面，包括布局、颜色、样式等。
4.2交互设计：解释用户与产品之间的交互方式和流程，包括页面跳转、表单输入等。
4.3响应式设计：考虑不同设备上的界面适配和响应，如手机、平板电脑等。
5.数据需求5.2数据处理：说明数据如何被采集、储存、处理和展示。
5.3数据安全：提供对用户数据的保护措施，包括加密、备份等。
6.性能需求6.1响应时间：指定产品的响应时间要求，以保证用户有良好的使用体验。
6.2并发能力：描述产品需要支持的同时用户数量，以及相应的系统性能要求。
6.3系统稳定性：要求产品具有良好的稳定性和可用性，减少故障和停机时间。
7.非功能性需求7.1兼容性：描述产品与各种硬件、软件和操作系统的兼容性，以便用户自由选择。
7.2安全性：提供对用户数据和系统安全的保护措施，如权限管理、防火墙等。
7.3可维护性：要求产品易于维护和升级，以适应市场和用户需求的变化。
8.项目计划8.1里程碑计划：制定项目开发的里程碑，明确各个阶段的目标和时间节点。
8.2开发资源：确定项目所需的人员、设备和资金等资源，以保障项目的顺利进行。
8.3风险管理：列举可能的风险和问题，并提供相应的应对措施和预防计划。
从零开始-产品需求文档(PRD)撰写
1、写前准备(信息结构图)在写PRD文档之前，我们需要先罗列出产品功能的信息内容，这一步是将想法逐渐清晰的第一步，也是帮助我们接下来规划功能的辅助信息，同时也可以辅助服务端技术人员创建数据库。
因为这是第一步，所以我们不需要罗列的很详细，在之后的步骤里，我们会逐步改进和完善信息内容。
例如一篇文章的信息内容主要有：文章标题、文章正文、文章作者、发布时间、所属分类。
初始的功能需求只有这些信息内容，但是在之后的功能规划中逐渐更加细致的考虑时，可能会增加或者删减，因此第一步我们不用刻意的追求信息的全面。
罗列信息内容的方式有很多种，文本形式、思维导图形式等等都可以，最主要的是能够清晰易懂，我最常用的方法就是思维导图，因此我称这一步为信息结构图。
当我们初次接触产品需求文档时，首先会从网络上寻找产品需求文档模板，希望从中了解和学习具体的写作要求，但实际上，现在网络上绝大部分的PRD文档都是与实际工作不相符的，或者说是复杂的。
前几天一位从事产品类工作的朋友，发来一份他写的产品需求文档目录截图给我(下图)，当时我就郁闷了，这些类目更像是MRD文档，而不是PRD文档了，因此我决定写几篇讲述写作PRD文档的文章，分享一些我关于PRD文档的见解和写作方法。
PRD是英文Product Requirement Document的缩写，中文的意思是产品需求文档，具体的名词介绍大家可以询问Google。
PRD文档是基于BRD、MRD的延续文档，主要用于产品设计和开发使用，因此阅读这份文档的人群绝大多数是设计与技术人员。
在这类人群中，设计师更多依赖于原型进行交互或视觉的设计，因此看这份文档的人就会偏向于技术人员。
相对于技术人员，他们不太关注产品的商业需求和市场愿景，因为在进行产品讨论立项时，产品的定义就已经向参与设计和研发的人员宣讲过，因此技术人员更多的是关注界面、功能、交互、元素等等内容，因此PRD文档是一份详细的产品功能需求说明文档，是产品文档中最底层和最细致的文档。
产品需求文档范文(PRD)
产品需求文档范文(PRD)产品需求文档（P R D ）标题logo 项目名字部门名称提交日期产品提交人项目负责人当前版本号修改记录日期修订版本说明修改人项目成员项目角色姓名| | 邮箱| | 分机备注项目经理产品经理设计制作研发负责测试负责内容负责客服负责文档及培训负责定稿会签PRD 拟制人产品负责人需求方负责人设计负责人制作负责人开发负责人测试负责人技术部负责人最高决策人意见汇总PRD 拟制人意见汇总：产品负责人：需求方负责人：设计负责人：制作负责人：开发负责人：测试负责人：技术部负责人：最高决策人：文档目录1. 总体说明项目概述项目概述简单描述项目的背景、意义、目的、目标等，描述领域知识＃详细填写产品项目意图、目标等＃待开发的系统的名称；＃本项目的任务提出者、目标用户；＃该系统同其他系统或其他机构的基本的往来关系（如CRM CMS 用户中心。
）。
功能范围功能范围给出业务逻辑图，类似BUC：描述各角色的职责、与周边系统的关系、全局商业规则用户范围角色描述（涉及到的actor、system 的描述）＃描述本项目所服务的最终用户的特点，用户用例等；＃如存在管理用户充分说明操作人员、维护人员的教育水平和技术专长，及预期使用频度。
假定及约束假定及约束项目执行环节存在的影响项目质量、进度的事件列表及应对方案词汇表词汇描述（术语与缩写的描述）＃列出本文件中用到的本专业，个性定义，外文首字母组词的原词组等。
非功能需求需求描述数据监控针对一个功能模块级别的监控点，必填，并且功能上线 2 周后需要给出数据分析报告性能用户体验。
其他说明其他说明其他任何需要说明的内容参考资料参考资料列出关联资料或可参考网站2. 功能结构功能模块分功能模块功能点优先级功能模块名称 1 分功能模块名称 1 功能点名称1 1 功能点名称21 功能点名称3 1 3. 业务功能流程＃产品整体业务流程图4. 业务对象模型# 所有业务对象/实体对象的组成结构及描述 5. 业务对象状态模型＃有状态的业务对象状态、转换及描述 6. 用例场景用例整体说明序号用例编号用例名称简要描述1用例名称1 简要描述该用例的场景2用例名称2 简要描述该用例的场景3用例名称3 简要描述该用例的场景用例具体说明用例名称描述业务描述商业目标，用户目的等业务内容需求描述产品需求，需要实现哪些功能点行为者该用例的Actor 界面描述UI 示意图：页面名称Demo 截图1 # 可以标明参看原型对应的页面截图说明1 功能元素功能名称规则流程描述用例1 流程流程说明用例名称2描述业务描述商业目标，用户目的等业务内容需求描述产品需求，需要实现哪些功能点行为者该用例的Actor 界面描述UI 示意图：页面名称Demo 截图 1 # 可以标明参看原型对应的页面截图说明1 功能元素功能名称规则流程描述用例1 流程流程说明＃对单个用例的说明可以结合axure ＃注1：视觉层面的描述通常直接通过Demo 表达（如页面大小，颜色字体字号等）＃注2：界面细节，引用界面规范文档（如表格中的文字对其方式）＃注3：交互细节，引用交互规范文档（如出错提示的方式）＃注4：文案细节，引用文案规范文档（如各种提示文案）7. 风险规避＃项目的风险预估及风险规避方案。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1、写前准备(信息结构图)在写PRD文档之前，我们需要先罗列出产品功能的信息内容，这一步是将想法逐渐清晰的第一步，也是帮助我们接下来规划功能的辅助信息，同时也可以辅助服务端技术人员创建数据库。
因为这是第一步，所以我们不需要罗列的很详细，在之后的步骤里，我们会逐步改进和完善信息内容。
例如一篇文章的信息内容主要有：文章标题、文章正文、文章作者、发布时间、所属分类。
初始的功能需求只有这些信息内容，但是在之后的功能规划中逐渐更加细致的考虑时，可能会增加或者删减，因此第一步我们不用刻意的追求信息的全面。
罗列信息内容的方式有很多种，文本形式、思维导图形式等等都可以，最主要的是能够清晰易懂，我最常用的方法就是思维导图，因此我称这一步为信息结构图。
当我们初次接触产品需求文档时，首先会从网络上寻找产品需求文档模板，希望从中了解和学习具体的写作要求，但实际上，现在网络上绝大部分的PRD文档都是与实际工作不相符的，或者说是复杂的。
前几天一位从事产品类工作的朋友，发来一份他写的产品需求文档目录截图给我(下图)，当时我就郁闷了，这些类目更像是MRD文档，而不是PRD文档了，因此我决定写几篇讲述写作PRD文档的文章，分享一些我关于PRD文档的见解和写作方法。
PRD是英文Product Requirement Document的缩写，中文的意思是产品需求文档，具体的名词介绍大家可以询问Google。
PRD文档是基于BRD、MRD的延续文档，主要用于产品设计和开发使用，因此阅读这份文档的人群绝大多数是设计与技术人员。
在这类人群中，设计师更多依赖于原型进行交互或视觉的设计，因此看这份文档的人就会偏向于技术人员。
相对于技术人员，他们不太关注产品的商业需求和市场愿景，因为在进行产品讨论立项时，产品的定义就已经向参与设计和研发的人员宣讲过，因此技术人员更多的是关注界面、功能、交互、元素等等内容，因此PRD文档是一份详细的产品功能需求说明文档，是产品文档中最底层和最细致的文档。
PRD文档是一份没有闲话，直入主题的功能说明文档，因此我们在写作时，脑海里构思的是成品产品的界面功能的逻辑线框图。
在写作这份文档前，我们需要先做一些准备，把BRD、MRD的相关需求消化并融合规划出产品的结构图。
因为这些准备工作是属于思维类的，所以我推荐使用思维导图软件(MindManager)进行规划工作。
规划产品的第一步就是梳理出产品的信息结构，有了信息结构我们才能继续往下规划产品结构，并且信息结构是服务端技术人员创建数据库的依据，是数据结构的辅助文件。
对于新产品或者新功能，没有人能够比产品经理更加清楚所需要的信息内容了，因此第一步我们就需要先将这些信息罗列出来，形成结构化。
（如下图）这张图是以我的博客作为示例，在罗列信息结构时，我们更多的是考虑信息数据，因此在这一步，我们还不需要深入的考虑产品的界面与功能。
信息结构的考虑有面向前端的，也有面向后端的，具体视产品类型而定。
例如CMS之类的程序，这类程序采用框架式开发，将功能与模板独立，因此前端具有多变性，并且这类产品属于平台型产品。
针对这类产品，我们在规划信息结构时，只需要简单的考虑一些前端的功能需求，更多的是面向后端管理员操作进行考虑，从后端入手规划和罗列出所需要的信息内容结构。
无论是什么样的产品类型，无论从哪里入手，我们第一步都是先要罗列信息结构，因为信息结构图不仅是辅助技术人员创建数据库的图表，也是辅助产品人员进行产品功能规划的参考，只有对信息或数据的结构了解，我们才能玩转数据，玩转产品。
在信息结构转数据结构时，如果是针对已经存在的产品而增加的新功能，那么技术人员就需要根据这个信息结构进行数据库对比，已经存在的数据便直接调用，如果不存在，则就需要具体的讨论，确定新信息的使用途径和以后的扩展方向，以便确认是创建数据表还是创建数据字段。
（虽然产品经理不需要技术开发，但是如果能够懂技术原理和数据库原理，非常有助于产品规划和技术沟通。
）信息结构图是产品层面的理解，如果要入库这些信息，还需要进行数据结构的讨论。
一条信息的存储有很多附加属性，具体是存成字段还是数据表，还是说存在中间表或者关联表，这些都需要在完成PRD文档后和数据库技术人员共同讨论。
讨论时除了展示信息结构图，还要讲解产品原型和功能需求，以便数据库技术人员了解产品意图，方便他们做数据库规划时考虑到以后的扩展。
信息结构图是我们将概念想法形成结构化的第一步，也是我们接下来几步工作的辅助文件，同时在接下来的几步工作中，我们还会不断的完善信息的结构。
2、梳理需求(产品结构图和用户流程图)当我们对产品的信息结构了解后，我们就需要规整脑海中的产品需求，让想法更加结构化，因此这一步是梳理产品的需求。
我们首先要罗列出产品的频道及页面(产品结构图)，其次再基于产品结构图梳理出频道及页面中的功能，并延伸构建出用户的操作流程(用户流程图)。
以上两步是为了让我们在撰写产品需求文档之前能够对产品有一个全面的了解，类似鸟瞰式的一目了然，也方便调整完善。
首先我们要规划出产品的频道及子频道、子模块或子页面。
（如下图）图注：讲解一下我对于这个思维导图的名词理解1、频道：某一个同性质的功能或内容的共同载体，也可称为功能或内容的类别。
2、子频道：某频道下细分的另一类别3、页面：单个或附属某个频道或分类下的界面4、模块：页面中多个元素组成的一个区域内容，可以有一个或多个，也可以循环出现(例如:文章列表)5、模块元素：模块中的元素内容，以文章列表举例：文章标题、文章摘要、文章发布时间，这些都是元素，都是组成模块的内容，同时他们也是可以循环出现的。
元素的类型可以是：文字、图片、链接等等如果你学过网页设计，或者了解Web产品的模板机制，你就能够理解这些名词了。
如下图所示，这是我的博客的首页结构。
当我们规划出频道后，我们就需要以用户的视角进行一步一步的模拟操作，逐渐完善产品的结构导图。
我称为用户流程图，用于展现产品经理脑海中比较抽象的产品逻辑，也是产品经理对自己脑海中的产品想法进行梳理的一个过程。
（如下图示例）这样做的目的就是梳理产品逻辑，让我们清楚的知道产品有几个频道，频道下面有没有子频道或者有多少个页面，这些页面里又有哪些功能模块，这些功能模块里又有哪些元素。
这样我们就模拟了用户的整个操作流程，逐一的将产品的所有功能界面操作了一遍，也列出了产品结构图和用户流程图。
有了这份结构导图，我们可以对产品进行鸟瞰式考虑和完善，当有问题时，修改起来也比原型和文档方便很多。
这样的方法同样适用于移动互联网产品的规划，并且比起Web产品更加容易梳理产品结构。
以上讲的都是前端面向浏览者的用户流程，但是如果规划的是一个平台级的大众化产品就不能从前端进行梳理了，例如CMS、BBS之类的程序，他们采用框架式开发，将功能与模板独立，前端的界面布局仅仅是通过模板机制的标签调用，因此在做产品规划时，前端是涉及不到的，也不应该从前端入手。
遇到CMS类平台产品的规划，也同样使用这样的方法，只不过是从后台入手模拟管理员的流程。
PRD文档写前准备就是让我们先通过思维导图梳理思路，明白产品有多少个频道、有多少个页面、页面有多少个功能模块、功能模块有多少个元素，逐步的将脑海里的想法明确梳理成结构。
虽然已经明确了产品的结构，但是这样的思维导图对于设计与技术人员依旧是抽象的，他们仍然看不懂，同时对于产品经理自己来说，这样的结构图也是没有经过推演的，具体是否符合产品逻辑，是否符合用户体验，都是没有深思过的，因此我们接下来就要进行原型设计，开始具体的考虑结构方案的可行性。
3、原型设计(手绘原型,灰模原型,交互原型)当我们逐渐清晰了产品的需求后，并梳理了产品的各个频道及页面，那么这一步就要开始验证这些想法的具体界面表现和方案的可行性了。
首先我建议通过手绘的形式快速在草纸上绘制出产品的原型，推演和讨论方案的可行性，当有一定的进展之后，我们再通过软件工具进行更深入的设计。
移动产品可以考虑灰模原型，网站产品可以考虑交互原型，对于这两种原型方式，无论是移动产品还是网站产品都可以使用，具体取得于你的个人习惯和团队要求。
对于产品经理来说，原型设计是为了帮助我们细致的考虑方案，并论证方案的可行性，同时也是为了避免产品宣讲时，抽象的语言描述导致听众理解困难和理解偏差。
上一篇文章我们通过思维导图将想法进行了结构化梳理，接下来我们就需要进行方案的可行性推演，验证产品功能是否可行，预估项目要花多少人力物力，因此我们就要通过原型设计进行相关需求的论证。
一开始就撰写PRD文档，我们很难对产品进行各方面的评估，也无法得知方案的可行性，并且无法直观细致的考虑产品。
原型设计是帮助我们更细致的思考，并做各项需求的评估，同时也是将自己脑海里的想法进行输出，通过原型设计后，我们就可以进行产品宣讲了。
相对于之前抽象的文字描述，原型则更加清晰产品的需求，设计和技术人员或者老板也能够更加直观的了解到产品意图。
原型设计是将结构化的需求进行框架化，因此原型也被称为线框图，具体的表现手法有很多种，相关的辅助软件也有很多，例如：Axure RP、Balsamiq Mockups、UIDesigner 等等。
当到了原型设计这一步时，已经不仅仅是构思了，我们需要更加深入的了解每个页面上的元素和这些元素的属性。
例如按钮元素，我们就需要考虑这个按钮的功能，并且这个功能操作后带给后端和前端的反馈。
举例这个按钮是注册会员按钮，用户操作后，第一步逻辑是验证用户输入的信息是否合法，不合法则给出前端反馈；合法则和后端通信验证是否已经存在同样信息，已经存在则给出前端反馈，不存在则进入下一步，注册成功；注册成功后的反馈是跳转页面，还是弹出层提示用户完善资料，这些都是需要更详情的考虑的。
当然这些更细致的思考是留在需求文档撰写时的，而此时我们需要做的就是把这些元素通过原型表现出来。
原型设计的表现手法主要有三种：手绘原型、灰模原型、交互原型1、手绘原型因为原型也被称为线框图，因此手绘是最简单直接的方法，也是最快速的表现产品轮廓的手法(如下图)。
手绘原型在初期验证想法时非常高效，也方便讨论和重构，同时也适合敏捷开发时快速出原型。
2、灰模原型灰模原型是由图形设计软件制作而成，我最常用的软件是PhotoShop和FireWorks，相对手绘原型，灰模更加清晰和整洁，也适用于宣讲，但是需要产品人员熟悉使用图形设计软件(如下图)。
灰模原型常用于移动互联网产品的设计，由于移动产品的交互需求复杂，原型设计软件难以高效的表达需求，因此移动互联网产品的设计通常是灰模原型加交互文档组合成PRD文档3、交互原型交互原型是使用原型设计软件完成的原型，常用软件是Axure RP，通常情况交互原型的设计仅早于PRD文档，是产品经理想法推演的最后一步。