2023年一看就会！中后台产品文档撰写技巧

一看就会！中后台产品文档撰写技巧class="size-fullwp-image-5788868aligncenter"src="/wp-files/2023/03/ZLWu4dFzaVJPt5yU2Tlp.jpg"alt=""width="900"height="420"/>

不同于C端产品对于体验的关注，中后台产品更注意规律的严谨、流程的完整、使用的稳定性等底层规律，因此中后台产品原型的设计需要关注的点更简单，今日我们来聊一聊如何写好一套中后台产品文档。

一、产品文档写给谁看

作为产品，撰写产品文档是工作职责内的本分，但是我们是否考虑过，除了写出来感动自己、证明工作量以外，这套文档是给谁看的？只有明确了给谁看，才能进一步明确文档要呈现的内容范围。

1、给业务看

产品文档是业务需求实现的蓝图，好的产品肯定是充分满意了业务需求，为了保证产品设计与业务需求精确     匹配，产品文档应当在设计过程中与业务方频繁的确认，保证在与技术评审之前得到业务方的确认。

业务所关注的是业务规律的正确性和页面内容的完整性，所以文档设计的时候要考虑到业务流程图的示意和页面字段的解释。

这里要留意的是，业务方包括但不限于需求方，还可能包含系统功能链条上的其他业务方，比如一些需要限制权限的功能，可能还需要和系统管理员去沟通权限点的设计细节。

2、给UI/前端看

我们知道，产品的五层结构包括了：表现层（视觉设计）、架构层（界面布局和信息内容）、结构层（交互和信息结构）、范围层（功能规范和内容需求）、战略层（用户需求和运营目标）。

在这五个层级里面，表现层和架构层是用户看得到的，直接影响了用户对产品的理解和体验感受，这两层在实际的项目中属于UI/前端（有时还有用户体验这样的职位）人员负责的范围，所以在进行产品文档撰写的时候，要留意明确页面结构和交互呈现形式的说明。

3、给后端开发看

产品的五层结构中，结构层和范围层是用户看不到的层面，这是后端开发的工作范围。为了让后端开发充分的理解系统结构和数据结构，产品文档不能只“画图”，还应当对底层的数据、流程和规律做充分的说明。有些需要接口对接的需求，还需要明确对接的接口、字段和规章。

4、给测试看

测试是需求的第一个使用者，只有充分理解了产品设计规章，才能明确的撰写测试用例并进行系统功能的验证，测试需要考虑到一般场景和特别场景下系统的处理策略，所以产品应当提前预想到特别的场景，并在文档中给出处理策略。

二、文档形式

在分析了给谁看的问题以后，我们找到了产品文档需要呈现出的几个关键点：业务流程、系统规章（正常/特别）、页面结构（页面间/页面内）、交互形式、字段说明、数据结构，有了这些关键点作为参照，产品文档在形式上就不会有太大遗漏。

基于这些关键点撰写产品文档时，规范来讲会产出PRD文档，即以图文的形式从各个角度去描述系统的功能，但是假如没有特别要求的状况下，笔者一般会用产品原型的形式产出产品文档，当然无论文档形式如何，都应当确保包含了上述关键点。

1、规范版：图文结合的PRD文档

下图中，笔者整理了PRD文档的一套名目，需要的产品伴侣根据这个名目去整理需求文档，就可以比较全面的包含需求的各个重点：

需求背景介绍，描述需求产生的背景以及需求方盼望达到的效果，假如有关联业务方也应当予以说明。假如是给外部需求的项目，还应当简洁的介绍外部需求方的状况，如公司现状和业务模式等；核心规章说明，描述业务规律以及产品设计的基本规章，假如文档中涉及到多套业务场景，应当首先解释多个业务场景之间的关系和区分，然后再做逐个介绍，这里除了可以用文字和图表的形式说明，还可以加入梳理好的业务流程图便利读者理解；特别规章说明，这部分是对一些特别场景或者特别规章的说明，在说明的时候应当明确与一般规章之间的关联，这部分不肯定每个需求都需要，可以酌情删减；数据源，说明底层数据的来源以及应用，包括内部来源和外部来源，内部来源是系统本身产生的数据，外部来源包括接口调取的数据和爬虫猎取的数据等，为功能和页面设计中的字段说明做预备；功能以及页面设计，描述每个功能模块的范围，展现内含的产品设计页面图，并对页面中的字段做字段性质说明、操作按钮做交互说明，涉及到权限的还应当做可见/可用权限说明；在文档结构只上，假如是同一个模块下频繁的在一个文档中修改，则应当增加文档的版本记录，以记录下每期需求变更的范围。2、草根版：五脏俱全的原型图

下图是笔者常用的产品文档，以原型文档为载体（不拘泥与墨刀或者RP），根据实际的模块页面结构去撰写，在页面结构之外再协作统一的版本记录和规章说明。在此结构下可以完善的表达系统的表现层（视觉设计）、架构层（界面布局和信息内容）、结构层（交互和信息结构）、范围层（功能规范和内容需求）、战略层（用户需求和运营目标）的产品规律：

1）版本记录

由于中后台模块规律关联性很强，所以建议一个模块一套原型，在一套原型下去做不同版本的变更，当然假如遇到大的变更还是建议将历史版本单独备份。版本记录这里就是记录此模块下每个版本变更的业务背景、业务目标、变更的系统规章和变更的系统页面范围；

2）规章说明

这里一般会包含业务流程的具体描述和流程图、核心的业务计算规律、数据源和数据规律、涉及到权限则需要说明权限范围。这里不要只拘泥于文字的描述，要更多的使用表格和图形，便利规章的解释，另外，规章假如有变更的，应当说明变更前和变更后两套规律分别是什么，便利读者理背景和目标；

3）系统页面

i页面的编号：根据实际要实现的页面结构撰写，每个页面根据结构编号，这里做编号有两个好处，一是在描述页面之间关联的时候可以精确     的指定某个页面，比如“跳转到1.1”或“数据取自2.1中的XX字段”，二是在进行产研沟通的时候节约了解释的成本，究竟有些页面的名称比较近似。这里的编号不要随版本变化修改，假如有新的页面就给与新的编号，避开引起混乱；

ii主页面的描述：包含多个子页面的主要页面，一般单独展现一个页面，这样能够保证原型规律与实际页面规律的全都性，便利前端的理解；在原型撰写的时候，主页面的描述中突出下属每个子页面的功能范围；

iii子页面的描述：具体的页面中主要呈现页面中所包含的内容以及操作，并解释说明内容和操作的具体规章。在进行说明的时候，首先要为页面划分大的区域，比如筛选区域、列表区域等，然后针对每个区域需要说明要素的名称和类型（字段/按钮/链接等），在对每个要素具体说明。具体说明要素的时候需要留意说明关联的弹窗、操作，并说明交互和系统推断的规律，留意要考虑到特别反馈的规律，涉及到计算的还应当说明数据的来源和计算规章。

下图是笔者在实际业务中页面的说明文档：

三、其他重要的点

1、不拘形式

每个项目会有自己的特点、每个需求中的侧重点也会不一样，比如数据系统关注数据的来源和规律、工单系统关注业务流程、客户系统关注用户的信息和标签，要依据实际的业务需求选择产品文档