蓝海情报网

写好需求文档的 9 个关键细节,你一定要知道!

蓝海情报网 325

写好需求文档的 9 个关键细节,你一定要知道!

最近看下属写的产品文档,逻辑混乱又贼难懂,估计 GPT 都读不了。

预计 10 分钟左右的评审,硬生生拖改了几天,真的差点被气哭。。

所以含泪写了几个小时,总结出我写需求文档的 9 个工作细节:颜色对比、大小差异、形状区分、符号标记、避免歧义、图表呈现、维度提炼、概念封装、领域知识。

如果你工作中也遇到了类似问题,不妨看看。

颜色对比

通过颜色深浅、色域对比,可以让人一下就抓到文档重点。

写好需求文档的 9 个关键细节,你一定要知道!

日常撰写需求文档时,你可以试着用红字标记重要内容或说明。

我有一个习惯是,会用蓝字去表示一些可跳转的页面或交互。

大小差异

在一些 UI 设计规范中,一般有字体大小的使用规则。

例如 22px 用于页面标题、17px 用于列表标题、14px 一般是列表描述文字。

写好需求文档的 9 个关键细节,你一定要知道!

其实我蛮建议初级的产品经理,去学习一两个组件库的设计规范,包含字体图标、组件说明、颜色大小等内容。

毕竟产品经理掌握组件库,是一种快速提升审美能力的途径。

形状区分

假设文档通过颜色对比、大小差异等优化后,呈现的内容还是难以理解和吸收,你可以尝试增加形状这一维度,进一步降低文档的阅读难度。

就像我们熟悉的流程图,绘制时会用圆角矩形代表起始节点、矩形代表流程动作、菱形代表条件判断。

符号标记

符号标记,指的是通过一些特殊符号,去突出重要内容的层次,加深文档读者的印象。

写好需求文档的 9 个关键细节,你一定要知道!

我一般喜欢用中英文间隔、 【】「」等符号,来突出文档中的一些重要内容。

避免歧义

我发现初中级产品在撰写文档时,最容易犯的高频错误,就是文档中出现的各种内容歧义。

例如列表的某个数据,需要显示 clients 表的 name 字段。这个表又有各种类似的数据 full_name、first_name、display_name。

写好需求文档的 9 个关键细节,你一定要知道!

如果你在文档中写的规则是显示客户名称,那前后端联调、测试验收时大概率会出各种小问题。

他们有可能会懵逼卡壳一两个小时,然后去猜、去问客户名称到底是指什么?

到底是用户表、游客表还是客户表呢?哦搞了半天原来是 clients 客户表。那客户名称这个字段,又是 clients 客户表的全名、名称、姓氏这些中文翻译,对应的哪一个英文字段呢?

运气好的话,前后端经过一番折腾,或许能显示你期望的内容。

但大多数情况,由于你完全不懂其中的数据逻辑和细节,所以只要面上过得去没有明显 BUG,你可能就草草验收了事,或者验收时出错,你连问题在哪排查都不知道。

我说的这种情况,其实只是最基础、简单的一个表数据出错。

可以想象更复杂的财务账单数据,要是数据能对上的话,那应该是平时有烧香拜佛、买中彩票了吧。

图表呈现

一图胜千言,能用图表的尽量图表呈现。

比如某些复杂的知识概念,可能需要几百字才能阐述清楚,如果通过图片、表格进行呈现,或许看的人几分钟就完全明白了。

写好需求文档的 9 个关键细节,你一定要知道!

我记得刚做产品时,就遇到了对产品新人来说,比较复杂的订单状态定义,当时尝试了文字描述,我写的麻烦、耗时不说,看得人也非常费劲。

后来学会了 UML,用几分钟画个简单的状态图直接搞定,清晰直观。

维度提炼

没有经过优化加工的内容,可以说只是一堆无序、混乱的信息。

要让这些信息变成通俗易懂、持续复用的知识,你需要把它们进行总结提炼,并找出内容的差异和共性,然后抽象出维度属性。

最后将信息按维度,进行整理归纳、分门别类,这个思考过程可以称为维度提炼。

脱不花老师在《沟通的方法》中,分享过一个职场的倾听方法,叫结构化倾听。

即把沟通中的话题,提炼成了情绪、事实和期待等 3 个维度。

概念封装

概念封装,核心是将内容进行压缩和简化,提升内容的复用率。

具体指的是用一个简单的概念,去表示一系列关联度较高、重复使用的复杂内容。

概念封装的好处是,一次定义,持续复用。

写好需求文档的 9 个关键细节,你一定要知道!

像我的需求文档模版中,常用的全局说明、名词解释、公式复用、参数说明、公共组件、交互解耦等文档模块,就是概念封装的一些使用场景。

领域知识

如何才能快速提升文档的沟通效率?其实核心在于,呈现领域知识。

简单来说,就是当面对不同的读者时,你要针对性地呈现专业内容。

公司的老板时间都很宝贵,所以你要在一两分钟内,就让他快速 Get 到文档重点。这时候内容就要侧重于简洁,大白话讲清楚文档的核心概念。

如果是针对业务方,一方面你要表达得简单易懂,另一方面又要呈现专业的业务知识,重点是快速达成双方共识。

当面对前后端团队时,你还要基于开发视角和技术知识,撰写便于他们理解的文档。

内容不限于写清楚数据处理、异常分支等复杂的规则交互等。

很多初级产品经理一定会遇到这种情况,自己花一小时写了一堆洋洋洒洒的文档说明,开发居然一个字都不看。

其实这是因为文档呈现的内容,并不是开发通用语言,理解起来太费劲了。

更好的做法是,找到类似 UML 这种统一建模语言,画几个状态图、流程图来呈现你的需求,既专业又高效。

总结

产品经理在日常工作中,如何才能让撰写的需求文档,显得既清晰、又专业?

核心在于做好这 9 点:颜色对比、大小差异、形状区分、符号标记、避免歧义、图表呈现、维度提炼、概念封装、领域知识。

看完觉得写得好的,不防打赏一元,以支持蓝海情报网揭秘更多好的项目。

标签:

ad2

推荐内容