如何撰写优秀的中后台产品文档?

文摘   2024-10-27 11:00   宁夏  


不同于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、不拘形式

每个项目会有自己的特点、每个需求中的侧重点也会不一样,比如数据系统关注数据的来源和逻辑、工单系统关注业务流程、客户系统关注用户的信息和标签,要根据实际的业务需求选择产品文档的撰写形式,只要能做到让所有读者充分理解,就是好的产品文档;

2、心态要稳

不要被完美主义心态牵制,自己觉得再完美的文档,也总会有人想要来挑刺,自己对自己要有个认知和定位,必要被外界的评论过分影响,只要不断进步就是好的;也不要怕变化,如果听到不一样的声音发现那是对的,那就吸收它然后成长为自己的能力。



作者:梦溪

来源网络博客

题图来自 Unsplash ,基于 CC0 协议,如有侵权,请联系VX:pmtalk123删除


品牌推广| 内容撰写|广告投放|培训合作

请添加微信  PMxiaowanzi 



每日案例拆解库,AI等产品打卡群

 

PMTalk创建的产品设计打卡社群,加入后365天,每天体验一款APP。提升产品设计能力,同时有1300份体验报告帮助你找到竞品。

 

在这里你可以随时查询到你想找的各类竞品行业APP,无须自己亲自下载就可以马上得到APP的一手产品优化、交互设计、功能描述信息。

 

从优化&建议、商业模式、运营、功能描述、交互设计、产品定位至少6个维度,体验一款应用。

 

平均1天1块钱,扫码购买即可加入 

 连续体验48款应用,通过后原路退回

 



报名后,请添加星球助理(否则报名无效)

PMTalk123


PMTalk产品经理社区
国内Top的产品经理社区,聚集21W人产品经理、运营、设计师等互联网人成长; 全国800+位产品领域大佬入驻签约作者; 每年举办70+场产品运营增长活动 ;你想知道的产品经理知识全部在这儿~
 最新文章