交互设计``筛选功能
最近在做一个供内部使用的语料分析工具，主要针对电商交易流程中的客服聊天记录和交易评价。 踩了不少坑，记录一些心得。
ToB电商客服聊天产品
开启一个新产品，首先当然是定位你的产品，形成产品的感性认知。讲解ToC与ToB产品差别、不同行业ToB产品差别的文章汗牛充栋。这里只再强调一遍：务必深刻理解你的产品服务的业务的整个逻辑，不仅熟记躯干，还要亲身体验到每一个枝节。（有无数人强调，也有无数人犯错，这里面的教训可以再写一篇文章了。）
对于电商产品的筛选功能来说，ToC，是决定用户体验的核心功能之一,筛选漏斗做的越好，用户触达目标商品的可能性就越大；ToB，则是最不能犯错的模块，数据的精准筛选是一切分析的前提。筛选功能看似简单，却也有好些坑要填。
筛选的需求
要做好筛选，第一部当然是确定好筛选的需求。
筛选需求一定要详细了解到枝节
筛选需求的搜集，不是了解清楚有哪些筛选项就完了，结合数据库数据，对每一个筛选项预期数量级、单项字节长度范围、是否可以标签化、是否需要多选，都应当清楚。这里前期的业务逻辑调研就发挥了巨大的作用。最后综合全部需求特征，构筑你的目标场景。
筛选模块的功能设计
有了筛选需求，就开始为筛选模块设计功能。
常见的筛选功能：筛选-复选与全选、全局搜索与栏目搜索、筛选记录与快捷清除
- 复选与全选功能取决于业务使用需求。
- 全局搜索一般用于单条搜索，在业务路径清晰的ToB产品中不多见，栏目搜索的需要取决于当前筛选栏内的条目数量，一般来说条目数量>20当前筛选栏就得有搜索了。
- 筛选记录与快捷清除功能主要看筛选行为的频次，如果在一次完整的分析流程中需要多次筛选，那么筛选记录与快捷清除是一个收益很大的功能，否则这个功能就没有什么必要。
由于我的产品的筛选功能是一个低频功能，故没有为产品规划筛选记录与快捷清除模块；而对于聊天记录的集合分析也用不上全局搜索，所以我重点规划了复选与栏目搜索功能。
根据需求建立场景设计功能
筛选模块的交互样式设计
整体展现：平铺还是弹出
要对筛选模块进行交互样式设计，除了掌握条数字段等基本信息，我们还需要掌握用户对筛选功能的使用频次，C端产品需要大量的用户调研确定用户层次，而B端还是对业务现状的理解。
淘宝网筛选
平铺是指将筛选项完全罗列在当前页面内，我们熟知的淘宝网就是采用这种模式，对于淘宝网来说，筛选是个常用功能。
这样展现的好处是筛选更为直观，操作便捷，筛选效率更高。可以看到这种展现样式有一定的限制，那就是展现条目本身是标签或者可以标签化，要么条目的最大字节长度在较低的水平，总体数量可要控制在一个合理的区间，如果筛选条目数量多到一屏放不下，则需要考虑弹出式筛选，甚至是将将筛选独立成页。
百度高级筛选
弹出式的代表是下拉列表，百度的高级筛选正是这种样式，对于百度搜索，搜索条件筛选依附于全局搜索，是专家用户才会使用的功能，并且一次搜索一般只需一次筛选，所以设计采用下拉列表，并隐藏在高级筛选中。
当筛选条目数量较多时，一个额外的空间更为友好。而如果筛选功能的使用频次较低，将它隐藏在下一个层级，为关键信息预留更多位置也是很合理的。
栏目搜索的样式
由于筛选条目数>20，故我们为产品筛选添加搜索。
栏目搜索既可以放置在下拉列表顶端，也可以与筛选框整合。
搜索位于下拉列表顶端
搜索位于筛选框内
下拉列表顶端使搜索功能更加明显，但是要多占一行位置；与筛选框整合的话，在筛选框内闪动光标也可以提示搜索功能的存在（以目前的用户教育水平，光标闪动交互提示完全足够）。我个人倾向于使用第二种，无论哪种，注意保持整体交互风格的一致性便好。
如此长的商品名——古老的复选框
在实际设计商品筛选时，超长的商品名配上复选需求让商品筛选十分麻烦。淘宝宝贝名长达40~50字，而且由于重要信息一般在整个名字的中部，所以简单省略是不可取。可如果检点做成下拉筛选框，这里就有一个交互体验问题，单条名称如此之长，商品筛选又通常是个集合，以至于用户选到后面完全忘记自己选择了什么。
一番思考后，我搬出了常用于上个时代的双筛选栏，配合搜索使用。
双筛选栏
这个双筛选栏常见于一些大型分析软件（SPSS、ArcGIS等）中，它很好地解决了忘记自己选择了什么、是否选择完全的尴尬。
商品筛选——隐藏的商品编号
需求中提到，需要用商品编号（ID）定位商品，但是放置一串串相似的数字在筛选框中，这个用户体验可太差了（长数字的可读性太低）。
你猜用户会不会疯掉？
为了解决这个问题，我与前端小伙伴商量了一下。最后的解决方案是商品ID在筛选框中不显示，但可以通过搜索匹配出来。
数字匹配名称
总结
ToB产品的筛选相对于ToC来说通用性要弱很多，比起用户体验从有到优的优化，很多时候是在解决从无到有的过程。情况越是复杂多面，九月要注重前期的调研和信息搜集，尽可能考虑好每一个问题。
网友评论