后台产品设计系列:搜索的细节(八)

7 评论 16248 浏览 172 收藏 10 分钟

一个看似简单的搜索功能,却包含许多“不为人知”的细节。本篇文章详细地介绍了后台产品搜索的相关细节。

魔鬼存在于细节。后台产品中,搜索是非常常用的功能,几乎每个数据列表上都会有一个搜索栏,但一个看似简单的搜索功能,却包含众多你想到或想不到的细节。

此篇文章,将详细介绍后台产品搜索的那些不为人知的那些事。

一、输入框搜索

针对数据格式非标准的字段,都会通过输入框进行搜索,如名称、概述、正文等。

对于输入框搜索,需要考虑以下几个要点:

1. 聚合搜索or分字段搜索

聚合搜索

聚合搜索是指一个输入框,可以同时搜索多个字段内容。例如下图中,输入关键词“人人都是产品经理”,可以对名称、描述等多个字段进行匹配。

优点

  1. 很方便,一次性能搜索大量数据;
  2. 用户不用记忆我要搜索的关键词到底在哪个字段

缺点

  1. 同时检索字段数据多,当数据量很大时,会导致搜索时间过长,影响体验;
  2. 搜索结果不够精确,如果只提供聚合搜索,对于用户清楚的知道搜索关键词在哪个字段的场景不友好

分字段搜索

由于我们的系统随着时间推移数据会越来越多,同时使用者多为对数据很熟悉的人,所以聚合搜索看似很方便,实则在系统产品中应用并不多。

也就是我们下图看到的,每个字段单独给一个输入框,将搜索精确到字段。

综合形式

有时候为了覆盖更全的场景,也可以使用综合的方式,输入关键词的同时给出“全部”和其他可能需要搜索字段选项,由用户自己选择。

这种方式适用于用户对数据熟悉程度有深有浅的产品,内部系统适用较少。

2. 模糊搜索or精确匹配

模糊搜索

模糊搜索是只要根据几个关键词,就会把含这个关键词的数据都显示出来,即使输入不完全,也能完成搜索,我们做系统搜索时,基本都是模糊搜索,这种方式体验更好。

精确匹配

精确匹配需要用户把搜索数据填写完整、准确,给用户带来较高的记忆成本,主要在两种特殊场景下会使用:

  • 对接的第三方系统,第三方系统无法提供模糊搜索接口;
  • 搜索数据有保密性要求。这种场景下,不能让用户随便输入一个关键词就进行匹配,会存在其他信息泄露的风险,例如通过身份证号进行搜索时,用户必须输入完整身份证号信息才会进行匹配;

3. 实时搜索or手动触发

实时搜索

实时搜索是每输入一个字符就根据已输入内容进行搜索。这种方式很及时,能让用户及时看到结果,搜索体验会很好,但这种方式意味着实时请求搜索接口,对接口造成一定压力,当使用人数较多时,容易出现系统报错,所以即使这种方式体验会好,我们也很少采用。

手动触发

手动触发则需要用户在输入完成后点击“搜索”按钮进行操作,有时候输入框页面上距离“搜索”按钮较远,体验会很差,所以一定要加入“回车键”搜索的功能,保留用户使用浏览器的习惯。

4. 历史记录加or不加

搜索的历史记录主要是方便我们间隔一段时间再次搜索同一条数据。

在很多To C的产品中,会经常使用历史记录功能,例如很多电商产品。但我们做后台搜索时,很少会增加搜索的历史记录,这是因为我们每次搜索出的结果是明确的,短间隔时间无需再次进行搜索,对于长时间间隔场景,我们一般会通过数据权限控制让搜索更方便,所以,后台产品的搜索一般不需要历史记录。

二、单选/复选搜索

单选/复选搜索在有的产品中也叫筛选,功能都一样。主要用于搜索数据标准化的字段。

1. 搜索样式

单选搜索

根据选项数量,我们选择下拉框中是否需要增加“搜索选项”功能,一般选项超过十个就要考虑增加“搜索选项”了,避免用户查找困难。

复选搜索

复选搜索也比较常见,当我们需要同时查看多种选项数据时,就要使用复选搜索

2. 独立搜索or联动搜索

所谓独立搜索,就是每个筛选项是独立的,不会因为已选择的搜索条件而改变,而联动搜索,则会因已有搜索条件,而改变现有搜索范围。

例如省市区的联动搜索,选择省份后,城市的选择范围就在这个省份内,而如果先选择了城市,那么省份就会默认选择这个城市所在省份,无法选择其他。

当多个搜索条件存在关联性时,我们就应采用联动搜索,作为产品经理,需要清楚的定义搜索条件间的相互影响、层级关系、数据对应关系。

3. 搜索所有or仅列表数据

有些筛选字段,我们有全部的数据,但列表中只有这个字段部分数据信息。例如用户通过测试管理系统提bug,我们在筛选哪些人提了bug时,到底是对公司所有人都能选择筛选还是只筛选提过bug的人呢?

这里一个重要的判断原则就是未提过bug的人是否以后有提bug的可能,如果以后也有可能,那么应搜索所有人。

三、整体

1. 前端搜索or后端搜索

对于没有开发经验的产品经理,是不会思考让后端搜还是前端自己搜这个问题的。

所谓前端搜索,是后端把所有数据通过接口一次性都返回给前端,每次搜索时前端自己根据已返回数据进行搜索,这种方式主要应用在数据变动频率低的场景中,而对于变动频率高的,都会采用后端搜索,即每次有搜索请求,都会通过接口让后端在数据库中匹配,以达到及时准确的目的。

2. 能否自定义搜索条件

当系统数据量很大,字段很多时,我们经常需要对大多数字段都要筛选搜索,但我们不可能把所有字段都作为筛选项放在搜索栏中,不仅会占据太多位置,也会影响可读性和美观。

另外,不同角色对搜索字段需求是不一样的,使用频次也不一样,所以这个时候我们需要针对筛选条件提供自定义功能,让用户根据自己的使用习惯,选择需要哪些筛选条件和顺序。

 

作者:周翔,起点学院深圳1609期产品经理实战训练营学员

本文由 @周翔 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 我的新书《不枯燥的B端产品实战课》已上线,更多干货尽在书里,京东地址:https://item.jd.com/12786741.html

    来自广东 回复
  2. 请教一个问题,B端软件历史数据量达到千万级,如何满足历史数据搜索场景。现在的思路是提供2种查询功能,分别去查业务数据库(最近3个月提交单据的实时数据)+数仓(凌晨定时更新数据,没有当日新增数据,当日更新数据不准),很惆怅。

    来自浙江 回复
  3. 看完了八篇后台设计,感觉很受益,作者可以针对后台设计中的结构设计这个模块再做一篇吗~~

    来自北京 回复
    1. 正在写本B端的书,书中会介绍这部分

      来自广东 回复
  4. “对于长时间间隔场景,我们一般会通过数据权限控制让搜索更方便”,关于这一点不是很理解,可以请作者详细说下吗~~

    来自上海 回复
    1. 同问+1

      来自广东 回复
  5. 学习了,都是干货额全部学习了

    来自北京 回复