B 端筛选设计的核心是贴合业务需求与提升效率，前端记忆、筛选复用等机制可优化操作体验，查询逻辑选择需结合数据规模与用户习惯。南森 HRM、TAPD 的实战案例与设计 SOP，为 B 端筛选功能落地提供了可直接参考的实用指南。
筛选功能的核心是服务于业务，因此每一个筛选维度和交互逻辑的设计，都必须契合真实的业务场景与用户需求。
其实这句话有点抽象，简单来说，设计前需通过灵魂发问：“用户在这个场景下，最需要通过筛选解决什么业务问题？”
举个例子：对于运营人员，他们更关注交易健康度和异常处理，因此在数据层面，我们需要挖掘“商品类型、订单状态、订单时间范围 ”等核心字段。所以在设计上，我们会将“订单状态”、“类型”等字段进行标签化外露展示，实现高频维度的一键筛选。
关于筛选效率，其实不仅仅是“减少步骤、缩短路径”，在 B 端复杂的业务场景中，我们更需要掌握以下三类“复用”机制的筛选设计。
其实就是默认保留上一次的筛选条件，能让用户进入页面后，快速查询到想要的结果。
因为用户使用筛选时，很可能需要在大量页面间跳转，因此会遇到页面刷新、重新进入等特殊情况。这种时候，默认保存上一次的筛选条件，更有利于用户快速查询；同时，在员工薪资、手机号码等隐私数据的筛选条件中，我们可以设定为不记忆，避免重要信息泄露。
当然，筛选条件也可设定一个默认保存周期，比如 24h或 36h，同时提供方便的重置入口，方便用户快速清除所有筛选选项。
这其实是前端记忆的升级版本，把记忆功能保存到后端。它可以将用户的筛选条件组合，保存为视图或者模板，来方便用户快速使用。
因为这两种筛选的配置通常较为复杂，若用户每次都需要手动调整筛选选项，操作会异常繁琐。因此，在筛选的操作区域设置保存入口，能让整体使用效率更高。
如果想要拓展更多功能，甚至可以考虑将排序字段的排列等表格相关设置，统一归纳到筛选复用的保存范围中。这会让整个复用功能更强大，用户也能自定义出更多符合需求的页面结果。就像纷享销客这样～
同样类似的做法还有明道云，用户能够自行保存筛选条件，这样高效、简洁～
筛选复用功能完成后，我们还可以考虑将整个筛选内容分享给公司内部或部门小组的其他成员使用，这就是我们所说的 “分享筛选”。
其目的很简单，就是统一管理员工的筛选情况，管理者可以配置所有可分享的筛选内容，普通员工则可直接使用。这样一来，即便业务中存在需要灵活调整的地方，管理者也能在前台应用中快速操作实现，无需在后台配置端进行繁琐的设置。这更符合高效协同办公的理念。
比如在 ONES 当中，就可以将筛选条件保存复用（也就是截图上的视图），同时可以将它设为公共视图，分享给其他人。
筛选中的三个操作 查询、实时查询、重置，对于设计师而言非常头疼。
查询是用户筛选了条件过后，需要点击按钮才会执行筛选并返回结果；实时查询则是当用户选择条件后，直接加载筛选结果；重置则是将所有的筛选条件进行归零，恢复初始的筛选状态。那这三个操作如何取舍？这边我们的判断会有三个依据：
1.数据规模
当系统表格大多数数据＜1000 条时，建议使用实时查询，因为数据量小快速实时查询不会造成系统卡顿，并减少用户操作步骤。
当数据＞10000 条时，建议使用查询按钮触发，因为数据量大，筛选需要服务器长时间加载，使用按钮手动触发能够减少系统加载次数，减轻服务器压力。
折中方案：如果系统数据不太确定，我们可以考虑将高频外露展示，低频默认筛选收起，这样体验、落地都能兼容。
2.筛选复杂度
当筛选更多为简单条件，我们则可以通过实时查询让用户快速看到结果，无需确认。
当筛选更多是复杂条件，则需要点击确认筛选，避免配置一半还需要等待加载。
3.操作习惯
用户的操作习惯也会影响我们是否提供筛选操作。
比如一线员工，像是客服、销售，日常筛选更多关注的是“待处理工单”、“个人的客户”，这些操作流程固定且条件简单，实时筛选能够减少点击查询的步骤，更容易满足他们的操作习惯。
比如管理人员，像是主管、老板，日常筛选则会分析 “多维度的客户情况”，因此操作频率低但是条件复杂，所以更希望用户检查筛选条件后，再触发。
关于筛选，我们不仅要了解筛选的常见类型，也需要去提供更多筛选的案例来帮助同学们进行实际工作的落地。
项目背景：南森HRM（人力资源管理系统）核心角色就是 HR，她的日常工作就是 大量简历筛选、招聘流程管理。她们需要反复在“人才库”页面查询数据，这也就为后续的筛选埋下伏笔。
阶段 1：南森HRM基础版本上线后，主要服务互联网行业的招聘工作，因此系统较为单一，对于人才库页面的使用需求相对简单。不过在上线一段时间过后还是会收到以下反馈：
1.筛选功能单一，很多筛选项都不能找到，只能换其他关键词筛选
2.筛选使用起来很别扭，很多筛选项铺满了以后很难寻找
3.筛选不够高效，感觉就是不好用
为此我们就需要明确问题出现的原因，才能方便设计，深度研究过后发现，其主要原因是：
1.用户希望能展示更多筛选项，特别是在关键页面处，能够保证我高频使用
2.筛选项的储物功能不够强大，一旦选项过多，就会很难应对
3.在筛选顺序上没有进行高低频设计，很多高频筛选都放置在后侧，因此很难应对
为了解决这一问题，我们设计了新版本的筛选，依旧保留之前的基础筛选，不过在筛选的细节上进行打磨，包含排序、样式…都进行重新设计，得到新版本页面
上线过后发现对于效率问题依旧没有解决，深度分析通过数据埋点发现端倪：
1.对于所有HR 来说，日常工作最为重要是关注是人才状态，而且数据明显高于其他筛选，需要重点设计
2.其次用户想要知道不同人才状态的数量，目前的解决办法是在下拉菜单当中展示数量，整体不够优雅
于是我们考虑将状态筛选的优先级提高，最终使用外露筛选，展示对应筛选指标图，方便用户查看数量的同时进行筛选操作。
随后我们上线一段时间过后，新的问题来了。
阶段 2：南森 HRM 系统之前都是服务互联网行业，因此字段相对固定。但随着业务发展，需要将系统拓展到其他行业，所以字段上就会需要用户自定义，对应在筛选上就要进行调整。
这里我们简单讲解一下，这个要带来的变化。
首先它是一个行业属性型产品，这个在我们之前的课程当中有提到，感兴趣的同学可以跳转查看。
也就意味着 HRM 系统要服务不同的行业，我们可以打开北森官网就会发现，这样就意味着我们的业务会发生改变。筛选上就会从最初的基础筛选变为更为复杂的高级筛选或者自定义筛选，那其他到底从何下手？
因为这一功能比较迷茫，我们就延续基础筛选的样式，只是增加 “添加筛选、删除筛选”的入口，这样就能满足用户的基础自定义需求。
这里原本也考虑过浮窗、表头等方式，但浮窗交互过于繁琐，因此只能作罢。
最后用户则是反馈这类筛选过于繁琐，没有根据他们实际工作场景进行优化。
我们就会思考，是哪里出了问题～
深度了解用户需求后发现，因为 HR 日常工作当中，其实有明确的划分：
1.日常工作主要以固定的招聘任务，比如小李 HR，主要负责产品部门的招聘工作，因此在使用时就会有自己的筛选习惯，所以希望能够将筛选逻辑进行保存
2.在业务逻辑上，很多企业会将校招、社招拆分，是来自不同的招聘渠道，所以需要将逻辑重新梳理
基于这一背景，我们重新梳理筛选，在结构上进行重新优化。最终形态就与飞书招聘类似～
看完了一个案例过后，我们再来赏析一个产品：
TAPD是腾讯的研发管理系统，算是非常重要的业务之一。
由于它出现的时间很早，导致我们可以追述一下它之前与现在的设计差异。
在早些版本，TAPD主要使用浮窗方式，用户点击后可以自行选择筛选项配置；
（这一块确实没有资料，只有给大家简单会绘制一下之前的样子）
现在则是将筛选的逻辑重构，分为基础与高级，基础是日常用户使用，展示在表头处，使用基础筛选就能高效使用。高级部分则是选择过后用户进行自定义筛选规则，这样简单高效可以完成复杂的筛选任务
同时提供保存入口，方便用户能够保存自己常用筛选组合进行快速访问。
在设计筛选时，我们要关注的内容会有以下 3 点：
首先我们会关注筛选的业务需求，运维系统的底层逻辑，才会决定设计方案究竟要如何呈现。究竟是 基础、高级、自定义，我们必须再需求开始前就需要了解。
其次再看筛选的数量与空间，因为需要展示的数量和空间，会直接影响我们选择哪类型的筛选，使用哪种解决方案会更加合理。
最后则是看操作频率，用户的使用频率会直接影响我们的整个设计方案。
在基础筛选当中，使用频率不高，我们就需要考虑尽量在前置排序上得到优化。
在高级筛选、自定义筛选当中，操作频率过高，我们就需要考虑用视图、保存筛选等诸多方案呈现筛选结果。
所以筛选是一个层层相扣、环环递进的过程。因此，我们在设计的时候，不能只看一个维度，需要多维度来去判断自己的系统究竟什么样的筛选会更为合适。
本文由人人都是产品经理作者【CE青年Youthce】，微信公众号：【CE青年Youthce】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。