2023年APP设计模式之-搜索功能

APP设计模式之——搜索功能可能在许多人看来，搜寻是个不起眼的小功能，无需花太多时间赘述。但作为PM/UI/UX，我们没有理由轻视任何涉及用户体验的产品设计，个人来讲，是不怕用户批判和吐槽的，我最怕的是眼界狭隘，思路不开阔，由于这打算了我的成长空间和速度。

所以在这篇文章中，我尽可能地把自己遇到/思索到的，涉及搜寻功能的设计模式，围围着搜寻流程，都一一列举出来，也盼望大家在看到新奇的APP搜寻模式时，贡献一下案例。

应第一篇专栏评论区@大大头披风伴侣的建议，后面全部文章插图，我都会进行标注。

另外特别感谢大家的关注与欣赏，你们的认可是我更新的最大动力。

言归正传，先放一张搜寻流程图：

湖蓝色边框是最简洁/必要的搜寻流程节点，考虑到各种各样的场景，整个搜寻流程就变得“冗长”了，但是用户体验却上去了。下面我们就逐一介绍搜寻流程中的各个动作和关键节点，以及典型实例。

一、输入搜寻内容

1.功能入口

搜寻功能入口即用户进入搜寻流程的起点，这个起点通常都以静态形式呈现在页面上，比如页面左上角或右上角的搜寻图标，或页面上的搜寻文本框（以圆角矩形为主）。如格志和Reddit：

用户点击这个图标或者文本框后，才算触发了搜寻流程的第一步：内容录入。

相对来说，搜寻图标适合低频搜寻应用，而搜寻文本栏更适合高频搜寻应用。查询类应用/场景明显特别适合搜寻文本框，而且用户使用频度越高，搜寻文本框自身面积就越大，所占页面位置也更加明显，比如网易云音乐和金山词霸：

个人来讲，不知为何，当我看到搜寻文本框的时候，就有一种立刻就要看到期盼的内容的感觉，而单纯的搜寻图标是没方法给这种感觉的。究竟搜寻图标和搜寻结果中间，总会隔着一个搜寻文本框。

2.条件输入

可能有人会说了，输入搜寻条件还有什么好说的？直接敲键盘不就完事儿了吗？

对于绝大部分用户来说，这的确没有问题，但是……俗话说得好，魔鬼都在细节里。越是这种不起眼的地方，我们越能做出一些能让小众用户觉得很好用/好玩的设计，在体现APP自身特色的同时，还能帮应用留住那些“长尾用户”。

条件输入环节，我们应当关注的设计要素：退出搜寻页面、一键删除已输入内容、触发搜寻动作执行的按钮、小键盘、小键盘增加设计。

退出搜寻界面：通常是“取消”二字，水平置于文本框右侧，也有些应用实行“＜”按钮设计，水平置于文本框左侧，比如微信阅读和Quora：

一键删除已输入内容：通常是在搜寻框右侧放置灰底白色“×”图标，也有些应用出于用户输入出错率高的状况，将这个元素放置到用户更简单“够得到”的位置，这个设计在大屏手机时代还是特别有必要的。

下面的良仓和金山词霸分别代表了这两种类型，且后者采纳了“清空”文字’代替“×”图标，居于屏幕中央略靠下的位置，可以说特别醒目了：

触发搜寻动作执行的按钮：PC端产品许多还保留着有实际作用的“搜寻”按钮，如百度首页的“百度一下”按钮：

谷歌的“Google搜寻”：

以及相当多应用的搜寻框内置的或者右侧的搜寻图标，PC端的“搜寻”触发是通过“Enter”回车键或鼠标单击完成，同理APP上的搜寻触发，要么是通过点击页面上的“搜寻”图标，要么是通过小键盘上的确认键来完成，而小键盘确认键往往有多种表现形式，如“搜寻”、“确定”、“换行”等。

小键盘：小键盘需要留意的就是依据输入框和表单的内容，来设置默认的小键盘样式，比如中文键盘、英文键盘、数字键盘等，为用户带来更顺畅的操作体验。

小键盘增加设计：增加设计指的是在小键盘上方，再增加一行命令项，在视觉设计上表现为做到和小键盘融为一体，在功能上表现为依据用户使用场景，尤其是高频操作，来设计对应的功能。

比如UC扫瞄器的小键盘增加设计，除了给出常见的网址前缀后缀，还在中间放置了一个光标精准定位滚轴，极具匠心：

还有一些带有应用自身特色的小键盘增加设计，如金山词霸和Quora。

词霸有三个按钮：“返回”（退出搜寻界面）、“清空”（一键清除已输入内容）、“翻译”（触发搜寻动作），我信任只要用户几次词霸，便会对这个界面欣赏有加，高频操作按钮居中布局，特别便利用户单手操作，且搜寻框显得特别简洁美观：

而Quora的增加设计更是独具匠心，将问答社区高频操作“搜寻-提问-阅读-回答-”中的提问入口直接放到了小键盘上方，当用户在动态搜寻结果中找不到自己想要的内容后，可以直接将想找的回答变为问题，惊不惊喜？意不意外？

而中国版Quora，即知乎，并没有建立起“搜寻-提问”的关联，提问入口仍旧是孤立的（文章发布后经@TonyLiao和@大大头披风的提示，发觉最新版知乎已经可以在搜寻结果页的上划刷新的第四屏看到“没找到想要的内容？——去提问”的悬浮提示设计）：

思索时间：右侧输入框的设计有何优缺点？如何进行优化？

再放两个特别增加设计，Termius（移动端主机管理工具）和Navicat（移动端数据库管理工具）。

前者整合了许多实体键盘按键，而后者为了不影响表结构的显示效果，干脆在增加设计行中做了个搜寻框，所以没有一成不变的设计，还是要详细问题详细场景详细分析。当然这种产品的PM基本就必需要懂相关技术和操作了：

3.帮助输入

帮助输入，指的是在用户输入前，APP供应给用户一些内容或者选项，以便用户更快更省力地输入搜寻条件。如UC扫瞄器和知乎就供应了历史搜寻记录，来帮助：

UC是给出了历史搜寻记录，而知乎则更进一步，对历史搜寻记录进行了分类，使用“内容”和“用户”两个标签让用户进行切换，而且还增加了“最近扫瞄”入口，便利用户回溯自己近期的扫瞄列表，更胜一筹。

“敬重用户的劳动”是胜利手机界面设计的最基本原则。“保存的搜寻”和“最近搜寻”使得搜寻条件简单从以前的搜寻历史中选择，而不用再次输入相同的关键词。

选项帮助输入，是指在用户输入搜寻条件之前，供应一些基本的搜寻范围（如内容分类等），让用户更快地获得期望的结果。参见全民K歌和Pinterest：

这种搜寻方式也可以称为“前置搜寻类别”。这种搜寻方式适用于分类较简洁的内容，便于精确地定位搜寻内容。

与“前置搜寻类别”相对应的，是“后置搜寻类别”，我们放到后面去讲。

此外还有包括基于地理位置搜寻的帮助输入方式，这在基于LBS的APP中特别常见，如猫眼电影和高德地图：

最佳实践：保存搜寻需要额外的步骤去命名搜寻参考值，敬重用户的劳动成果，让用户削减操作。

二、执行搜寻命令

在移动端，最广泛的搜寻模式是：用户输入搜寻内容后，APP自动执行搜寻动作，同时将搜寻结果以列表的形式展现在搜寻文本框下方，用户连续输入搜寻内容，搜寻结果也会相应自动变化，当全部条件输入完毕时，点击搜寻按钮，显示最终结果。

这种搜寻模式，我称之为动态搜寻，这也是目前最符合“懒设计”理念的搜寻方式。同时，还有一种较为“古老”的搜寻模式，即静态搜寻，即用户输入完全部的搜寻条件，再一键执行搜寻命令。

动态搜寻

动态搜寻，指输入搜寻条件时的实时搜寻+实时展现。这种设计也被称为动态过滤，即输入文本数据，对应搜寻结果将会动态过滤显示在屏幕上。同时，这也是一种特别形式的帮助输入（见4.1.3）。我们以豆瓣为例：

在输入“梦”和“梦的”两个搜寻条件时，结果呈现的完全不一样，这是由于动态搜寻时，是依据已输入内容的词频热度进行搜寻和排序的。这又涉及到搜寻算法，对于这部分内容，我们放到后面去具体介绍。

目前使用静态搜寻设计的APP已经越来越少，因此不做赘述。

三、搜寻等待

通常状况下，无论是动态搜寻还是静态搜寻，在搜寻结果呈现之前，都会有进度条或者加载交互动作的指示器，用以告知用户：“正在搜寻中，请急躁等待”。当搜寻动作执行完毕后，再展现最终的搜寻结果：

在2G（其次代移动通信技术）时代，下载速度在几KB/S到10几KB/S之间，从录入搜寻条件到显示搜寻结果，通常需要1秒以上的响应时间，这时的系统反馈就特别必要，进度条或者加载动作能给用户以提示，表示正在搜寻中。

到了3G/4G，甚至将来几年就能够在国内应用的5G时代，搜寻结果几乎瞬时呈现，这时系统反馈动作是否必要呢？答案是确定的，由于哪怕是在一线城市市中心，也会存在网络环境差的场景，应用仍需要给用户供应等待提示。

四、展现搜寻结果

1.

展现方式

搜寻结果的展现，涉及到展现方式、展现层级等。

搜寻完毕，结果会显示在原有页面下方，或在新页面中显示（相对较少）。展现方式也纷繁多样。比如最简洁的文字列表视图（墨墨单词和TripAdvisor）：

图文并茂式列表视图（网易云课堂和在行）：

还有一些简约化，内容设计感极强的列表（Kickstarter和Town）：

Kickstarter是横向左右滑动卡片式列表，每个卡片代表一个众筹项目；Town是纵向滑动大图列表，每个条目代表一处人文景观。

增加列表视图（豆瓣和携程）：

增加列表视图，是一般列表视图的变体，指在列表视图的基础上，糅合其他设计要素，而呈现出更加多样的视图方式。

比如豆瓣的多重列表视图就是增加列表视图的一种，它采纳了基于搜寻结果类别进行分列表展现的视图方式。简洁来讲就是展现页面有多个列表，如“图书”列表、“电影/电视”列表等。

携程搜寻展现页面是增加型列表视图的典型，在整体是列表视图的整体视觉效果上，有的列表项本身就是一项内容集合，如“张家界的旅游度假”；有的列表项本身是一个详细条目（张家界碧桂园凤凰酒店）；有的列表项增加了内容详情介绍（旅游产品介绍），不同列表项代表不同类别（飞机、酒店、旅游产品等），这种视图方式适合搜寻结果门类及其简单，不同结果展现权重不同的应用。

表格视图（小红书和ASOS）：

当搜寻结果需要图文并茂地进行展现，且需要支持用户快速扫瞄较多条目的时候，表格视图再适合不过了，而上述两个前提，缺了任何一个，都会影响用户体验。这种视图方式常常应用在购物类的应用中，且最多两列排列，再多的话，信息就太过密集。

假如需要图文显示，且用户扫瞄速度更快，条目更多的时候，就由表格视图变为了图文并茂的列表视图，如淘宝和美团，只保留一列内容，是为了不打断用户的视觉流。设想一下从上到下，和从左到右+从上到下，哪种方案更好？

缩略图（Eventbrite）：

缩略图视图模式，指的是搜寻结果的内容条目，是将详情页的图文内容进行选取、缩小或模糊处理后，以N个缩略图的方式，展现在搜寻结果展现页，因此该模式通常和其他模式混合使用。

甚至地图卫星图（摩拜和ofo）：

地图/卫星图的视图方式，适合于供应基于LBS（基于地理位置信息服务）的应用，可以为用户供应空间和位置的宏观视角。当然，还有个默认前提就是：搜寻结果信息类别单一，比如摩拜和ofo搜寻结果都是标准化、同质化的单车，用户不需要关怀这辆车有什么特质，只需要关怀能不能用即可。

有时依据搜寻结果的简单程度和用户使用首选项的不同，也会使用多种视图显示，如高德地图和Eventbrite，就结合了地图和列表两种视图方式：

高德地图搜寻杨家火锅，火锅这种餐饮行业，即便同一品牌，不同门店供应的服务也可能相差极大，比如店铺环境、人气、价格（不同商圈价格会略有变化，会有一个价格系数）、经营状态、营业时间、评价等，所以除了位置信息，还需要把其他关键信息以列表形式呈现给用户。

而Eventbrite特征更加明显，我输入的搜寻条件“基于纽约及周边地图的艺术类活动”明显囊括的内容更加纷繁多样，所以在展现结果时，除了使用地理位置视图，还将活动用列表的形式呈现出来，配以主题、时间、地点和价格介绍等。

2.内容加载

在搜寻时，通常使用延迟加载技术，使部分结果可以被优先、快速地展现出来，而更多数据则会被延迟加载，这种设计有助于提高用户体验，如Foursquare：

很多应用通过““查看更多”按钮，或拖动屏幕（上拉刷新）时自动加载更多结果。如LOFTER和ABCNews：

也有应用把延迟加载做得更平滑，拖动屏幕（上拉刷新）时自动完成更新，如开眼，只有在关闭网络的状况下，我们才能看出它的加载交互，是由logo动效完成的。

五、结果筛选

结果筛选，指在搜寻结果的基础上，通过筛选条件，对内容进行过滤，得到更加精确的搜寻结果。通常分为前置筛选、后置筛选和全局筛选。

1.前置筛选

前置筛选是在用户触发搜寻动作之前进行的筛选，如豆瓣：

在动态搜寻执行完，点击“全部”菜单，在下拉列表中选择“图书”，得到筛选后的结果，再次点击“搜寻”按钮，进入展现搜寻结果的全屏页：

2.后置筛选

后置筛选，也称结果筛选。指的是当搜寻动作执行完毕后，基于搜寻结果，所进行的二次筛选，通常是以“搜寻表单”的方式呈现，特点是一个单独的表单输入多个条件和一个明显的搜寻