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

3 评论 7816 浏览 81 收藏 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协议。

给作者打赏,鼓励TA抓紧创作!
2人打赏
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 优秀!!!

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

    回复
  3. 赞👍

    回复