导语：增删查改显算传，异常情况考周全，文案简洁无歧义，类似场景要对齐。交互设计符预期，中间状态勿忘记。逻辑漏洞细细缕，关系变化高发区。账号权限上下游，依赖关系记心头。各个环节求闭环，兜底方案保齐全，口诀默念记心里，助你评审皆顺利！

各位产品小伙伴，在方案评审时，有没有因为方案考虑不周，而被喷过？如果要挑选一个产品经理尴尬的时刻，评审会上被技术和运营伙伴喷，肯定要算上一个了。

究其原因，无外乎是产品方案考虑不周，逻辑不顺，漏洞百出。尤其是刚入行的产品伙伴，更是如此。做方案时感觉已经考虑的很周全了，一到评审会上，就发现好多地方确实没考虑到。

回想我当初刚开始入行时，也遇到了同样的问题。后来做的时间久了，慢慢的发现容易忽略的往往都集中在某几类问题上。于是我结合这些年的经验，编写了一个方案的自检口诀，方便记忆。

各位可以每次做完方案后，按照此口诀快速自检走查一下。

此口诀共计14句98个字，具体如下：增删查改显算传，异常情况考周全，文案简洁无歧义，类似场景要对齐。交互设计符预期，中间状态勿忘记。逻辑漏洞细细缕，关系变化高发区。账号权限上下游，依赖关系记心头。各个环节求闭环，兜底方案保齐全，口诀默念记心里，助你评审皆顺利！

下面就展开说明一下：

一、增删查改显算传，异常情况考周全

做过技术的都知道，系统最基本的四个操作就是对数据的增删查改，再加上数据如何展示（显）、数据的计算规则（算）、数据的传输（传），基本上就覆盖了所有对数据的操作了。

• 增：数据的新增。比如我们要做一个学习系统，那么需要新增的就是课程、班级、人员等维度的数据。
• 删：数据的删除。需要注意删除时是否需要确认，是逻辑删除还是物理删除？
• 查：数据的查询。查询时是精准查询还是模糊查询等。
• 改：数据的编辑。需要考虑谁有权限编辑？什么时候编辑？具体编辑哪些字段等等。
• 显：数据的显示。显示时的样式如何，如果数据量或者文字太多如何处理显示。
• 算：数据的计算规则。比如文章的阅读量的计算规则是什么样的。
• 传：数据的传输。比如数据是实时同步，还是定时同步。同步时是增量还是全量等等。

可以看出，针对这七个对数据的操作，每一个操作都有一些要注意的细节,我们可以结合5W2H来进行逐步检查，5W2H，即who、when、where、why、what、how、how much 。

• who：主要是涉及到权限。谁能进行相应的操作；
• when：主要涉及什么时候能进行操作，比如删除时，有些数据有关联时，是不允许进行删除操作的；
• where：主要涉及操作的入口在哪里？展示的具体位置在哪了；
• why：为什么要有这个功能，可不可以没有；
• what：操作的具体部分是什么？
• how：如何进行操作，操作流程是什么？
• how much：操作步骤有几步？可不可以减少？

5W2H不一定每一个维度都涉及到，但可以帮助我们考虑的更周全。我将七个操作和5W2H整理成一张对应的二维表，如下：

以上都是我们按照理想情况去考虑的，但实际执行时，总会千奇百怪，所以我们要尽可能的把异常case考虑全面。所谓异常，就是指程序一旦不是按照我们预期的情况执行时，我们应该如何处理。

最基本的就是比如名称重复了，或者进行操作或同步数据时网络中断了、查找数据时找不到对应数据了等等。

二、文案简洁无歧义，类似场景要对齐

我们做产品方案时，有时需要写提示文案语，其目的是能及时的告之用户目前系统的状态。

提示语简单来说分为三种：一种是引导用户进行某种操作，比如请填写手机号；一种是预防用户进行某种操作，比如禁止删除；**一种是简单的通知，告之系统目前的状态，比如提交成功、删除成功等。

无论哪种类型，其目的就是要把文案的信息快速准确的传递给用户，所以此类文案编写的两个原则就是简洁、无歧义。

快速要求简洁，准确要求无歧义。

所谓简洁，就是用一句话能描述清楚的，绝不啰嗦两句话。比如删除的提示语：”确定删除吗？删除后将不可见“就不够简——”删除后将不可见“就有点多余。这里有一个原则，就是长提示语一般不要超过20个字，否则大概率就违背简洁原则了，可以尝试缩减到20个字之内。

所谓无歧义就是要逻辑通顺，确保每个人看到后，理解的都一样。

这里举一个反例，就是个人所得税APP中，当你由于换工作需要修改个税申报方式时，会让选择更换扣缴义务人原因，这时候你会想选择”变更工作单位“，但细看其提示文案时，就纠结了，因为文案里有一句”原单位继续扣除“的描述，这就是一句有很大歧义的文案，让很多人搞不明白。

还有一点，就是在类似的场景中，文案内容、文案所采用的句式都要保持一致，这样可以保持产品的统一性，给用户以专业的感觉。常见的反例就是，同样是提交的场景，有的提示语是“保存成功”，有的叫“提交成功”。

**一点，就是文案避免出现常识性的错别字，比如登录写成登陆、账号写成帐号等。

三、交互设计符预期，中间状态勿忘记

做交互设计时，当你不知道如何设计时，有一个原则屡试不爽，就是站在用户的角度，设想用户的预期是什么？

比如用户查询报表，当点击查询按钮，遇到数据量大时，用户的预期是希望可以看见加载的状态。比如”loading…“，这时候如果你设计了，就基本符合用户预期了，反之如果没有设计，就一直在那等着，用户就感觉不知道发生了什么情况，是没数据吗？体验自然不好。

但如果你进一步设计了加载的进度百分比，甚者显示剩余时间，那么就算超用户预期了，用户就会夸你用户体验好。

交互过程中的中间状态往往容易忽略，比如同步数据时，状态一般分为未同步、同步中、同步完成。数据量少时还好，可以瞬间同步完成。但如果数据量大时，就可能要同步几分钟，这个时候要切记得把同步中的状态设计出来，比如用一个旋转的图标代表“数据同步中”。

四、逻辑漏洞细细缕，关系变化高发区

逻辑漏洞是原型方案比较常见的问题，最常见的逻辑漏洞大致分为几种：