产品自查手册

在网上看到很多产品自查手册，从交互体验到账号规则到数据等等，洋洋洒洒记录了产品各个方面的设计要点，列出要注意什么。

很多产品团队或多或少都有类似要求，但不一定整理成册，或者不要求执行。曾经我们PaaS团队也有用checklist来验收产品，一开始执行不错，后面因为某些原因变得有点形式化。与朋友聊到他们的团队也有类似的设计规范，但规范内容会尽量放简单，因为看的人很少，大多规范只有初级产品看，没必要投成本于此。

在产品学习过程中，我也梳理过这些自查项。曾经把页面设计分成很多模块组件，从页面图标ico，到菜单栏，到图片布局，甚至到网站声明，都一一列出来规范和检查项。但结果是，在产品设计时几乎不看，或者忘记要看。只有偶尔翻到，才会花几分钟看看里面的内容。

相信这样的情况不是个例。出于工作习惯或者工作规范，我们都会整理自查手册。但没用起来的原因，我整理以下：

1、规范太多太细难以落地

我们写自查手册的时候，是从“被检查的部分怎么做才更规范”的角度出发，而不是从“自查时应注意什么”，因此会整理出很多很详细的规范，甚至到字体字号字数行距列宽等等。

2、被现实打败

现实工作中很多需求只是局部的优化，并不涉及全局。因此在产品设计时，不需每个模块完整设计，而只需突出主要特性。检查时也只会检查改动部分，不会全盘回归检查，甚至不想在小改动上花时间自查。且一旦在时间压力下，或出于惰性，产品经理顾不上所有细节，很难将自查手册严格执行到位。

其实产品自查手册的意义在于：

• 帮助检查产品能否满足真正的业务和用户需求
• 检查产品设计是否有瑕疵，设计缺陷
• 排查可能因此设计而产生的二次缺陷
• 使产品设计符合一致性，更贴合产品调性和减少用户疑惑

道理都懂，但就是做不好。已经有这么多产品自查手册，但都会产生类似的问题，那自查手册是否多余？估计很多人都不会觉得多余，但大家就是不想自己被要求执行。

那有什么办法，让大家用好自查手册呢？（这才是“产品自查手册”真正的需求）有两个解决方案：

1、自动化测试

如果自查手册用于检测各个模块是否符合设计规范，当人工懒得一条条对着检查时，可以借助机器帮忙逐一检查。这就是自动化测试的实战应用。将设计规范写成脚本，作为一个个检查项，在完成产品设计时，以及产品上线前，分别跑一次规范性验证即可。

2、“说人话”

产品自查手册如果很详细，人工检查成本会很高，执行的人会很少，很可能变成一纸空文。其实产品自查手册可以是一本应用书，而不一定是本理论书。因此除了将“理论书”脚本化以外，还可将检查项以“检查”的角度出发予以改写。改写后的规范一定要简化，容易记忆，适合思考思路，也就自然容易执行开。

写脚本的事就不必多说，可以说说怎么“说人话”来优化自查手册。

1、按两个维度分类，叠加出16种需求影响场景：

• 按影响范围维度分类：全站设计、全页设计、模块设计、控件设计。
• 按需求类型：功能需求、性能需求、数据需求、文案需求

2、选择场景，列出自查关键因子

根据各个场景，结合业务特性，分别列出要自查的关键因子和自查问题，供选择自查。例举一些：

全站设计×功能需求的关键因子：

• 登录
  • 登录页长怎样，地址是什么
  • 用什么账号登录
  • 怎么认证账号，是否具备验证机制（成功、失败如何表现）
  • 有没有管理账号
• 默认页
  • 有没有访问权限控制
  • 是否个性化配置

全站设计×数据需求的关键因子：

• 初始化数据
  • 有没有数据权限控制
  • 按什么查询条件初始化数据
• 空白页
  • 无权限时怎么显示，
  • 数据空白时怎么显示

控件设计×功能设计的关键因子：

• 标准化
  • 默认显示什么
  • 有没有非标要求
  • 有什么使用前提
  • 交互产生什么结果
• 控件关系
  • 该控件联动什么控件
  • 该控件被什么控件联动

……

3、对照以上因子和问题，拿不同需求自查几遍。