产品设计-(5)需求文档

流程非常必要，我把设计流程主要分为4大块:

1、初步沟通

这个是最为重要的一步，双方都在选择，有的公司会为此专门抽人出来做这一步。我个人认为专业和效率是第一步的关键词，而不是什么价格、关系等，没有专业，都是空谈。

2、前期准备

这一步最重要的是签合同。没有合同绝对不要开始设计，那样的设计是没有价值的，客户也不会把你放在眼里。因此我认为原则是关键词，价格和首期款甚至都可以谈，但款是一定要先收的。

3、设计阶段

执行是这一步的重点，所有的工作都必须为此事提前和优先进行，服务时间上要占得主动。

4、后期执行

主要是结款，前面的步骤进行的流畅，后面的款就好收。如果涉及到制作的话，则需要双方配合和协调。

以下是具体流程说明：

（其中涉及到标准的7个表格）

一、初步沟通

充分了解客户需求客户可以先在企业自身内部形成统一的意见，明确需要设计的项目、设计的要求和项目预算，指定项目的负责人，协调好相关的资料收集工作。

对企业背景、产品背景、目标市场环境、竞争企业和竞争产品进行初步分析客户可以利用自身的行业优势，向广告公司提供尽可能多的背景资料，以便于广告公司对设计项目进行系统的专业分析。

向客户介绍此类项目的常见设计风格以供参考广告公司可以向客户提供项目相关的实际案例以便于客户进行风格和形式的筛选。

了解客户预算以便在设计时采用适当的印刷工艺和材质预算的多少对设计方案最终是否能够顺利执行有很大的影响，好的方案如果没有预算的支持，只会浪费双方的时间和精力，所以应尽可能在项目开始前就确定好大致的预算。

提出初步的设计解决方案在与客户充分的沟通后，根据掌握的资料，经过内部分析，向客户提出初步的解决方案即设计简报1，并取得客户的认可。

二、前期准备

根据设计的要求、数量和难度，向客户提出报价

设计费根据不同的要求和难度，价格有所不同，通常由广告公司提供整合解决方案时(如由广告公司同时承接前期设计和后期制作执行)设计费可以有一定的浮动空间。

         墨刀连接：https://org.modao.cc/app/44c36ea7f224104c1fd3c6ac19162db5 

一.需求背景

二.需求目的及明细

三.业务流程

    3.1业务流程

    3.2页面流程

四.功能详细设计

    4.1交互设计

    4.2原型

五.考核指标

六.总结

公司最近想把用户约见这个场景在微信小程序上做深做透，基于这个业务诉求，设计聚餐投票的功能，便微信群用户在线下聚会前，能先在线上把大家喜欢的美团店铺汇总在一起，然后投票决策聚会去吃哪个店，可以节约用户的时间成本。

使用投票聚餐一定是针对的一个小群体，这个小群体一定是有一定关系的，如同事，朋友，同学，家人等，基于上述理论对用户-场景-需求分析：

需求目的：完整的投票聚餐功能，选择商户到统计投票。解决用户在聚餐选择商家时意见不统一或者想要统计大家意见时的需求。

创建流程 ：

编辑流程 ：

1.我的

在我的页面中新增入口图标，点击后可进入投票聚餐

2.新增投票页

页面分为新增投票模块以及历史投票模块，历史投票模块以时间顺序排列

创建投票：创建投票后进入选择餐厅页面

编辑：点击编辑后，重新编辑此次记录，进入确认页面，可重新发起投票

3.选择餐厅页

选择餐厅页面分为3个模块，顶部的搜索模块，排序模块以及商家展示模块。

排序模块分为4种筛选模式：

按照美食种类分类，其中默认为全部美食，用户点击后出现下拉菜单，用户可选择美食分类（如：食品保健，特色菜，福建菜等）

按照地理位置进行排序，分类模块按城市区域地理性标志划分，默认选择为附近

为用户筛选的常用关键字排序，分为：智能排序，离我最近，好评优先，销量最高，默认为智能排序

按照餐厅服务以及用餐人数为用户进行筛选，默认状态为关闭

确认添加：点击确认添加后，进入确认页

添加商户：点击加号添加商户，再此点击取消添加商户

搜索：点击搜索页进入搜索页面

已添加商户:点击后进入展开已添加商户，可以对已添加商户进行删除

4.确认页

确认页分为主题元素，商户展示模块

主题默认为系统填写，用户点击后可进行修改

生成投票分享好友：点击后进入好友页

添加喜欢餐厅：点击后进入选择餐厅页，无人员限制

删除商家：点击后删除商家

5.结果页

模块分为主题模块，商户展示模块以及出现在商户暂时模块下面的统计模块

投票：点击投票按钮投票，再次点击取消投票；用户若已选择商户，在点击其他商户的投票按钮将自动取消已选的上加商户。

随机功能：场景为当出现平票时为用户随机一家商户，没有操作权限，任何人都可以操作，但点击一次后默认10分钟后才能再次点击，随机结果将一直展现，直到下次随机出现新的结果

回首页：点击后返回首页

添加喜欢餐厅：点击后进入餐厅选择页，选择完毕后直接进入到结果页。

1.考察用户日活增长指数：当天日货量-前一天的日活量/前一天的日活量x100%。投票聚餐是有分享属性存在的，纯在分享属性，进入小程序的用户数应相应增多。

2.对投票聚餐的入口，新增投票以及生成投票分享好友进行埋点，统计访问人数，分别计算转化率。是考核功能的转换率，用户流入入口的数据，是判断这个需求是真需求还是伪需求的根本。

3.使用流程转化率：新增投票访问人数/投票聚餐的访问人数x100%，生成投票分享好友访问人数/投票聚餐的访问人数x100%。此数据是对流程的考察，用户是否觉得流程好用，从此数据能够得出一定的结论。

总结

投票聚餐是针对于当代年轻人常出现的聚餐场景，由于每个人都有自己的喜好而出现的意见不统一的需求，因此诞生出来的功能。此功能要包含完整的投票流程，从选择餐厅-投票，并需将选择餐厅的分类功能尽量做详细，给用户更多的参考意见。此功能完成后，用户日活应有一定程度的增长。

我们先假如产品需求文档（PRD）是一个产品，那么该如何做出一个拥有良好用户体验的PRD？

首先先来考察下PRD的用户群体（User Persona）：主要是开发人员，在繁忙的开发任务中最希望看到“简洁易懂”的产品需求文档。

梳理下PRD的功能：

传达出产品需求；

管理记录产品迭代过程；

各部门共享产品信息，以促进沟通；

因此一个好的PRD的原则是：

结构清晰

语言简洁易懂

实时共享

具体我们该如何制作？

答案很简单——一个PRD文档即可

现在，越来越多的产品经理采用将文本说明和原型结合成一个PRD文档的方式，因为之前的word+原型的方式管理起来繁琐，而且还容易产生信息疏漏。

将原型和文本说明统一，直接分享一个链接，开发人员就能看到所有信息，是理想状态。

多级导航结构展示PRD信息

通常来讲，一个产品需求文档里包含“产品概述”、“流程图”、“功能详情和原型”，“全局说明”，“非功能性需求”。

如何把这些内容清晰有条理地呈现在一个文档里呢？使用一个网页般的多级导航结构即可。

1、产品概述

产品概述部分用于展示文档修订历史、版本说明、开发周期、和产品介绍。

「文档修订历史」用来记录产品经理对该PRD文档的修改状况，也方便成员能及时了解到PRD是否有改动；

「版本说明」展示上线产品各版本的核心功能；

「开发周期」用于梳理开发、测试、上线的预计开始和结束日期。

「产品介绍」用来记录产品名称、简介、用户画像、使用场景、产品定位等等。

（墨刀“PRD模版A”中的“版本信息”模块，by 小龙）

2、流程图

流程图是产品经理梳理产品逻辑和功能的一个思维Map，一般会有“功能结构图’、“信息结构图”、“任务流程图”。

「功能结构图」 展示产品的功能模块，一般展开用户可见的最小单元。

「信息结构图」则是以信息为维度，用来描述有哪些数据字段，展现用户信息/行为信息等。

「流程图」记录着用户使用产品的路径，也是一种产品线路图，展示着产品的所有页面及对应关系，有助于产品理解。

（墨刀“PRD模版A”中的“结构图”模块，by 小龙）

3、功能详情和原型

这个模块是开发人员查看频率最高的模块了。目前一种快捷高效的呈现方式便是“原型”+“注释”。

图文互补，把图片传递不了的信息用文字补充清楚，比如产品的一些使用逻辑，方便同事理解。

使用墨刀的话，可以创建一个大的画布，然后把墨刀制作的原型页面粘贴到画布里，并添加文字注释，在关键位置有一些边界条件的说明。

或者，直接在产品原型项目里通过“批注”添加注释。

（“PRD模版A”中的“交互原型”模块，直接嵌入了墨刀原型，by 小龙）

4、全局说明

这个页面用来展示整个产品的设计规范，一些通用的规则可以附在这里。

对于这点，使用墨刀制作的方便之处在于：

可以直接把有关设计规范的原型项目通过网页链接的方式嫁接过来，还能点击“标注”查看各元素的细节信息。

（ 墨刀“PRD模版A”中的“全局说明”模块，by 小龙）

5、非功能性需求

对于不同类型的产品，非功能性需求会有各种差异，一般会涉及到的有：

性能需求

系统需求

运营需求

安全需求

统计需求

财务需求

……

这部分就要自己按需要调整。

总结

PRD作为一种重要的公司内部沟通的文档，能把必要的信息汇集在一个逻辑清晰的结构里是提高工作效率的一个优势。语言上的简洁易懂，再结合可视化的结构图和原型，都是为了增强易读性，让沟通更高效。

把PRD当作一个小产品去打磨一下，不是浪费时间，一个好的PRD文档可以继用很久。

墨刀新出了两种产品需求文档的模版，这两种PRD里的各级页面内容、导航和交互都为大家设计好了。

现在大家可以点击“创建项目”，从墨刀模版中选取“产品需求文档A”或者“产品需求文档B”，点击“使用模版”，再按照自家产品需要做一些更改就okay！

通过墨刀的分享链接还能直接让公司内部人员在线实时同步PRD的更新，不用再担心信息滞后或者文档不兼容问题。

让我们着手开始创建或者优化您的产品需求文档吧～

希望采纳！谢谢！

配图来自  “运维派”以及墨刀官网截图

首先告诉你产品需求文档肯定是有的！一个经过实际工作检验、经历过“质疑”、“挑战”和“斗争”之后沉淀下来的模板，肯定是已经吸收了各类人的偏好、意见，固化了很多符合实际业务必须的内容要求，能够起到很好的业务承接作用。格式化、标准化本身是一个很好的思维、工作方式，可以让你在编辑文档和接受文档的双方关系中建立一种“标准”的沟通机制和预先定义的沟通基础，减少额外的沟通成本，提高效率。

不过，在享受别人智力和经验梳理好的模板进行需求编写的同时，还是应该了解模板形成的原因，并在此过程中形成自己对于模板的理解，进而形成对于产品需求文档的理解，在理解中使用，裁剪和优化。

要理解和分析模板，理解和分析产品需求文档，可以运用以下几个方法：

一、描述-解释-预测-监控

描述，是对观察过程和观察结果的描述。观察的对象因不同的研究而有差异，其目标是尽可能完整地将观察者根据自己的观察得到的现象、由此现象所产生的思想和感觉，以及在观察过程中选择纳入的过程参与者对现象的反应等信息进行描述。

解释，是回答 “为什么”，是对于描述的理解、归类、定义和解释。其目标是将描述内容背后的成因、原理、动机，内容中各部分之间的相关，依存、依赖和影响关系等进行说明，以便对于描述内容有更清晰、更细致、全面的了解。

预测，根据以因果关系为内容的内在联系，相互影响来推导未来的发展或者将要发生的事情。通过研究解释内在的联系，准确地表达内在联系，从中推导出正确的预测。

监控，是对于预测行为、现象的观察和监督，包括了观察到的预测中的行为、现象的发生或者预测以外的行为、现象的外发生，以及因此而采取的对应的反映动作；这些反映动作是预测过程中根据内在联系制定的“响应”机制，并任其自然发生或者通过提供“系统”的自制能力来实现。

二、需求准备、编写和检查

回归到产品经理的日常工作中，在时间占比上较为集中的就是产品需求管理了，包括了需求的准备、分析、编写和检查过程。在这个过程中，描述——解释——预测——监控这个通用的科学分析过程也同样使用，且可以贯穿其中，并可以帮助理解、形成并固化成我们前文提到的需求文档的模板。这个科学分析的过程、方法在不同阶段运用的侧重点会有所不同。

1. 描述

描述的过程是客观的进行“需求向”描述的过程，是一个“背景”信息的补充，用来说明，这个需求文档的源出是什么，是针对什么问题，这个问题是在具体什么领域，在怎样的范围内，涉及到的是那些人；在需求相应的功能设计实现之前，当前的解决方案存在的问题是什么，参与者是怎么解决的，解决的情况怎么样，是好，还是不好，还是勉强可以，对于新的需求的紧迫性是什么样的。此外，描述的过程还需提供一个基础的概念和流程的解释，用来统一作为背景去理解一个现实的业务场景和“沟通字典”，避免在沟通中因为误解而产生不必要的偏差。

需求准备的过程：了解需求来源（管理部门、市场部门、运营部门等），需求背景（行业、同业规则现状等）；

需求分析的过程：了解需求目标、预期效果（时间、结果等）、使用者习惯、相关人影响；

需求编写的过程：描述需求目的、背景、时间和结果要求、业务流程、交互过程、系统架构、干系人角色和影响范围；

需求检查的过程：需求的背景、目标、过程、干系人、结果预测和预防的完整性检查；

2. 解释

解释在需求来源的基础上描述了 “为什么”接下来这个需求可以解决遇到的问题，同时还加入了“是什么”和“怎么样”的部分。就是这个需求是通过怎么样的方法解决了“描述”过程中提到的问题，这个新的解决方法需要要做什么，对于原有的业务过程有哪些改变，会提升什么，会降低什么，会影响哪些人、哪些业务部分、哪些业务系统以及哪些数据的产生。这个部分，是需求文档的最主要、最核心的内容部分，也是在内容上占比最大的一部分。

这里的解释根据产品需求面向的要解决的问题不同，而可能存在多个层面，多个维度的层面，比如对于运营的影响，对于前端市场的影响，对于用户的影响，对于财务、法务的影响；从技术开发、技术实现维度，比如对于前端开发的影响、对于服务端开发的影响、对于数据平台的影响，还可能涉及到对于运维资源的影响等；因此对应到实际的产品需求工作中：

需求准备的过程：了解需求可能涉及的相关业务系统及系统对应的数据流程和逻辑、了解需求可能涉及的外部服务的数据流程和逻辑；了解面向的内外部用户的产品使用水平、学习能力和使用习惯；

需求分析的过程：选择和制定最有效的，满足时间、资源投入等要求的方案；

需求编写的过程：详细描述需求的业务流程，通过各种图表格式说明新的解决方法在各服务系统之间、各业务部门之间、用户与产品，产品与后服务之间的数据、文件和行为的交互过程、详细的信息输入、信息处理和信息输出；每个业务节点明确的输出物和节点标志，重要性和优先级；系统架构、干系人角色和影响范围；

需求检查的过程：需求的流程、用户交互动作、系统信息交互等完整性检查；

3. 预测与监控

预测与监控在产品需求文档的管理上是联动的，是对于预测的事件发生的时候，进行管理的机制，监控=预测+干预。在产品需求文档的管理上，对于设计好的业务流程、使用功能，在实际过程中可能会出现这样或者那样的 “非规划”的使用，也就是我们通常说的“用户并不总是按照产品设计的方式来使用产品，而且，往往相反。”因此，这部分内容很大的比例需要来对于用户的行为进行预测和监控，并提供“预防”或者“解决”方案。其中：

预防在于，预测产品的用户在使用的过程中，可能会进行的一些超过产品使用半径的操作，一旦进行这些操作，操作的任务流程会中断，掉出，进入其他业务流程中且无法回滚，从而使得操作无法进行下去，功能使用失败，使用者会感觉产品、功能没有包容性，缺乏引导性，导致了最后操作的失败，预想的结果没有实现，而且造成了一定的挫败感，甚至造成了一定的损失。预防的具体方法多采用导航、提示等，不同的系统都有各自标准化的控价，我们在这里不做展开。

解决在于，预测产品的用户在使用产品的过程中，因误解、操作手误而进行了“非标”、“超规”使用“掉出”原本设计的业务流程和操作流程的情况下，需要提供额外的流程和控制来“回转”用户的操作，来帮助用户回到预先设定和他所需要的流程上来。解决的具体方法多通过“导航”引导“跳转”和“返回”、“回退”来实现。对应到实际的产品需求工作中：

需求准备的过程：了解用户特征和使用水平、评估、比较不同方式实现需求对于用户行为的可控性和“非常规”操作的危害程度；

需求分析的过程：选择和确定需求实现方案，评估行为管理方式和管理机制；

需求编写的过程：详细描述需求的业务流程和交互过程中可能出现的用户异常操作，相应异常操作中系统反应，系统对应的控制和引导；

需求检查的过程：需求“异常”流程和相应引导、控制地完整性检查；

在需求管理的过程中，就可以按照这个 描述——解释——预测——监控流程来进行。这四个既是步骤，是需求文档内容的组成部分，也是需求编写完成之后的检查。

四个模块构成了需求文档的完整性，且同时有各自独立，有对应的说明，引导、要求和标准。所谓标准文档，就可以按照这四个模块作为框架、内容和格式。

写在最后

产品需求文档作为产品经理同视觉设计、交互设计以及技术开发人员进行需求沟通的一个载体，我平时用的比较多的是摹客的服务进行创作。一个完整的、充分沟通确认，并最终达成多方理解和共识的产品需求文档，能够最大限度的还原产品、功能的设计，保证产品、功能的实现，最大限度的减少因为各方理解的偏差而造成的时间、人力和经济资源的浪费及复工。

你好，今天我来详细介绍交互设计师的输出物–交互文档的相关细节，其实，UX设计师在今天看来，仍然算是一个新兴职位，所以我多讲一些UX设计师的职位背景和相关工作内容，作为本篇文章的背景。

一、交互设计师的工作内容

UX设计师的存在，使原本产品经理工作中的原型制作工作逐步转让给UX设计师，使产品经理更关注需求的战略层面，更能进行战略层面的设计。同时，UX设计师也分担了UI设计师的布局设计、跳转设计等非本职工作，使开发流程中的角色更加专注自己的工作。

交互设计师，UX设计师，有的公司也称之为UE设计师。具体的工作内容可以认为有：

需求消化，使其可实现化，并制作对应的交互原型；

规定数据格式、样式，规定数据的展示方式、字段限制；

规定控件的使用规范；

从功能流程的高度，梳理功能的页面层级；

规定数据的前后台交互；

规定临界状态；

页面切换动效的规定和模拟等等。

不同的公司对交互设计师的工作内容可能有不同的界定，但是一般情况下，上述是大部分交互设计师的主要工作内容。在这样一份工作中，交互设计师基本上是填补了从产品经理到UI设计师之间的空白，从开发角度和设计角度对一款产品的细节进行补完。

二、 交互设计师的输出物

作为交互设计师的输出物，交互文档是联系开发流程上下游的重要文件，它需要具备良好的可读性、唯一性和时效性。

可读性指的是不论产品经理、设计师还是开发人员，都需要读得懂；

唯一性指的是，针对某个开发需求，必须有且只有一个交互文档。针对某个项目，其对应的交互文档也必须是独一份（可以是一个交互文档的集合）。即使存在多个版本，旧的版本必须标注为“归档备查”，并且明确备注过时时间；

时效性指的是，某个需求或者某个项目，尚在使用中的交互文档，必须是最新的，符合当前需求要求和产品输出的。

本文着重介绍的即是交互文档的构成和它的写法（基于中国移动交互文档规范）。

三、交互文档的构成

综合国内IT行业的从业环境，基于Axure的原型制作可能更便于打通开发上下游。

大概碍于Axure做出来的原型不是那么美观和便捷，部分产品经理和UX设计师可能已经转战Sketch等交互设计软件，或者使用Flinto来模拟交互动效。但因为这些软件大多无法跨平台，考虑到很多公司并没有能力全面采用MAC办公，所以这里推荐使用Axure进行原型制作。

交互文档一般由以下部分构成：

1. 交互文档说明及日志

说明交互文档所针对项目或者功能；

日志记录它的创建时间、修改时间及修改原因和内容；

记录文档的编写人和最新的更新时间。

请点击输入图片描述

交互文档说明示例

请点击输入图片描述

交互文档更新记录/日志示例

交互文档的Title有效地保证了交互文档的唯一性，即该文档对应的是XX项目或XX项目的XX功能；

通过编写人、版本号、创建时间和更新时间，方便在文档内容存疑时，找到对应的时间节点和该文档的负责人，便于对接和修正；

在更新记录中，需要有效地标明版本号、更新时间、更新内容和修改人，便于文档内容出现存疑时，定位到是哪一部分出现了问题，该部分的对接人是谁，并且明确时间节点，便于版本的追溯和责任的厘清。

2. 文档内容结构

大致包括模块名称、功能流程图、页面说明、页面跳转关系图等。

请点击输入图片描述

交互文档构成结构示例

在文档内容的结构中，必须保证交互文档的说明和日志是位于头部，便于随时查阅；

在正式内容中需要灵活运用Axure中的图层，如分组和页面图标等。一般我们认为将页面说明和页面跳转关系统一归到一个功能流程或者一个分组下，这样旣合乎逻辑也可以保证文档内容的层次感，便于查阅时的定位和展开；

始终坚持“一个页面只描述一个功能”的原则，这样可以保证单个文档页面中的内容量适当，便于查阅。

请点击输入图片描述

页面说明示例

在确定以上内容后，就可以保证这份交互文档结构是足够清晰的，是便于查阅的。接下来，我们将讲解交互文档的正式内容应该如何写。

我们用国内的一款软件摹客网页链接举例

1.产品概述

产品需求文档的第一部分，首先需要对整个项目的研发背景及整体规划进行说明，让阅读者可以快速理解需求背景和产品定位。其次是对产品需求文档本身进行阐述，在每一次修订后都需要进行记录，方便阅读者了解产品需求文档的修订更新。这一部分主要包括以下内容：

项目概述

词汇表

文档修订历史

版本说明等

2.功能范围

这一部分需结合用户、业务规则及市场环境，对产品的用户和市场需求进行分析梳理，找出差异性和优势，制定业务流程和需求清单。可通过业务逻辑图、流程图、产品结构图等图表，让产品逻辑和功能以最简单的方式陈列出来，团队成员可根据这一部分了解用户信息、行为信息等，也有助于对产品进行进一步的理解。

3.功能详情和原型

首先是列举功能总表，将产品功能进行逐条梳理，每一条功能都能对应前面的产品目标。

其次是功能详情展示，通过Mockplus等原型工具快速绘制原型，配合关键部分的批注说明，详细描述业务模块的展示、交互和数据逻辑，以供开发人员查看和理解。

4.全局说明

这一部分包括设计规范、数据统计、通用规则说明等信息，方便设计师和开发人员查看产品细节信息。

5. 测试需求

产品一般在正式上线前都有BETA版本或者内测版本，产品经理需要定制测试产品的功能或者性能。

6.非功能性需求

非功能需求为用户常规操作产品时的极端情况，涉及很多内容，包括产品性能、安全性、可靠性、拓展性等方面。

7. 产品运营和市场分析

完成产品开发并不是终点，产品的最终目的是要赢得市场。产品上线后如何运营？建议的推广策略是什么？产品经理和运营人员该如何协作？等等问题。

产品需求文档撰写技巧

如何高效完成产品需求文档的撰写？我们可以从以下四个方面展开说明：

理清文档结构

详尽叙述每一个细节

语义明确，没有歧义

搭配原型图或设计稿进行说明

1.理清文档结构

一份产品需求文档的内容往往多而复杂，因此，产品经理在撰写产品需求文档时，必须理清文档的结构，才能提升产品需求文档的可读性，让阅读者可以快速了解文档的思路和查阅重要信息。

将一份产品需求文档看做一个产品，首先需要梳理出它的结构，如上文中所呈现的文档内容，然后再按顺序进行撰写，这样才能写出结构清晰，层次分明的产品需求文档。

2.详尽叙述每一个细节

当我们站在产品经理的角度思考问题时，往往会出现这样的误区：产品的这一功能模块逻辑非常简单，业内常见，开发人员也一定能懂，不用再进行单独说明。

产品经理对于产品的功能及逻辑往往非常了解，但如果从开发或测试人员的角度来看，往往对于许多产品的细节和逻辑关系都不太了解。因此产品经理在撰写产品需求文档时，一定要做到事无巨细。不仅需要详尽叙述页面逻辑、交互逻辑、数据逻辑等所有细节，还需要从开发、测试等角度检查是否有遗漏或错误，才能保证后续开发工作有条不紊。

3.语义明确，没有歧义

在撰写产品需求文档时，要做到语义明确，不能出现让阅读者产生歧义的词汇或语句，如：大概、可能、似乎等词语。另一方面，对于产品定义的表述方式，必须做到全文统一。比如在撰写一份APP的产品需求文档时，前文写了“首页轮播图”，后文就不能再使用“首页Banner”、“横幅”等名称。

4.搭配原型图或设计稿进行说明

产品需求文档往往包含大量文字描述，团队其他成员在阅读某些功能细节时，往往无法完全理解文字内容。此时如果使用原型图或设计稿进行说明，就可以补充文字内容很难描述的信息，帮助阅读者快速理解产品功能和内在逻辑。因此产品经理在撰写产品需求文档时，需要配合原型图或设计稿进行说明。

一款产品的原型图或设计稿通常会进行反复修改，产品需求文档必须同步更新，才能让阅读者及时了解到项目的最新动态。但如果每修改一次原型图或设计稿，产品经理都必须手动去替换文档中的配图内容，那效率就太低了！其实，使用高效的产品需求文档撰写神器即可解决这一难题。

产品需求文档撰写神器

随着产品开发流程的不断发展，Office等传统办公软件已无法满足产品文档的撰写需求。今天为大家推荐的，是一款专门面向产品经理的文档工具——摹客。除了上述图文同步的难题外，摹客还能解决审阅沟通、版本管理等产品需求文档的写作困境，让产品经理可以更高效地创建专业的产品文档。一起来看看~

1.富文本撰写，充分表达产品需求

摹客全新的富文本在线写作模式，符合产品经理日常编辑习惯，可以快速完成文档撰写。撰写内容自动保存，可随时查看历史版本，方便对比修改。此外，产品经理也可以直接上传本地产品文档，会自动解析目录，并生成文档树，方便查阅。

请点击输入图片描述

2.与原型图、设计稿深度结合，相互说明论证

产品经理在撰写产品需求文档时可插入设计稿，当对设计稿进行了更新修改，可在文档中设置内容同步，无需重复插入。另外，团队成员在设计稿上打点评论时，也可以引用文档进行说明，让团队成员可以一目了然地查看相关信息。

请点击输入图片描述

3.实时审阅，高效沟通

文档编辑完成后可以通过链接一键分享给团队成员，团队成员可选中文字增加评论，对文档进行在线审阅，清晰表达项目意见，实现产品开发团队的高效沟通。

请点击输入图片描述

4.追踪修改记录，备份历史版本

通常，产品需求文档的写作不会一步到位，往往会根据团队成员的评审意见进行反复修改，因此会产生大量的迭代版本，对于产品经理来说，如何管理产品需求文档的历史版本，是一个很大的难题。在摹客

撰写产品文档，每一次修改都可以自动生成历史版本，可以随时跳转查看和恢复，管理便捷。

请点击输入图片描述

5.在线预览、分享更便捷

在摹客中在线撰写或上传的产品需求文档，可通过链接快速分享给团队成员，团队成员获得链接后可自由查看，当产品需求文档有修改时，团队成员仍可通过链接查看最新版本。

使用摹客等高效便捷的产品文档撰写工具，可以简化产品文档撰写流程，提升产品经理的文档撰写能力，让产品经理事半功倍。

在大多数软件项目中，要末不作详细设计，要么开发完成后再补详细设计文档，质量也不容乐观，文档与系统往往不能同步，使详细设计文档完全流于形式，对工作没有起到实际的帮助。

·

详细设计是相对概要设计而言的，是瀑布开发流程的一个重要环节，在概要设计的高层设计的基础上，从逻辑上实现了每一模块的功能，是编码阶段的主要参考资料，是从高层到低层、逐步精化思想的具体实现。

详细设计文档的内容包括各个模块的算法设计，

接口设计，

数据结构设计，交互设计等。必须写清楚各个模块/接口/公共对象的定义，列明各个模块程序的

各种执行条件与期望的运行效果，还要正确处理各种可能的异常。

·

在开发过程中，由需求及设计不正确、不完整所导致的问题是项目进度拖延、失败的一个主要因素，而软件系统的一个重要特性就是需求和设计的不断构建和改进，在写详细设计文档过程中，

详细设计实际上是对系统的一次逻辑构建，可以有效验证需求的完整性及正确性。

如果不写详细设计文档，一般就从概设直接进入编码阶段，这时开发人员所能参考的资料就是需求规格说明书及页面原型、数据库设计等，不能直接进行开发，需要进行信息的沟通，把页面原型不能体现的设计讲清楚，这样既容易遗忘，也容易发生问题，详细设计文档可以作为需求人员、总体设计人员与开发人员的沟通工具，把静态页面无法体现的设计体现出来，包含整体设计对模块设计的规范，体现对设计上的一些决策，例如选用的算法，对一些关键问题的设计考虑等等，使开发人员能快速进入开发，提高沟通效率，减少沟通问题。

对于系统功能的调整，后期的维护，详设文档提供了模块设计上的考虑、决策，包括模块与整体设计的关系、模块所引用的数据库设计、重要操作的处理流程、重要的业务规则实现设计等等信息，提供了对模块设计的概述性信息，阐明了模块设计上的决策，配合代码注释，可以相对轻松读懂原有设计。

·存在的问题要由专门的人写，是比较麻烦的，也是很需要时间的，会对进度造成压力，也容易形成工作瓶颈，使设计人员负担过重，而开发人员无事可作。对于现在一般的以数据库为中心的管理系统而言，这个工作始终是要作的，区别只不过是不是形成专门文档，形成文档可能会多花一两周时间，但相对于规避的风险和问题来说，也是值得的，另外由于现在高级语言的流行，所以更详细的设计应该直接体现在代码的设计上，而文档则只体现设计上的一些决策，协调整体设计与模块设计的关系，把页面原型所不能体现的设计情况文档化，所以所花费的时间是有限的。

设计内容容易过细，但设计阶段是不能考虑特别清楚地，时间也不允许。

对于这个问题，一个对策是上边所提到的，文档只体现设计上的决策，页面原型所不能反映的信息，详细设计只体现总体设计对模块设计的一些考虑，例如对功能的数据库设计等等，而具体的实现实现，则到代码中再去实现，相关的设计也仅体现在代码中。

需求、设计需要不断的被更新、构建，则设计文档需要不断的重新调整，文档的维护需要跟上，否则文档和系统的同步就很难得到保障了，且造成多余的工作量。文档的内容易流于形势，质量糟糕，不能成为开发人员的参考手册，一是要建立起相关制度，如有修改，先改文档，后作开发，从工作流程上切实保障文档与系统的同步，二是要规范文档质量，对文档该写什么，不该写什么，标准是什么，粒度是什么，语法应该如何组织，有明确的标准和考虑，同时，建立审计文档评审、审核制度，充分保障系统的使用。·

首先是文档的内容，根据项目和团队的不同，详细设计文档的内容也有所不同，一般说来，粒度不宜过细，不能代替开发人员的设计和思考，但要把有关设计的决策考虑进去，包括与其他模块、整体设计的关系、操作的处理流程，对业务规则的设计考虑等，有一个标准为，凡是页面原型、需求规格说明书所不能反映的设计决策，而开发人员又需要了解的，都要写入文档。

其次是文档所面向的读者，主要为模块开发人员、后期维护人员，模块开发人员通过详细设计文档和页面原型来了解所开发的功能，后期维护人员通过实际系统、模块代码、详细设计文档来了解一个功能。

再有就是谁来写文档，因为文档主要考虑的是设计上的决策，所以写文档的人应该为负责、参加设计的技术经理、资深程序员，根据团队情况和项目规模、复杂度的不同，也有所不同。

还需要保证文档的可读性、准确性、一致性，要建立严格的文档模板及标准，保证文档的可读性及准确性，同时建立审核及设计评审制度，来保障设计及文档的质量，另外在工作流程中要强调，要先设计、先写文档，再进行开发。

作为产品经理，日常接触最多的工作之一就是设计文档了。每个产品经理有自己的设计文档的写法，各个公司也有各自的设计文档的要求，所以大家平时看到的设计文档几乎没有一模一样的。

一份设计文档的结构大概包括一下几部分的内容：项目背景、项目排期、版本历史、信息架构分析（包括站点地图、体验地图、流程图等）、产品框架设计、线框图和视觉稿等。

具体在设计文档中要展示哪些内容，取决于实际项目的情况，公司的具体规定、产品经理的个人工作习惯等，可能删减一些内容，也可能增加一些内容。

每个部分拆分开来，我们一起来看看具体是如何的。

》》

这一部分的内容在充分沟通需求之后完成。产品经理充分了解要设计的产品是什么，是什么平台上发布的，产品的用户群体是哪些类型，使用场景有什么，他们想通过这个产品解决什么问题，业务/产品现状，关键痛点是什么。把需要和需求方了解清楚之后，能够明确产品设计目标，要解决的需求是什么，根据这些需求，需要设计什么样的功能或者如何优化现有的功能，最终达到怎样的业务目标。

》》

和需求方确认各阶段交付物的时间节点，知道什么阶段要完成什么工作，达成什么目标。根据时间节点制定完成设计的具体计划，根据这个计划有节奏、有方向地展开工作，以较高的质量按时交付。

》》

每发生一次比较大的迭代更新，都要记录在版本历史记录里。这样做的好处是，可以清晰地展现设计稿的迭代历程，做了哪些需求的改动，设计思路发生什么样的变化，哪个部分是什么时候什么人负责的。对于产品设计的回溯，提供了极大的便利。相比一个个去翻以前的设计稿，查看版本历史记录更清晰，项目结束后浏览这一部分，也可以看到自己的设计在哪些方面哪个阶段存在不足，是如何被发现、改进和提升的，下一次设计的时候是否可以更早地思考到和回避掉。

》》

根据具体项目性质的不同，这一块的分析工具也有较大的差异，具体的选择和使用要按照实际场景来，而非机械进行套用。

如果是设计一整套网站系统，站点地图必不可少。站点地图可以对整个网站的架构可以构建起一个初步的印象，像架构层级过深、页面内容重复等问题都可以通过站点地图发现，以全局的角度去观察整个产品，而不是单一的某个功能、某个页面。

体验地图可以把产品在不同使用场景、流程下的体验问题直观地呈现出来，我们通过调研，会得到一些用户的体验反馈，但是通常比较杂乱、没有逻辑性。通过体验地图可以整理出用户使用产品大概有哪些场景和环节，各场景和环节下都遇到过什么样的问题，哪些问题出现的频率较高等，让产品经理能够更贴近用户，沉浸到使用产品的实际体验过程中去，进而思考各场景、环节下都可以进行怎样的设计目标拆解与设计优化、最终帮助完成产品的整体目标。

流程图也是一个常用工具，明确展示出用户使用产品的流程和步骤是怎样的。通过它可以查找步骤是否可以合并优化，能否抽象出通用的流程来构建框架设计等。

》》

产品框架设计构建起产品的轮廓，抽象出通用的布局原则，页面上大概有哪些模块，这些模块之间的主次、优先级关系是怎样的。整体规划把握界面的结构、模块之间的关系呈现等，而不是纠结于一些细枝末节和不重要的内容上。

》》

线框图在产品框架设计的基础上具化出了产品的完整骨架。在绘制线框图的时候需要仔细考虑到每一个可能的使用场景，包括负面、误用等特殊情况都要包括在内。

Axure是绘制产品经理绘制线框图的常用的工具。在Axure中，通过命名页面和调整层级关系，建立站点地图。在每个页面中根据场景画出线框图，包括具体的功能及场景，可以加以文字说明，辅助以用例交互。

线框图不是视觉设计稿，但在视觉效果呈现上却马虎不得。如果在绘制线框图的时候不考虑如产品尺寸、页面规范等，最终完成得会比较粗糙，也容易对内容的编排产生影响，导致整个页面结构都要被迫调整之类的情况，只能增加产品设计成本，而在最开始就注意这方面的问题，就可以尽可能地避免类似的情况发生。

》》

视觉稿作为产品设计的最终产出，在线框图的基础上完成配色、图标绘制等视觉细节，为产品“涂脂抹粉”。视觉稿选择关键场景的界面进行绘制表现，注意一些Hover/Active之类的状态表现，然后就可以标注交付前端了。

这是产品设计文档中比较常见也比较重要的的几部分内容，根据你自己的需要和公司的规定、项目的具体情况，选择需要重点体现的内容，也可以有所增删，并不是一成不变的。

首先，产品经理可以根据项目的阶段运营目标提出合理需求，通过PRD文档阐述产品整体设计需求背景，设计思路，功能范围，交互逻辑，页面细节及其他信息。

其次，团队的相关人员可以快速获取自己需要的信息，节省反复沟通的时间成本，更好地开展工作。

最后，产品需求文档也是一个产品项目投入开发前的重要附件之一。团队领导可以根据产品需求文档清晰了解为什么需要开发这样一款产品。项目的其他相关方也可以随时参阅需求文档，了解项目的基本信息。

产品文档的好坏会直接影响到整个团队的工作进程，因此产品需求文档对产品经理来说是一项非常重要的工作。

在工作过程中可以使用摹客等专业文档撰写管理工具，结合设计稿和原型图进行说明，也支持在线审阅，可以让产品经理的工作效率大大提升。

需求文档的编写内容包括很多的，但是需要根据该软件的规模和具体要求进行编写。 一份比较完整的详细需求分析应该包括：1. 前言 2. 摘要 3. 系统详细需求分析 3.1. 详细需求分析 3.1.1. 详细功能需求分析 3.1.2. 详细性能需求分析 3.1.3. 详细信息需求分析 3.1.4. 详细资源需求分析 3.1.5. 详细组织需求分析 3.1.6. 详细系统运行环境及限制条件需求分析 3.1.7. 信息要求 3.1.8. 性能要求 3.2. 接口需求分析 3.2.1. 系统接口需求分析 3.2.2. 现有软、硬件资源接口需求分析 4. 总体方案设计4.1. 系统总体结构 4.1.1. 系统组成、逻辑结构 4.1.2. 应用系统结构 4.1.3. 支撑系统结构 4.1.4. 系统集成 4.1.5. 系统工作流程

.2. 分系统详细界面划分 4.2.1. 应用分系统与支撑分系统的详细界面划分 4.2.2. 应用分系统之间的界面划分 5. 应用分系统详细设计 5.1. XX分系统详细需求分析 5.1.1. 功能详细需求分析 5.1.2. 性能详细需求分析 5.1.3. 信息详细需求分析 5.1.4. 限制条件详细分析 5.2. XX分系统结构设计及子系统划分 5.3. XX分系统功能详细设计 5.4. 分系统界面设计 5.4.1. 外部界面设计 5.4.2. 内部界面设计 5.4.3. 用户界面设计 6. 数据库系统设计 6.1. 设计要求 6.2. 信息模型设计 6.3. 数据库设计 6.3.1. 数据访问频度和流量 6.3.2. 数据库选型 6.3.3. 异构数据库的连接与数据传递方式

6.3.5. 数据共享方式设计 6.3.6. 数据安全性及保密设计 6.3.7. 数据字典设计

8. 信息编码设计 8.1. 代码结构设计 8.2. 代码编制 9. 关键技术 9.1. 关键技术的提出 9.2. 关键技术的一般说明 9.3. 关键技术的实现方案 10. 系统配置 10.1. 硬件配置 10.2. 软件配置 11. 限制 12. 组织机构及人员配置 12.1. 机构调整与确认 12.2. 组织机构的任务和职责 12.3. 人员配置方案 12.4. 培训计划 13. 工程实施计划 13.1. 分期实施内容 13.2. 进度计划 13.3. 实施条件 13.4. 测试与验收 14. 投资预算 15. 参考和引用资料

16. 术语

这里还有很需要补充的，也有很多是可以不写的；因为一份需求文档不是谁能写的，呵呵，在实际的工作中

是那些负责人才能写这个的。如果是课设的话，只要在流程图 逻辑结构 或者是XX分系统的设计图上下点功夫就好了。说到格式 就是按上面的写 然自己弄一个目录 就像是我们平时翻书的时候看到的那种，这样好阅读。