1. 主页 > 行业资讯 > 设计文章 >

要不要失传已久的B端原型设计配方?

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

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

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

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

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

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

下面我们来解释一下:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.重叠或缺失状态

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

2.前后不一的

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

3.缺少细节

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

七、写在最后

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

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

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

本文由网上采集发布,不代表我们立场,如有侵权请联系我删除,转载联系作者并注明出处:http://ffjianzhan.cn/a/sjwz/502.html

联系我们

在线咨询:点击这里给我发消息

微信号:

工作日:9:30-18:30,节假日休息