各位产品小伙伴，在方案评审时，有没有因为方案考虑不周，而被喷过？如果要挑选一个产品经理尴尬的时刻，评审会上被技术和运营伙伴喷，肯定要算上一个了。
究其原因，无外乎是产品方案考虑不周，逻辑不顺，漏洞百出。尤其是刚入行的产品伙伴，更是如此。做方案时感觉已经考虑的很周全了，一到评审会上，就发现好多地方确实没考虑到。
回想我当初刚开始入行时，也遇到了同样的问题。后来做的时间久了，慢慢的发现容易忽略的往往都集中在某几类问题上。于是我结合这些年的经验，编写了一个方案的自检口诀，方便记忆。
各位可以每次做完方案后，按照此口诀快速自检走查一下。
此口诀共计14句98个字，具体如下：
增删查改显算传，异常情况考周全，文案简洁无歧义，类似场景要对齐。交互设计符预期，中间状态勿忘记。逻辑漏洞细细缕，关系变化高发区。账号权限上下游，依赖关系记心头。各个环节求闭环，兜底方案保齐全，口诀默念记心里，助你评审皆顺利！
下面就展开说明一下：
01 增删查改显算传，异常情况考周全
做过技术的都知道，系统最基本的四个操作就是对数据的增删查改，再加上数据如何展示（显）、数据的计算规则（算）、数据的传输（传），基本上就覆盖了所有对数据的操作了。
- 增：数据的新增。比如我们要做一个学习系统，那么需要新增的就是课程、班级、人员等维度的数据。
- 删：数据的删除。需要注意删除时是否需要确认，是逻辑删除还是物理删除？
- 查：数据的查询。查询时是精准查询还是模糊查询等。
- 改：数据的编辑。需要考虑谁有权限编辑？什么时候编辑？具体编辑哪些字段等等。
- 显：数据的显示。显示时的样式如何，如果数据量或者文字太多如何处理显示。
- 算：数据的计算规则。比如文章的阅读量的计算规则是什么样的。
- 传：数据的传输。比如数据是实时同步，还是定时同步。同步时是增量还是全量等等。
可以看出，针对这七个对数据的操作，每一个操作都有一些要注意的细节,我们可以结合5W2H来进行逐步检查。
5W2H，即who、when、where、why、what、how、how much 。
- who:主要是涉及到权限。谁能进行相应的操作。
- when:主要涉及什么时候能进行操作，比如删除时，有些数据有关联时，是不允许进行删除操作的。
- where：主要涉及操作的入口在哪里？展示的具体位置在哪了。
- why:为什么要有这个功能，可不可以没有。
- what：操作的具体部分是什么，
- how:如何进行操作，操作流程是什么？
- how much:操作步骤有几步？可不可以减少？
5W2H不一定每一个维度都涉及到，但可以帮助我们考虑的更周全。
我将七个操作和5W2H整理成一张对应的二维表，如下：
以上都是我们按照理想情况去考虑的，但实际执行时，总会千奇百怪，所以我们要尽可能的把异常case考虑全面。
所谓异常，就是指程序一旦不是按照我们预期的情况执行时，我们应该如何处理。最基本的就是比如名称重复了，或者进行操作或同步数据时网络中断了、查找数据时找不到对应数据了等等。
02 文案简洁无歧义，类似场景要对齐
我们做产品方案时，有时需要写提示文案语，其目的是能及时的告之用户目前系统的状态。
提示语简单来说分为三种：一种是引导用户进行某种操作，比如请填写手机号；一种是预防用户进行某种操作，比如禁止删除；最后一种是简单的通知，告之系统目前的状态，比如提交成功、删除成功等。
无论哪种类型，其目的就是要把文案的信息快速准确的传递给用户，所以此类文案编写的两个原则就是简洁、无歧义。
快速要求简洁，准确要求无歧义。
所谓简洁，就是用一句话能描述清楚的，绝不啰嗦两句话。比如删除的提示语：”确定删除吗？删除后将不可见“就不够简——”删除后将不可见“就有点多余。
这里有一个原则，就是长提示语一般不要超过20个字，否则大概率就违背简洁原则了，可以尝试缩减到20个字之内。
所谓无歧义就是要逻辑通顺，确保每个人看到后，理解的都一样。
这里举一个反例，就是个人所得税APP中，当你由于换工作需要修改个税申报方式时，会让选择更换扣缴义务人原因，这时候你会想选择”变更工作单位“，但细看其提示文案时，就纠结了，因为文案里有一句”原单位继续扣除“的描述，这就是一句有很大歧义的文案，让很多人搞不明白。
还有一点，就是在类似的场景中，文案内容、文案所采用的句式都要保持一致，这样可以保持产品的统一性，给用户以专业的感觉。常见的反例就是，同样是提交的场景，有的提示语是“保存成功”，有的叫“提交成功”。
最后一点，就是文案避免出现常识性的错别字，比如登录写成登陆、账号写成帐号等。
03 交互设计符预期，中间状态勿忘记
做交互设计时，当你不知道如何设计时，有一个原则屡试不爽，就是站在用户的角度，设想用户的预期是什么？
比如用户查询报表，当点击查询按钮，遇到数据量大时，用户的预期是希望可以看见加载的状态。比如”loading…“，这时候如果你设计了，就基本符合用户预期了，反之如果没有设计，就一直在那等着，用户就感觉不知道发生了什么情况，是没数据吗？体验自然不好。但如果你进一步设计了加载的进度百分比，甚者显示剩余时间，那么就算超用户预期了，用户就会夸你用户体验好。
交互过程中的中间状态往往容易忽略，比如同步数据时，状态一般分为未同步、同步中、同步完成。数据量少时还好，可以瞬间同步完成。但如果数据量大时，就可能要同步几分钟，这个时候要切记得把同步中的状态设计出来，比如用一个旋转的图标代表”数据同步中。
04 逻辑漏洞细细缕，关系变化高发区
逻辑漏洞是原型方案比较常见的问题，最常见的逻辑漏洞大致分为几种：
1、状态重叠或缺失
即状态不符合MECE原则（相互独立，完全穷尽），要么重叠，要么缺失。
2、前后矛盾
即逻辑不通，想要某个结果，但前提条件不具备。
比如群发消息时，在没有选择人数和消息条数时，就要显示消息总数。
3、细节缺失
即只描述了大致的逻辑，具体细分场景没有考虑，导致逻辑漏洞的出现。
比如群发消息，当消息超出当天最高数量限制时，需要延迟到第二天发送。这里面就有一个细节缺失的地方。假设每人每天消息数量是3000条。当老师余额还剩5条时，这时候老师要给2个学生（学生A和学生B）发消息，每人3条，共计6条消息。该如何发送呢？
如果没有仔细考虑，就会出现只发5条，剩余1条不发。但从消息的完整性考虑，一个学生只收到2条消息，显然是不对的。所以就需要补充这一个发送的细节：当发送造成消息不完整时，该学生的所有消息都不发送，也就是只给一个学生发送3条即可。另外一个学生的3条延迟到第二天发送。
4、对象关系/状态发生变化
当对象的关系或者状态发生变化的时候，往往是漏洞发生的高发区，需要我们格外注意：
状态变化引起的逻辑漏洞：
比如设计题库时，当题目的状态由开启变为禁用时，那么就需要考虑已经关联了该题的试卷应该如何处理，如果没有相应的说说明，就会出现逻辑漏洞。
对象关系引发的逻辑漏洞：
比如设计CRM系统中，当客户的所属销售由A变为B时，客户上面一些个人标签是否要清空。无论清不清空，都需要有对应的说明。
05 账号权限上下游，依赖关系记心头
做B端系统的方案，尤其是在大公司，一般都会有成熟的账号系统（比如EHR、用户中心等等）和权限系统等，那我们在设计系统方案时，像账号登录、权限设置就没必要单独设计了，可以直接调用公司现有的系统。所以一定要搞清楚这些依赖系统的内在逻辑和调用方法。
另外还有考虑到自己所设计的模块/系统和上下游系统的依赖关系：自己从上游系统要拿的数据是否能够正常提供，自己吐给下游系统的数据是否能正常兼容。
06 各个环节求闭环，备选方案保齐全
记得曾经有一句话来描述方案的闭环，就是你的产品方案就是装着硫酸的各种管道，管道必须是闭环的，不能有漏口，否则硫酸就会溢出，造成“伤害”。
所以我们在设计方案时，要养成闭环的思维，方案自检时，要考虑下每一个流程是否都通顺，异常流程是否都考虑全了，如果都失败了，是否有最后的方案来兜底。
这里就体现流程图的重要性了，务必要养成做原型方案前，先画流程图的习惯。
用流程图可以很好的避免流程不通或丢失的情况。画流程图这里不再赘述，感兴趣的可以看看我之前写的关于流程图的文章——《大话业务流程图(一)——什么是业务流程图》、《大话业务流程图（二）—如何绘制业务流程图？》
最后需要说明一点，就是我们可以有兜底方案，但切记不要为了低频的场景来设计逻辑复杂的兜底方案。相反，如果是低频场景，哪怕是用户麻烦点，兜底方案是手动处理也问题不大。
写在最后
最后说一下，虽然以上口诀目的是为了让方案尽可能的完美起来，但遗憾的是，没有方案是完美的，不要指望你的方案可以解决所有问题，只要方案能解决核心问题即可，其余的不完美都是可以暂时接受。
只有接受不完美，才是走向完美的开始！
以上就是我总结的原型自检口诀，很多是根据自己踩过的坑总结而来，权当是个1.0版本，各位也可以在留言区说说自己在原型方案中踩过的坑，我们一起将此口诀逐渐补充完善。
