引:加、删、查、改、算、通、查异常情况彻底，文案简洁不含糊，类似场景要对齐。交互设计师期待，中间状态不要忘记。逻辑漏洞没问题，关系变化频繁。账户权限是上下游，记住依赖关系。所有环节闭环，所有方案保证完整，公式默记，帮你顺利复习！

亲爱的产品伙伴们，你们有没有因为方案评审时对方案考虑不周而被喷过？如果你想挑一个产品经理的尴尬时刻，在评审会上被技术和运营伙伴喷，那你一定要算一个。

原因是产品方案考虑不周全，逻辑不流畅，漏洞很多。新产品合作伙伴尤其如此。当我制定计划时，我觉得我已经考虑得很透彻了。到了复习会，发现很多地方真的没有考虑到。

刚开始职业生涯的时候，也遇到了同样的问题。做了很久以后才慢慢发现，容易忽略的往往集中在某些类型的问题上。于是我结合这几年的经验，编了一个方案的自检公式，方便记忆。

每次完成计划，都可以按照这个公式通过自检快速检查。

这个公式有14句98个字，分别是:加、删、查、改、算、通，把异常情况查透，文案简洁不含糊，类似场景要对齐。交互设计师期待，中间状态不要忘记。逻辑漏洞没问题，关系变化频繁。账户权限是上下游，记住依赖关系。所有环节闭环，所有方案保证完整，公式默记，帮你顺利复习！

下面我们来解释一下:

一、增删查改显式计算传输，异常情况测试良好

做过技术工作的人都知道，系统最基本的四个操作是添加、删除、检查和修改数据，加上如何显示(显示)数据、计算规则(计算)数据和传输(传输)数据，基本涵盖了对数据的所有操作。

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

可以看出，对于数据上的这七个操作，每个操作都有一些需要注意的细节。我们可以结合5W2H进行分步检查，即谁，什么时候，什么地方，为什么，什么，怎么，多少。

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

5W2H不一定涉及到每一个维度，但是可以帮助我们更全面的思考。我将7个操作和5W2H组织到一个相应的二维表中，如下所示:

以上都是根据理想情况考虑的，但实际执行中总会有很多奇怪的事情，所以要尽可能全面的考虑异常情况。所谓异常，是指一旦程序没有按照我们的预期执行，我们应该如何处理。

最基本的有，比如重名，操作或同步数据时网络中断，查找数据时没有对应数据等。

第二，文案简洁不含糊，相似场景要对齐

我们在制定产品计划时，有时需要写提示文字，目的是为了及时告知用户当前的系统状态。

提示分为三种:一种是引导用户进行一定的操作，比如填写手机号码；一种是阻止用户做某些操作，比如禁止删除；最后一个是通知系统当前状态的简单通知，如成功提交和删除。

不管是哪一种类型，其目的都是为了快速准确地把文案的信息传递给用户，所以写这种文案的两个原则就是简洁和不含糊。

快速性要求简洁，准确性要求明确。

所谓简洁，就是一句话就能描述清楚，绝不啰嗦。比如删除提示:“确定要删除吗？删除后不可见”不够简单——“删除后不可见”有点多余。这里有一个原则，就是长提示不要超过20个字，否则大概率会违反简洁原则，可以尽量减少到20个字。

所谓不含糊，就是要逻辑通顺，保证大家看了之后都明白一样。

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

还有一点就是在类似的场景中，文案的内容和句式要一致，这样才能保持产品的统一性，给用户一种专业的感觉。一个常见的反例是，在相同的提交场景中，有的提示被“保存成功”，有的则被称为“提交成功”。

最后，文案要避免常识性的错别字，比如把登录写成登录，把账号写成账号。

第三，交互设计师期望中间状态不要被遗忘

当你做交互设计的时候，当你不知道怎么设计的时候，有一个原理是一直在尝试和测试的，就是站在用户的角度，想象用户期望什么。

例如，当用户查询报表时，当他单击查询按钮并遇到大量数据时，用户希望看到加载状态。例如“装载& # 8230；”这时候如果设计出来，基本符合用户的预期。反之，如果没有设计，你一直在那里等，用户觉得不知道发生了什么。没有数据吗？体验自然不好。

但是如果你进一步设计加载进度百分比，甚至显示剩余时间，即使超出了用户的预期，用户也会对你良好的用户体验大加赞赏。

交互过程中的中间状态往往被忽略。例如，在同步数据时，状态通常分为非同步、同步和同步。数据量少的时候还行，可以瞬间同步完成。但是，如果数据量很大，同步可能需要几分钟时间。这时候记得设计同步状态，比如用一个旋转图标表示“数据同步”。

第四，逻辑漏洞没问题，关系变化频繁

逻辑漏洞是原型方案中常见的问题，最常见的逻辑漏洞大致分为几种类型:

1.重叠或缺失状态

也就是说，这些国家不符合MECE原则(它们彼此独立，而且完全用尽)，要么重叠，要么缺失。

2.前后不一的

即逻辑不合逻辑，想要一个结果，但前提条件不满足。例如，分组发送消息时，当没有选择人数和消息数时，应该显示消息总数。

3.缺少细节

即只描述一般逻辑，不考虑具体细分场景，导致出现逻辑漏洞。

例如，分组发送消息需要延迟到第二天，此时消息超过了当天的最大数量限制。这里缺少一个细节。假设每人每天的消息数是3000条。当老师余额还剩五条消息时，老师会给两个学生(学生A和学生B)发消息，每个学生发三条消息，共计六条消息。怎么发？

不仔细想想，你会发现只发5篇，剩下的一篇就不发了。但是考虑到消息的完整性，一个学生只收到两条消息显然是错误的。因此，有必要补充一下这次发送的细节:当发送导致消息不完整时，不会发送所有学生的消息，即只向一个学生发送三条消息。另一个学生的3项推迟到第二天。

4.对象关系/状态发生变化

当对象的关系或状态发生变化时，往往是脆弱性的高发区，这就要求我们特别注意:

状态变化引起的逻辑漏洞：比如设计题库时，当题目的状态由开启变为禁用时，那么就需要考虑已经关联了该题的试卷应该如何处理，如果没有相应的说说明，就会出现逻辑漏洞。对象关系引发的逻辑漏洞：比如设计CRM系统中，当客户的所属销售由A变为B时，客户上面一些个人标签是否要清空。无论清不清空，都需要有对应的说明。

第五，账户权限上下游，记住依赖关系

b端系统解决方案，尤其是大公司，一般都有成熟的账户系统(如EHR、用户中心等。)和权限系统，所以在设计系统解决方案时，不需要单独设计，比如账号登录和权限设置，可以直接调用公司现有的系统。因此，我们必须了解这些依赖系统的内部逻辑和调用方法。

此外，还考虑了自己设计的模块/系统与上下游系统的依赖关系:是否能正常提供你想要的来自上游系统的数据，以及你吐槽给下游系统的数据是否能正常兼容。

第六，所有环节都是闭环的，替代方案是完整的

记得有一句话形容方案的闭环，就是你的产品方案是各种含硫酸的管道，管道必须是闭环无泄漏，否则硫酸会溢出造成“危害”。

所以设计方案的时候要培养闭环思维。在对方案进行自检时，要考虑每个流程是否顺畅，是否考虑了所有的异常流程，是否有最终的方案覆盖。

这就说明了流程图的重要性，要养成先画流程图再做原型方案的习惯。

使用流程图可以很好地避免流程被阻塞或丢失的情况。这里就不赘述了。有兴趣可以看看我之前关于流程图的文章——《大华业务流程图(一)——什么是业务流程图》和《大华业务流程图(二)——如何绘制业务流程图？》

最后需要说明的是，我们可以有一个自下而上的方案，但是切记不要为低频场景设计一个逻辑复杂的自下而上的方案。相反，如果是低频场景，即使对用户来说是个麻烦点，手工处理自下而上的方案也不是什么大问题。

七、写在最后

最后，虽然上面公式的目的是让方案尽可能完美，但很遗憾，没有一个方案是完美的。不要指望你的方案能解决所有问题，只要方案能解决核心问题，其他的不完善暂时可以接受。

只有接受不完美，才是完美的开始！

以上是我总结的原型自检公式，很多都是基于我踩的坑。应该是1.0版。你也可以在消息区说说你在原型方案中踩过的坑。我们会一起逐步补充完善这个配方。