失传已久的B端原型设计口诀秘籍，你要吗？-轻识

字数:3660 | 估计阅读:10分钟

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

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

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

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

此口诀共计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版本，各位也可以在留言区说说自己在原型方案中踩过的坑，我们一起将此口诀逐渐补充完善。

最后，如果感觉此口诀对各位有所帮助，感谢点赞、在看和转发！

-end-