1. 首页 >> 休闲

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

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端交互评审如何智胜
?实战案例帮你学会!

结尾

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

作者:超人的电话亭



版权声明:新流派 - 专业行业资讯与产品服务平台 - x6p.cn ,转载请注明出处:https://www.x6p.cn/news/66d47099463.html

 
QQ在线咨询
售前咨询热线
020-123456789
微信号
020-123456789