最近在做一个供内部使用的语料分析工具，主要针对电商交易流程中的客服聊天记录和交易评价。 踩了不少坑，记录一些心得，分享给大家。

ToB电商客服聊天产品

开启一个新产品，首先当然是定位你的产品，形成产品的感性认知。讲解ToC与ToB产品差别、不同行业ToB产品差别的文章汗牛充栋。

这里只再强调一遍：务必深刻理解你的产品服务的业务的整个逻辑，不仅熟记躯干，还要亲身体验到每一个枝节。（有无数人强调，也有无数人犯错，这里面的教训可以再写一篇文章了。）

对于电商产品的筛选功能来说，ToC，是决定用户体验的核心功能之一，筛选漏斗做的越好，用户触达目标商品的可能性就越大；ToB，则是最不能犯错的模块，数据的精准筛选是一切分析的前提。筛选功能看似简单，却也有好些坑要填。

筛选的需求

要做好筛选，第一部当然是确定好筛选的需求。

筛选需求一定要详细了解到枝节

筛选需求的搜集，不是了解清楚有哪些筛选项就完了，结合数据库数据，对每一个筛选项预期数量级、单项字节长度范围、是否可以标签化、是否需要多选，都应当清楚。这里前期的业务逻辑调研就发挥了巨大的作用。

最后综合全部需求特征，构筑你的目标场景。

筛选模块的功能设计

有了筛选需求，就开始为筛选模块设计功能。

常见的筛选功能：筛选-复选与全选、全局搜索与栏目搜索、筛选记录与快捷清除。

• 复选与全选功能取决于业务使用需求。
• 全局搜索一般用于单条搜索，在业务路径清晰的ToB产品中不多见，栏目搜索的需要取决于当前筛选栏内的条目数量，一般来说条目数量>20当前筛选栏就得有搜索了。
• 筛选记录与快捷清除功能主要看筛选行为的频次，如果在一次完整的分析流程中需要多次筛选，那么筛选记录与快捷清除是一个收益很大的功能，否则这个功能就没有什么必要。

由于我的产品的筛选功能是一个低频功能，故没有为产品规划筛选记录与快捷清除模块，而对于聊天记录的集合分析也用不上全局搜索，所以我重点规划了复选与栏目搜索功能。

根据需求建立场景设计功能

筛选模块的交互样式设计

整体展现：平铺还是弹出

要对筛选模块进行交互样式设计，除了掌握条数字段等基本信息，我们还需要掌握用户对筛选功能的使用频次，C端产品需要大量的用户调研确定用户层次，而B端还是对业务现状的理解。

淘宝网筛选

平铺是指将筛选项完全罗列在当前页面内，我们熟知的淘宝网就是采用这种模式，对于淘宝网来说，筛选是个常用功能。

这样展现的好处是筛选更为直观，操作便捷，筛选效率更高。可以看到这种展现样式有一定的限制，那就是展现条目本身是标签或者可以标签化，要么条目的最大字节长度在较低的水平，总体数量可要控制在一个合理的区间，如果筛选条目数量多到一屏放不下，则需要考虑弹出式筛选，甚至是将将筛选独立成页。

百度高级筛选

弹出式的代表是下拉列表，百度的高级筛选正是这种样式，对于百度搜索，搜索条件筛选依附于全局搜索，是专家用户才会使用的功能，并且一次搜索一般只需一次筛选，所以设计采用下拉列表，并隐藏在高级筛选中。

当筛选条目数量较多时，一个额外的空间更为友好。而如果筛选功能的使用频次较低，将它隐藏在下一个层级，为关键信息预留更多位置也是很合理的。

栏目搜索的样式

由于筛选条目数>20，故我们为产品筛选添加搜索。

栏目搜索既可以放置在下拉列表顶端，也可以与筛选框整合。

搜索位于下拉列表顶端

搜索位于筛选框内

下拉列表顶端使搜索功能更加明显，但是要多占一行位置；与筛选框整合的话，在筛选框内闪动光标也可以提示搜索功能的存在（以目前的用户教育水平，光标闪动交互提示完全足够）。

我个人倾向于使用第二种，无论哪种，注意保持整体交互风格的一致性便好。

如此长的商品名——古老的复选框

在实际设计商品筛选时，超长的商品名配上复选需求让商品筛选十分麻烦。淘宝宝贝名长达40~50字，而且由于重要信息一般在整个名字的中部，所以简单省略是不可取。

可如果检点做成下拉筛选框，这里就有一个交互体验问题，单条名称如此之长，商品筛选又通常是个集合，以至于用户选到后面完全忘记自己选择了什么。

一番思考后，我搬出了常用于上个时代的双筛选栏，配合搜索使用。

双筛选栏

这个双筛选栏常见于一些大型分析软件（SPSS、ArcGIS等）中，它很好地解决了忘记自己选择了什么、是否选择完全的尴尬。

商品筛选——隐藏的商品编号

需求中提到，需要用商品编号（ID）定位商品，但是放置一串串相似的数字在筛选框中，这个用户体验可太差了（长数字的可读性太低）。

你猜用户会不会疯掉？

为了解决这个问题，我与前端小伙伴商量了一下。最后的解决方案是商品ID在筛选框中不显示，但可以通过搜索匹配出来。

数字匹配名称

总结

ToB产品的筛选相对于ToC来说通用性要弱很多，比起用户体验从有到优的优化，很多时候是在解决从无到有的过程。

情况越是复杂多面，就要注重前期的调研和信息搜集，尽可能考虑好每一个问题。

作者：汪知浩，TP公司成长期产品经理、交互设计师。热衷微交互，探索魔鬼细节。

本文由@汪知浩 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议