失传已久的B端原型设计口诀秘籍,你要吗?

11 评论 14588 浏览 236 收藏 15 分钟

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

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

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

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

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

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

下面就展开说明一下:

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

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

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

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

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

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

失传已久的B端原型设计口诀秘籍,你要吗?

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

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

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

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

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

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

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

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

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

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

失传已久的B端原型设计口诀秘籍,你要吗?

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

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

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

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

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

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

失传已久的B端原型设计口诀秘籍,你要吗?

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

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

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

1. 状态重叠或缺失

即状态不符合MECE原则(相互独立,完全穷尽),要么重叠,要么缺失。

2. 前后矛盾

即逻辑不通,想要某个结果,但前提条件不具备。比如群发消息时,在没有选择人数和消息条数时,就要显示消息总数。

3. 细节缺失

即只描述了大致的逻辑,具体细分场景没有考虑,导致逻辑漏洞的出现。

比如群发消息,当消息超出当天最高数量限制时,需要延迟到第二天发送。这里面就有一个细节缺失的地方。假设每人每天消息数量是3000条。当老师余额还剩5条时,这时候老师要给2个学生(学生A和学生B)发消息,每人3条,共计6条消息。该如何发送呢?

如果没有仔细考虑,就会出现只发5条,剩余1条不发。但从消息的完整性考虑,一个学生只收到2条消息,显然是不对的。所以就需要补充这一个发送的细节:当发送造成消息不完整时,该学生的所有消息都不发送,也就是只给一个学生发送3条即可。另外一个学生的3条延迟到第二天发送。

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

当对象的关系或者状态发生变化的时候,往往是漏洞发生的高发区,需要我们格外注意:

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

五、账号权限上下游,依赖关系记心头

做B端系统的方案,尤其是在大公司,一般都会有成熟的账号系统(比如EHR、用户中心等等)和权限系统等,那我们在设计系统方案时,像账号登录、权限设置就没必要单独设计了,可以直接调用公司现有的系统。所以一定要搞清楚这些依赖系统的内在逻辑和调用方法。

另外还有考虑到自己所设计的模块/系统和上下游系统的依赖关系:自己从上游系统要拿的数据是否能够正常提供,自己吐给下游系统的数据是否能正常兼容。

六、各个环节求闭环,备选方案保齐全

记得曾经有一句话来描述方案的闭环,就是你的产品方案就是装着硫酸的各种管道,管道必须是闭环的,不能有漏口,否则硫酸就会溢出,造成“伤害”。

所以我们在设计方案时,要养成闭环的思维,方案自检时,要考虑下每一个流程是否都通顺,异常流程是否都考虑全了,如果都失败了,是否有最后的方案来兜底。

这里就体现流程图的重要性了,务必要养成做原型方案前,先画流程图的习惯。

用流程图可以很好的避免流程不通或丢失的情况。画流程图这里不再赘述,感兴趣的可以看看我之前写的关于流程图的文章——《大话业务流程图(一)——什么是业务流程图》、《大话业务流程图(二)—如何绘制业务流程图?

最后需要说明一点,就是我们可以有兜底方案,但切记不要为了低频的场景来设计逻辑复杂的兜底方案。相反,如果是低频场景,哪怕是用户麻烦点,兜底方案是手动处理也问题不大。

七、写在最后

最后说一下,虽然以上口诀目的是为了让方案尽可能的完美起来,但遗憾的是,没有方案是完美的,不要指望你的方案可以解决所有问题,只要方案能解决核心问题即可,其余的不完美都是可以暂时接受。

只有接受不完美,才是走向完美的开始!

以上就是我总结的原型自检口诀,很多是根据自己踩过的坑总结而来,权当是个1.0版本,各位也可以在留言区说说自己在原型方案中踩过的坑,我们一起将此口诀逐渐补充完善。

#专栏作家#

产品老吴,微信公众号:产品老吴,人人都是产品经理专栏作家。10年教育行业老兵,专注B端产品方向,擅长CRM系统 智能学习系统的规划、设计、搭建。目前负责在线智能学习系统的规划设计。

本文原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 牛逼了,我每个坑都踩了咋办。。。

    来自陕西 回复
  2. 好好学习,谢谢老师

    来自广东 回复
  3. 这个厉害了,总结的很细致

    来自北京 回复
  4. 很棒

    来自上海 回复
  5. 请问可以转载贵文章到公众号进行传播吗?会注明出处及作者

    来自广东 回复
    1. 可以的。我公众号也有发,可以开白。

      来自北京 回复
    2. 谢谢,下次发的时候找你开白哈

      来自广东 回复
  6. 刚入门B端系统设计,涨姿势了~

    来自广东 回复
  7. 优秀!!!

    回复
  8. 这个总结的真好~我也是踩了这些坑

    来自河南 回复
  9. 赞👍

    回复