胡想神话志最强气焰推荐攻略

焦点 5113℃

B端交互评审如何智胜?交互实战案例帮你学会!

B 端交互中,评审有很多需求和应用场景是何智独有的,特殊的胜实,没办法找到一模一样的战案参考照抄。作为设计师,例帮我们只能自己构思方案并输出 。交互

而做交互最大的评审难点 ,就是何智找出真正合理的方案而不是只遵照团队/领导的建议 ,换句话说就是胜实你设计出有效的结果并说服团队通过 。

一 、战案原交互方案说明

下面是例帮我们某个学员的项目案例:

B端交互评审如何智胜
?实战案例帮你学会�!

这个页面的交互筛选模块和常规筛选不同,常规筛选是评审预设好筛选的属性,等用户填入数值后提交再生成筛选结果 。何智

B端交互评审如何智胜
?<strong></strong>实战案例帮你学会!

但该案例中的筛选,是由用户完全自定义实现的,需要用户先添加筛选条目  ,并设置每个筛选条目内的规则 。

筛选条目内的规则如下:

属性类型 —— 条件 —— 属性参数

B端交互评审如何智胜	?实战案例帮你学会!

属性类型即当前页面内表格数据项包含的属性,比如在一个用户表格中 ,用户包含姓名、身高  、年龄、性别等属性 ,那么就可以选择其中一个。但不能选择和创建不存在的属性,所以属性类型的设置是一个单选操作 。

条件即对后续筛选参数的运算方式 ,包含等于、不等于 、包含、等于空四个类型 。其中等于空是比较特殊的运算符 ,直接指定了筛选参数为"空"。

属性参数则是用于运算的参数  ,比如具体年龄 、日期、时间、地址参数等等。

在这个筛选规则内  ,多个筛选条目是 "并且" 关系而不是"或"关系 ,筛选出来的结果,要满足所有这些条件 ,而不是只有其中之一  。且在筛选条目中,一个属性只能出现一次制定一个筛选条件,不能使用类似 "年龄 >18" 加 "年龄 < 18" 的组合 。

了解完产品逻辑 ,再回到原设计中 。可以直接给结论,筛选的多列排版是非常不利于查看的,且每条筛选的设置并不合理,包括属性要在这个阶段选择 ,以及后续包含增减项的按钮 。

B端交互评审如何智胜�?实战案例帮你学会!

所以下面 ,我们就要基于它来完成调整 ,并阐述如何解释交互方案的思路。

二、交互的设计和说明

这次先直接看我优化完的第一个版本 :

B端交互评审如何智胜	?实战案例帮你学会	!

在这个改动中  ,首先修改添加筛选项的步骤,在添加过程中可以直接选择要筛选的属性类型  ,一方面可以一次性完成要筛选的条目创建 ,另一方面在下方的设置中,可以减少选择项 ,让每个条目的信息更清晰 。

第二个改动 ,则是将筛选项切换成每行一条,提高筛选信息的可读性和交互性。且因为在不同的页面中 ,属性筛选可能会有很长的名字 ,所以增加左侧标题的空间。

第三个调整 ,则是将条件和参数做成一个输入框。这么做最重要的理由 ,就是有很多属性筛选是没有选择运算符的必要的。比如省份需要筛选  ,那筛选只需要考虑选出的省,而没有 "不包含某省" 的使用需求。或是选择性别的时候 ,也只有选择男或女,而不应该出现"不包含男"  、"不包含女"这种情况 。

总结起来属性中填入筛选项的情况包含:

  1. 数值类可以使用运算符
  2. 只能在既定选项中选择
  3. 直接填入自定义信息

后面两种情况一个是下拉菜单一个是输入框 ,只有第一种情况需要额外的操作步骤  ,即下拉菜单先选择条件类型 ,然后再输入相关的数值 。

B端交互评审如何智胜	?实战案例帮你学会!

在这套方案中,最大的问题就是一行只有一条筛选,是不是太浪费空间了?

这是筛选和表单中最老生常谈的问题,而我们要解决这类问题,不是光靠嘴说 ,而是要去模拟实际的场景做不同方案的对比,讲解其中的优劣 ,比如添加 6 个筛选选项 。

B端交互评审如何智胜
?实战案例帮你学会!

原案例的做法中,除了让筛选区域短一点,还解决了什么问题 ?它只创造了更多的问题:

  1. Z 字型浏览的顺序缺乏检索的效率
  2. 格子太多很难识别每个筛选的条件  ,且操作起来困难
  3. 不容易处理属性标题过长的问题
  4. 要过多考虑响应式的兼容规则和列数
  5. 开发难度比较高,落地效果会更差

而唯一一个优势 —— 省空间,包含了"万一添加了十几个选项,那表格不得顶得看不见"的场景。

"万一"就是整个交互设计过程中最大的敌人和谎言 ,因为我们经常会在设计思考和评审中讨论万一,并想去兼容这种情况  ,但成熟的产品和设计师  ,一定会去考虑这个万一的权重 。

因为很多万一的场景出现的概率非常非常低,兼容这些情况是有必要的,但重点是 —— 要不要为了兼容万一牺牲绝大多数场景的体验。

在并列筛选条件中 ,添加的条件越多 ,筛选的结果越少 。而添加一大堆筛选项的概率实际上非常低 。这就需要在整个项目所有同类页面中做排查 ,哪个页面有添加一大堆筛选的场景。

如果这种场景都很极端、或者干脆没有 ,那就不要提这种没有意义的万一来干扰交互的设计。如果出现的场景非常普遍  ,那才会考虑多列缩短高度的做法。

交互的决策就是做取舍的过程 ,而取舍以真实场景为依据 。要优先考虑的是高权重 、高频次操作的需求和场景,而不是为了低权重的需求而牺牲前者 。

而要在评审中出现反对,就需要把不同的方案都做出来进行优劣的直接对比 ,简单的话可以直接做成设计稿对比,复杂的话可以用 Axure 等软件实现比较拟真的交互进行对比。

最后,放一个我没放出来的版本,将筛选操作做在表头上的版本,你们可以自己考虑有哪些优劣 ,适用在什么样的场景:

B端交互评审如何智胜?实战案例帮你学会�!

结尾

时间不怎么多  ,没有按预期做完更丰富的交互细节和操作方式,但意思已经表达清楚了,你们看着理解  。

作者:超人的电话亭