产品需求文档(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编写一份高质量的需求规格说明书（Product Requirements Document, PRD）是软件开发过程中的关键环节，它详细描述了产品的功能需求、非功能需求、用户界面、性能要求、约束条件以及与其他系统的接口等，为开发团队提供了明确的指导。
以下是一些步骤和建议，帮助您撰写一份清晰、完整且易于理解的需求规格说明书：1. 明确目的与范围●引言：简要介绍项目的背景、目的、目标用户及主要需求概述。
●范围定义：明确PRD所涵盖的功能范围，以及不包含的内容，避免需求蔓延。
2. 用户故事与用例●用户角色：定义产品的用户角色及其主要目标和任务。
●用户故事：以“作为[用户角色]，我希望能够[执行某个操作]，以便[达到某个目的]”的格式编写用户故事。
●用例图与用例描述：通过用例图展示用户与系统之间的交互，并详细描述每个用例的前置条件、基本流、备选流和后置条件。
3. 功能需求●详细功能描述：对每个功能进行详细说明，包括输入输出、处理逻辑、异常处理等。
●优先级排序：为功能设定优先级，帮助开发团队理解哪些功能是最重要的。
4. 非功能需求●性能要求：如响应时间、吞吐量、并发用户数等。
●可用性：界面友好性、易用性、可访问性等。
●安全性：数据加密、用户验证、权限管理等。
●兼容性：支持的平台、浏览器、设备类型等。
●可维护性与可扩展性：代码结构、文档化、模块化设计等。
5. 界面原型与UI设计●界面原型：提供低保真或高保真的界面原型图，展示界面布局和交互流程。
●UI设计规范：包括颜色、字体、图标、布局等的设计准则。
6. 数据要求●数据库设计：描述数据库的结构、表之间的关系、字段类型及约束等。
●数据字典：定义所有数据元素的名称、类型、长度、用途等。
7. 接口定义●API接口：详细描述与外部系统或内部组件之间的接口协议、请求参数、响应格式等。
●文件格式与标准：如果涉及文件上传或下载，需定义文件格式、编码标准等。
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）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中已经要写清楚页面的元素以及这些元素的含义，并且说明最终用户在页面上大大致操作过程。
3个方法写对用户画像产品需求文档
3个方法写对用户画像产品需求文档产品需求文档（PRD）是指对用户画像产品的需求描述，包括功能、设计、界面等方面的要求。
下面列举了三个方法，帮助编写用户画像产品需求文档。
1.竞品分析法竞品分析是了解市场上同类型产品的基本功能和特点的重要方法。
在编写用户画像产品需求文档时，可以先对市场上同类别产品进行分析，了解他们的优势和不足之处，并根据用户反馈和市场需求进行针对性的改进和创新。
具体步骤如下：-选取与用户画像产品相似的竞品进行分析。
-分析竞品的功能、界面设计、用户体验等方面。
-根据竞品的优势和不足之处，确定用户画像产品的基本功能和特点。
2.用户研究法用户研究是了解用户需求的主要途径，通过调查问卷、深度访谈、用户观察等方法，收集用户的需求和意见，从而指导用户画像产品的需求编写。
具体步骤如下：-确定需要研究的用户群体。
-制定用户研究的计划和方法。
-进行用户研究，收集用户需求和意见。
-根据用户研究的结果，对用户画像产品的需求进行调整和优化。
3.需求分析法需求分析是对用户画像产品需求进行细化和明确的过程，通过分析产品的功能、用户交互等方面，明确产品的具体需求。
具体步骤如下：-确定用户画像产品的核心目标和功能。
-对每个功能进行细化分析，明确功能点和用户交互逻辑。
-根据功能点进行界面设计，包括界面布局、色彩搭配等。
-利用原型工具或草图等方式绘制产品展示效果图。
通过综合运用这三个方法，编写用户画像产品需求文档时可以全面了解市场需求、用户需求，并针对性地进行产品设计和功能开发，从而更好地满足用户的期望和需求。
同时，需求分析和用户研究可以实现产品需求的合理性和可行性，确保产品开发过程中能够高效、有序地进行，提高产品的成功率和用户满意度。
产品经理如何写一份好的PRD
产品经理如何写一份好的PRD一份好的产品需求文档（PRD）是产品经理日常工作中至关重要的一部分。
它对于团队成员的理解和指导至关重要，是确定产品功能和设计的基础。
以下是一些关键的步骤和要点，以帮助产品经理写一份高质量的PRD。
1.开始写PRD之前，产品经理应该进行充分的市场调研和用户研究，了解目标用户的需求、市场竞争环境和潜在机会。
这些信息将有助于确立产品的目标和战略方向。
2.PRD应该明确产品的目标和利益相关者，包括目标用户、业务目标和项目预算等。
产品经理应该清楚地了解产品的核心价值和独特卖点，并将其体现在PRD中。
3.PRD应该清晰地描述产品的功能和特性，并将其组织为层次清晰的章节和子章节。
每个功能和特性应该包含具体的描述，例如用户故事、用例和详细规格等。
4.产品经理应该避免使用过于技术性的术语和复杂的设计细节，在PRD中尽可能使用简洁和易懂的语言进行描述。
这将更容易为团队成员理解和执行。
5.PRD应该包含详细的用户界面和交互设计，以帮助开发人员和设计师更好地理解产品的外观和使用方式。
可以使用原型、线框图或流程图等可视化工具来表示设计思路。
6.PRD还应包含测试用例和质量标准等，以确保产品符合预期的质量要求。
这样可以帮助开发团队和测试团队更好地验证产品功能，并提高产品的稳定性和用户体验。
7.与团队成员进行有效的沟通和协作非常重要。
产品经理应该鼓励团队提出问题和建议，并及时对其进行回复和解答。
还可以使用会议、邮件、即时通讯工具等进行沟通，保持团队的紧密合作。
8.最后，产品经理可以通过定期更新PRD来跟踪产品的开发进度和反馈。
这有助于识别潜在的问题和风险，并及时进行调整和优化。
同时，产品经理还可以使用PRD作为产品版本间的参考和文档，为产品的后续发展提供指导。
总之，一份好的PRD应该清晰、详细、易懂，并与整个团队进行有效的沟通和协作。
通过遵循上述步骤和要点，产品经理可以写出一份高质量的PRD，为产品的开发和交付提供有力的支持。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
产品需求文档(PRD)的写作方法无论我们做什么事都讲究方式方法，写产品需求文档(以下称PRD文档)也是如此，之前我通过五篇文章分享了自己写PRD文档的一些方法，而这一篇文章主要是对之前五篇文章进行整体的摘要介绍，帮助大家快速了解写作流程。
产品需求文档(PRD)的写作五篇章：1、写前准备(信息结构图)2、梳理需求(产品结构图和用户流程图)3、原型设计(手绘原型,灰模原型,交互原型)4、撰写文档(PRD文档)5、用例文档(UML用例图、流程图)1、写前准备(信息结构图)：在写PRD文档之前，我们需要先罗列出产品功能的信息内容，这一步是将想法逐渐清晰的第一步，也是帮助我们接下来规划功能的辅助信息，同时也可以辅助服务端技术人员创建数据库。
因为这是第一步，所以我们不需要罗列的很详细，在之后的步骤里，我们会逐步改进和完善信息内容。
例如一篇文章的信息内容主要有：文章标题、文章正文、文章作者、发布时间、所属分类。
初始的功能需求只有这些信息内容，但是在之后的功能规划中逐渐更加细致的考虑时，可能会增加或者删减，因此第一步我们不用刻意的追求信息的全面。
罗列信息内容的方式有很多种，文本形式、思维导图形式等等都可以，最主要的是能够清晰易懂，我最常用的方法就是思维导图，因此我称这一步为信息结构图。
2、梳理需求(产品结构图和用户流程图)：当我们对产品的信息结构了解后，我们就需要规整脑海中的产品需求，让想法更加结构化，因此这一步是梳理产品的需求。
我们首先要罗列出产品的频道及页面(产品结构图)，其次再基于产品结构图梳理出频道及页面中的功能，并延伸构建出用户的操作流程(用户流程图)。
以上两步是为了让我们在撰写产品需求文档之前能够对产品有一个全面的了解，类似鸟瞰式的一目了然，也方便调整完善。
3、原型设计(手绘原型,灰模原型,交互原型)：当我们逐渐清晰了产品的需求后，并梳理了产品的各个频道及页面，那么这一步就要开始验证这些想法的具体界面表现和方案的可行性了。
首先我建议通过手绘的形式快速在草纸上绘制出产品的原型，推演和讨论方案的可行性，当有一定的进展之后，我们再通过软件工具进行更深入的设计。
移动产品可以考虑灰模原型，网站产品可以考虑交互原型，对于这两种原型方式，无论是移动产品还是网站产品都可以使用，具体取得于你的个人习惯和团队要求。
对于产品经理来说，原型设计是为了帮助我们细致的考虑方案，并论证方案的可行性，同时也是为了避免产品宣讲时，抽象的语言描述导致听众理解困难和理解偏差。
4、撰写文档(PRD文档)：当我们通过以上三个大的步骤之后，我们就已经非常清晰产品的需求了，一般情况下，通过原型加描述的方式就已经完成了PRD文档的目的(很多产品经理直接使用Axure制作PRD)。
当然也会有一些个人或团队的要求不一样，对PRD文档有特定的规范标准，这类情况可能是需要存档归类。
无论什么样的规范标准，PRD文档的目的都是相近的，因此功能描述的方式也是相似的，所以在这里我分享了三种撰写PRD 文档的方式。
5、用例文档(UML用例图、流程图)：《产品需求文档(PRD)的写作方法》的补充文章，主要讲解PRD文档中的重要辅助文档“用例文档”。
产品需求文档的写作(一) –写前准备(信息结构图)当我们初次接触产品需求文档时，首先会从网络上寻找产品需求文档模板，希望从中了解和学习具体的写作要求，但实际上，现在网络上绝大部分的PRD 文档都是与实际工作不相符的，或者说是复杂的。
前几天一位从事产品类工作的朋友，发来一份他写的产品需求文档目录截图给我(下图)，当时我就郁闷了，这些类目更像是MRD文档，而不是PRD文档了，因此我决定写几篇讲述写作PRD文档的文章，分享一些我关于PRD文档的见解和写作方法。
PRD是英文Product Requirement Document的缩写，中文的意思是产品需求文档，具体的名词介绍大家可以询问Google。
PRD文档是基于BRD、MRD 的延续文档，主要用于产品设计和开发使用，因此阅读这份文档的人群绝大多数是设计与技术人员。
在这类人群中，设计师更多依赖于原型进行交互或视觉的设计，因此看这份文档的人就会偏向于技术人员。
相对于技术人员，他们不太关注产品的商业需求和市场愿景，因为在进行产品讨论立项时，产品的定义就已经向参与设计和研发的人员宣讲过，因此技术人员更多的是关注界面、功能、交互、元素等等内容，因此PRD文档是一份详细的产品功能需求说明文档，是产品文档中最底层和最细致的文档。
PRD文档是一份没有闲话，直入主题的功能说明文档，因此我们在写作时，脑海里构思的是成品产品的界面功能的逻辑线框图。
在写作这份文档前，我们需要先做一些准备，把BRD、MRD的相关需求消化并融合规划出产品的结构图。
因为这些准备工作是属于思维类的，所以我推荐使用思维导图软件(MindManager)进行规划工作。
规划产品的第一步就是梳理出产品的信息结构，有了信息结构我们才能继续往下规划产品结构，并且信息结构是服务端技术人员创建数据库的依据，是数据结构的辅助文件。
对于新产品或者新功能，没有人能够比产品经理更加清楚所需要的信息内容了，因此第一步我们就需要先将这些信息罗列出来，形成结构化。
（如下图）这张图是以我的博客作为示例，在罗列信息结构时，我们更多的是考虑信息数据，因此在这一步，我们还不需要深入的考虑产品的界面与功能。
信息结构的考虑有面向前端的，也有面向后端的，具体视产品类型而定。
例如CMS之类的程序，这类程序采用框架式开发，将功能与模板独立，因此前端具有多变性，并且这类产品属于平台型产品。
针对这类产品，我们在规划信息结构时，只需要简单的考虑一些前端的功能需求，更多的是面向后端管理员操作进行考虑，从后端入手规划和罗列出所需要的信息内容结构。
无论是什么样的产品类型，无论从哪里入手，我们第一步都是先要罗列信息结构，因为信息结构图不仅是辅助技术人员创建数据库的图表，也是辅助产品人员进行产品功能规划的参考，只有对信息或数据的结构了解，我们才能玩转数据，玩转产品。
在信息结构转数据结构时，如果是针对已经存在的产品而增加的新功能，那么技术人员就需要根据这个信息结构进行数据库对比，已经存在的数据便直接调用，如果不存在，则就需要具体的讨论，确定新信息的使用途径和以后的扩展方向，以便确认是创建数据表还是创建数据字段。
（虽然产品经理不需要技术开发，但是如果能够懂技术原理和数据库原理，非常有助于产品规划和技术沟通。
）信息结构图是产品层面的理解，如果要入库这些信息，还需要进行数据结构的讨论。
一条信息的存储有很多附加属性，具体是存成字段还是数据表，还是说存在中间表或者关联表，这些都需要在完成PRD文档后和数据库技术人员共同讨论。
讨论时除了展示信息结构图，还要讲解产品原型和功能需求，以便数据库技术人员了解产品意图，方便他们做数据库规划时考虑到以后的扩展。
信息结构图是我们将概念想法形成结构化的第一步，也是我们接下来几步工作的辅助文件，同时在接下来的几步工作中，我们还会不断的完善信息的结构。
产品需求文档的写作(二)梳理需求(产品结构图和用户流程图)上一篇我们将概念想法形成了信息结构，罗列出了产品的所有信息内容，现在我们就要依据信息结构，开始规划产品的功能需求，绘制出产品结构图和用户流程图。
首先我们要规划出产品的频道及子频道、子模块或子页面。
（如下图）图注：讲解一下我对于这个思维导图的名词理解1、频道：某一个同性质的功能或内容的共同载体，也可称为功能或内容的类别。
2、子频道：某频道下细分的另一类别3、页面：单个或附属某个频道或分类下的界面4、模块：页面中多个元素组成的一个区域内容，可以有一个或多个，也可以循环出现(例如:文章列表)5、模块元素：模块中的元素内容，以文章列表举例：文章标题、文章摘要、文章发布时间，这些都是元素，都是组成模块的内容，同时他们也是可以循环出现的。
元素的类型可以是：文字、图片、链接等等如果你学过网页设计，或者了解Web产品的模板机制，你就能够理解这些名词了。
如下图所示，这是我的博客的首页结构。
当我们规划出频道后，我们就需要以用户的视角进行一步一步的模拟操作，逐渐完善产品的结构导图。
我称为用户流程图，用于展现产品经理脑海中比较抽象的产品逻辑，也是产品经理对自己脑海中的产品想法进行梳理的一个过程。
（如下图示例）这样做的目的就是梳理产品逻辑，让我们清楚的知道产品有几个频道，频道下面有没有子频道或者有多少个页面，这些页面里又有哪些功能模块，这些功能模块里又有哪些元素。
这样我们就模拟了用户的整个操作流程，逐一的将产品的所有功能界面操作了一遍，也列出了产品结构图和用户流程图。
有了这份结构导图，我们可以对产品进行鸟瞰式考虑和完善，当有问题时，修改起来也比原型和文档方便很多。
这样的方法同样适用于移动互联网产品的规划，并且比起Web产品更加容易梳理产品结构。
以上讲的都是前端面向浏览者的用户流程，但是如果规划的是一个平台级的大众化产品就不能从前端进行梳理了，例如CMS、BBS之类的程序，他们采用框架式开发，将功能与模板独立，前端的界面布局仅仅是通过模板机制的标签调用，因此在做产品规划时，前端是涉及不到的，也不应该从前端入手。
遇到CMS 类平台产品的规划，也同样使用这样的方法，只不过是从后台入手模拟管理员的流程。
PRD文档写前准备就是让我们先通过思维导图梳理思路，明白产品有多少个频道、有多少个页面、页面有多少个功能模块、功能模块有多少个元素，逐步的将脑海里的想法明确梳理成结构。
虽然已经明确了产品的结构，但是这样的思维导图对于设计与技术人员依旧是抽象的，他们仍然看不懂，同时对于产品经理自己来说，这样的结构图也是没有经过推演的，具体是否符合产品逻辑，是否符合用户体验，都是没有深思过的，因此我们接下来就要进行原型设计，开始具体的考虑结构方案的可行性。
下一篇我将讲解原型设计的几种方法，并说明为什么原型设计要早于产品需求文档的撰写。
产品需求文档的写作(三)原型设计(手绘原型,灰模原型,交互原型)上一篇文章我们通过思维导图将想法进行了结构化梳理，接下来我们就需要进行方案的可行性推演，验证产品功能是否可行，预估项目要花多少人力物力，因此我们就要通过原型设计进行相关需求的论证。
一开始就撰写PRD文档，我们很难对产品进行各方面的评估，也无法得知方案的可行性，并且无法直观细致的考虑产品。
原型设计是帮助我们更细致的思考，并做各项需求的评估，同时也是将自己脑海里的想法进行输出，通过原型设计后，我们就可以进行产品宣讲了。
相对于之前抽象的文字描述，原型则更加清晰产品的需求，设计和技术人员或者老板也能够更加直观的了解到产品意图。
原型设计是将结构化的需求进行框架化，因此原型也被称为线框图，具体的表现手法有很多种，相关的辅助软件也有很多，例如：Axure RP、Balsamiq Mockups、UIDesigner等等。