中后台产品文档撰写技巧.docxVIP

中后台产品文档撰写技巧 不同于C端产品对于体验的关注，中后台产品更注重逻辑的严谨、流程的完整、使用的稳定性等底层逻辑，因此中后台产品原型的设计需要关注的点更复杂，今天我们来聊一聊如何写好一套中后台产品文档。 一、产品文档写给谁看 作为产品，撰写产品文档是工作职责内的本分，但是我们是否考虑过，除了写出来感动自己、证明工作量以外，这套文档是给谁看的？只有明确了给谁看，才能进一步明确文档要呈现的内容范围。 1、给业务看 产品文档是业务需求实现的蓝图，好的产品一定是充分满足了业务需求，为了保证产品设计与业务需求准确匹配，产品文档应该在设计过程中与业务方频繁的确认，保证在与技术评审之前得到业务方的确认。 业务所关注的是业务逻辑的正确性和页面内容的完整性，所以文档设计的时候要考虑到业务流程图的示意和页面字段的解释。 这里要注意的是，业务方包括但不限于需求方，还可能包含系统功能链条上的其他业务方，比如一些需要限制权限的功能，可能还需要和系统管理员去沟通权限点的设计细节。 2、给UI/前端看 我们知道，产品的五层结构包括了：表现层（视觉设计）、架构层（界面布局和信息内容）、结构层（交互和信息结构）、范围层（功能规范和内容需求）、战略层（用户需求和运营目标）。 在这五个层级里面，表现层和架构层是用户看得到的，直接影响了用户对产品的理解和体验感受，这两层在实际的项目中属于UI/前端（有时还有用户体验这样的职位）人员负责的范围，所以在进行产品文档撰写的时候，要注意明确页面结构和交互呈现形式的说明。 3、给后端开发看 产品的五层结构中，结构层和范围层是用户看不到的层面，这是后端开发的工作范围。为了让后端开发充分的理解系统结构和数据结构，产品文档不能只“画图”，还应该对底层的数据、流程和逻辑做充分的说明。有些需要接口对接的需求，还需要明确对接的接口、字段和规则。 4、给测试看 测试是需求的第一个使用者，只有充分理解了产品设计规则，才能明确的撰写测试用例并进行系统功能的验证，测试需要考虑到一般场景和异常场景下系统的处理策略，所以产品应该提前预想到异常的场景，并在文档中给出处理策略。 二、文档形式 在分析了给谁看的问题以后，我们找到了产品文档需要呈现出的几个关键点：业务流程、系统规则（正常/异常）、页面结构（页面间/页面内）、交互形式、字段说明、数据结构，有了这些关键点作为参照，产品文档在形式上就不会有太大遗漏。 基于这些关键点撰写产品文档时，规范来讲会产出PRD文档，即以图文的形式从各个角度去描述系统的功能，但是如果没有特殊要求的情况下，笔者一般会用产品原型的形式产出产品文档，当然无论文档形式如何，都应该确保包含了上述关键点。 1、规范版：图文结合的PRD文档 下图中，笔者整理了PRD文档的一套目录，需要的产品朋友按照这个目录去整理需求文档，就可以比较全面的包含需求的各个重点： 需求背景介绍，描述需求产生的背景以及需求方希望达到的效果，如果有关联业务方也应该予以说明。如果是给外部需求的项目，还应该简单的介绍外部需求方的情况，如公司现状和业务模式等； 核心规则说明，描述业务逻辑以及产品设计的基本规则，如果文档中涉及到多套业务场景，应该首先解释多个业务场景之间的关系和区别，然后再做逐个介绍，这里除了可以用文字和图表的形式说明，还可以加入梳理好的业务流程图方便读者理解； 特殊规则说明，这部分是对一些特殊场景或者特殊规则的说明，在说明的时候应该明确与一般规则之间的关联，这部分不一定每个需求都需要，可以酌情删减； 数据源，说明底层数据的来源以及应用，包括内部来源和外部来源，内部来源是系统本身产生的数据，外部来源包括接口调取的数据和爬虫获取的数据等，为功能和页面设计中的字段说明做准备； 功能以及页面设计，描述每个功能模块的范围，展示内含的产品设计页面图，并对页面中的字段做字段性质说明、操作按钮做交互说明，涉及到权限的还应该做可见/可用权限说明； 在文档结构只上，如果是同一个模块下频繁的在一个文档中修改，则应该增加文档的版本记录，以记录下每期需求变更的范围。 2、草根版：五脏俱全的原型图 下图是笔者常用的产品文档，以原型文档为载体（不拘泥与墨刀或者RP），按照实际的模块页面结构去撰写，在页面结构之外再配合统一的版本记录和规则说明。在此结构下可以完善的表达系统的表现层（视觉设计）、架构层（界面布局和信息内容）、结构层（交互和信息结构）、范围层（功能规范和内容需求）、战略层（用户需求和运营目标）的产品逻辑： 1）版本记录 因为中后台模块逻辑关联性很强，所以建议一个模块一套原型，在一套原型下去做不同版本的变更，当然如果遇到大的变更还是建议将历史版本单独备份。版本记录这里就是记录此模块下每个版本变更的业务背景、业务目标、变更的系统规则和变更的系统页面范围； 2）规则说明 这里