编辑导语：在很多产品中，搜索都是其中比较基础且很重要的一个功能，在很多时候我们都需要进行搜索找到需要的东西，搜索的设计、逻辑、交互等问题也是需要特别注意的；本文作者分享了关于搜索功能的设计理解，我们一起来了解一下。

搜索功能是许多产品的核心，例如电商搜索、内容搜索等等；面对如何进行搜索功能设计，确实是个看似简单实则深奥的问题。

不管不顾，随后画一个条形框、正方体，他们就是搜索框和搜索图标就能代表一个搜索模块；若要仔细研磨，各种用户交互问题，各类逻辑，那他们也是一个搜索系统；这一切都取决于你，产品设计师如何设计。

设计一个搜索功能我们需要从用户体验和功能实现两方面出发：

• 用户体验包含了样式UI设计、交互设计；囊括起来说就是用户搜索前、搜索中以及搜索后用户对我们的功能的感知；
• 而功能实现则是聚焦用户对问题的输入，和我们结果的输出（结果匹配度）。

由此我将分成搜索的设计和搜索的逻辑两部分进行说明。

一、搜索的设计

先从可感知的样式来说。我们按照用户路径地图来理解用户使用功能时的具体步骤：

用户使用产品 – 有疑问需要搜索解决 – 看见搜索功能 – 点击搜索功能（展开输入框） – 输入问题 – 点击确认等到结果反馈 – 翻阅搜索结果 – 选择结果进行查阅。

按照上述路径，我们可以将用户使用搜索功能的场景分为三部分：搜索前、搜索中、搜素后。同时根据应用场景的不同，还需区分移动端和PC端。

1. 搜索前

首先，我需要申明我对于搜索核心的定义，那就是搜索功能核心在于解决用户的疑问，给予用户满意的答案；因此我们在设计的时候，需要带入场景假想我们就是用户，我们在迫切需要解决问题的时候，我们会是什么样的心里活，烦躁？渴望？又或是兴奋？建立了同理心后才是功能的设计。

所以在搜索功能设计的时候，对面用户迫切的心情，我们合理设计搜索功能。在用户使用产品产生疑问的时候，我们要根据当前场景进行选择放大、缩小搜索对于用户的感官；在越容易产生疑问的地方选择使用输入框搜索作为设计方案，而在不容产生问题的地方还是可以选择搜索图标作为解决方案。

这两个解决方案是十分常见的，但我们需要注意，除开样式的差异在选择使用输入框作为搜索样式的时候，大多人都偏爱在输入框上做文字引导，这种文字引导有引导使用文案和推荐搜素文案两种。

这样做不是一定需要的，因为我确实没准确的数据告诉你，做了和没做在数据层次带来的效果是什么。所以这是需要你自己自行选择的。

2. 搜索中

用户点击搜索功能输入问题这段时间，我们看作搜索中，在这里有两种设计方式：分别是当前页面直接进行搜索和进入搜索独立页面。

其中，当前页面直接进行搜索，在pc端较为常见，因为pc页面有大面积区域可使用，可以尽情展示内容所以常见。

另外一种采用搜索独立页面在移动手机端常见，因受限于手机屏幕大小，在不跳转页面直接搜索的情况下我们可展示的内容过于受限；而采用了新页面承载搜索，那就可以提供更多的功能和内容。

在这里我们可以通过后台管理功能，尽情的增加热门搜索的内容。同时在用户输入内容后，我们对输入内容进行联想展示，方便用户选择他想搜索的实际内容，提高搜索的易用性和便捷性。

但是产品设计师们需要注意的是，联想展示内容不易过多，控制在7个词条左右就行，过多词条会干扰用户阅读；展示内容需要有独立一套逻辑支撑，需要明确告知研发，为什么显示这些内容？这些内容排序依据是什么等。（这里后面部分会介绍说明）

同理，从提高搜索的易用性和便捷性这个目的出发，我们可以收录用户近期历史搜索，以便用户再次搜索相同问题；至于历史记录每次展示几个，可参考7+-2法则控制数量。（一般人的短时记忆容量约为7个加减2个，即5–9之间，可以理解为7加减2个组块。）

3. 搜索后

搜索结果的展示在移动端上一般是双排和单排展示。双排能够展示更多的搜索结果。单排能对搜索结果展示更多的信息。

到这里基本对于搜索功能的原型就没有问题，下面开始说说搜索功能的逻辑部分。

二、搜索的逻辑

先说结论：看似简单的搜索其实并不只是由简单的sql（数据操作语言）进行全数据库搜索，里面还涉及对用户搜索问题的、分词、纠错、预测、召回以及排序排序。

1. 分词

分词很好理解，就是当用户输入问题后，对输入的文字进行拆分，就叫分词。分词核心在于分词法以及特性字词典库。

同时分词也叫NLP（自然语言处理分析）算是AI人工智能的一个分支，毕竟你需要让人工智能理解你说的是什么，学的是什么，不然就成人工智障了。那么搜索是按照什么方式进行分词的了？其实分词的方式很像小时候查字典。

1）逐词匹配

我们理解为一个人给你一句话，这时你需要将他们分成两两相对或三三相对的词条，但是你并不知道如何那几个相邻的字能够组成字条。那么索性你直接拿着这句话去翻新欢词典，从头到尾翻一次，发现没有符合的时候，就删除最后一个字，在去翻词典。以至于将词典中的所有词按由长到短的顺序在文章中逐字搜索，直至文章结束。

这种方式你可以想象下，如果是人是不是很崩溃。就算是电脑在进行，因为需要重复的查询，也会造成效率低下，等半天才分词成功。

2）正向最大匹配法

最大正向匹配会按照我们的阅读习惯，从左到右进行匹配，而其中的最大的含义就是当出现多个匹配词条时，以字数最多的词条为准；比如匹配野生动物园这个词条有两个匹配，一个是野生动物图案，另一个是动物园，那我们以野生动物园为最终匹配，按照这个思路我们再说明。

有个用户搜索：“成都动物园在哪里”。

• 这个时候进行第一次词典查询，按在最大的词“成都动物园在哪里”进行查询，发现没有匹配。
• 进行第二次查询，这次查询“成都动物园在哪”，同样没发现匹配。
• 进行第三次查询，这次是“成都动物园在”，还是发现没有匹配的。
• 第四匹配的时候，这次匹配“成都动物园”，结果在词条里面检索到了。

我们保留结果是“成都动物园”，随后便去除“成都动物园”变成“在哪里”重新开始检索；这样根据我们的词典进行分词，我们可以得到结果：“成都动物园”“在”“哪里”，这就是正向最大匹配

3）逆向最大匹配法

大致逻辑和正向匹配相同，唯一的区别在于它是从右到左，每次减去开头的字。还是以“成都动物园在哪里”为例。

• 第一次词典查询，按在最大的词“成都动物园在哪里”进行查询，发现没有匹配。
• 进行第二次查询，这次查询“都动物园在哪里”，同样没发现匹配。
• 进行第三次查询，这次是“动物园在哪里”，还是发现没有匹配的。
• …….
• 最后在第七次查询我们得到“哪里”，随后便去除“哪里”对““都动物园在”进行检索。

当同样的逻辑缩减到“在”后，还是没有相对应的词典，那么将“在”也单独剔出，开始检索“成都动物园”。这样第一次检索就成功检索出来，得到结果“哪里”“在”“成都动物园”这样的分词。因为是反向其实结果和正向结果相同。

4）双向匹配

这种匹配法是为了更加准确的分词出现，把正向和反向两种算法都切一遍，然后根据词条颗粒度来进行选择。分词的词条越长越好，非词典词和单字词越少越好的原则，选出这里面最合适的进行匹配。例如：

• 非词典内的词：正向匹配（1）> 反向匹配（0） 选择反向
• 词典内的单字：正向匹配（2）= 反向匹配（2） 持平不做选择
• 总分词数量：正向匹配（3）< 反向匹配（2）选择反向

2. 词意纠错

词意纠错也是搜索里重要的一环节，在搜索的时候，打错字说错话是很常见场景（语言搜索）；并且因为文字和语言是情感交流的渠道，中文汉字会因为声调的不同有着不同的含义，同时一词多义，通假字等也是十分头疼的事情。

这词意纠错也可以按照查字典来理解，只是查询的字典是特殊字典里面的内容包含了情感，拼音还有声调相关的内容。抽象点的描述，我们在看见“康帅傅”的时候大脑会把“康帅傅”自动纠错成“康师傅”，这就有点自动纠错的味道。

1）拼音纠错

当输入的汉字存在错误时，系统需要及时联系上下文进行解析，可以将汉字转换成拼音，通过同拼音进行识别，比如“如何吧大象放入病象”，把他们未能分词成功单独留下的汉字转化成拼音“如何”“ba”“大象”“放入”“bing”“xiang”在查询字典进行处理。

2）模型算法

这部分高于繁琐，想了解的可自行搜索：SVM、Maxent等。

3. 类目预测

用户使用搜索功能在于得到解答，所以我们需要理解用户搜索内容的含义；比如用户搜索苹果的时候，她搜索的是吃的苹果还是苹果手机了；一个吃一个用这两个答案是风马牛不相及的，所以预测类目会对用户搜索结果影响很大。

做类目预测有几个方法：

1）人工配置

通过后端埋点日志搜集最近热门的搜索词，对这些搜索词进行指定配置，这样就可以保证当用户搜索苹果的时候出来的是苹果手机，而不是真的苹果；这样也是最简单有效的方法，但麻烦在需要安排人长期维护。

2）类目相关性

通过对搜索词进行算法计算，从搜索词的重要性、类目数、类目出现次数、搜索词出现次数等进行计算。

代表性tf-dc算法。

4. 结果排序

搜索结果的排序也是十分头疼的事情，比如搜索苹果手机，出现的结果是10万+条商品信息，那么谁排第一这就成了一个问题，因此我们要从权重出发进行权重排序。（商品少也可以按照最新更新时间排序，哈哈看个人）。

• 词频：对搜索对query进行分词处理，在进行预测类目后对高词频内容优先展示；
• 用户标签：符合用户标签喜好的商品进行加权,优先排序；
• 时间段：对当前时段营业（客服在线）进行加权；
• 销量、好评率：同理这就不说了；
• 商品时效：对新更新商品进行加权，可用于互冲旧商品销量、好评的加；
• 付费：竞价广告、付费升权等。

作者：wcof，在努力做产品不做产品经理的人；微信公众号：Wcof（ID：wcofPM）

本文由 @Wcof 原创发布于人人都是产品经理，未经作者许可，禁止转载

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