上一期写到了原型搜索的需求分析篇，这一期继续来聊聊原型设计篇。
既然上一期已经确定了是通过搜索的形式来检索产品文档，那么首先用户得知道自己想要什么，然后将想要的内容以文字的形式键入到搜索框中，系统则根据用户的输入去匹配相应的内容，最后再返回呈现给用户，这是搜索产品设计的基础逻辑，简单来说可以通过下图来表示从用户视角的搜索流程。
用户搜索流程图
在这个过程中，我们发现这里面有 2 个关键的行为，一个是用户主动输入，既然是用户主动输入的信息，则相应地表明用户是相对清楚自己的需求。另一个行为则是系统的匹配机制，系统获取到用户输入的内容后，可以根据内容返回若干结果给到用户，供用户挑选。通常而言，匹配到的结果数量越少，往往获取到的文档更精准。但是现实是随着工作内容的变化，产品输出的文档也相应地增多，匹配难度相对较大，这个时候提供一些额外的辅助信息以便于用户筛选，就显得尤为必要了。
作为产品而言，了解用户需求是前提，设计对应的用户流程是结果，在这 2 者之间则是一种微妙的平衡，平衡着用户需求、业务需求、产品现状、技术实现等综合因素，才能设计出相对合适的产品。
从技术实现的角度而言，上一期我们分析到每一个产品文档是以一个个页面（page） 的形式存在，每一个页面都会有一个标题，通过检索标题的关键字，我们就可以匹配到对应的文档。而我们现阶段是通过 MiniO 文件系统后台来管理产品原型的，搜索的功能可以像此前做了个小工具一文中一样，通过油猴脚本注入页面的方式增加一个搜索栏来实现MiniO 文件系统原型搜索的功能（这一部分用户是无感知的，就像搜索功能原本就存在一样），具体而言技术实现流程就是下面这样的。
Axure原型搜索技术实现流程
接下来，会按照这个实现流程一步步展开来讲原型设计。
首先看搜索的入口，要看搜索入口的位置，自然要看搜索这个功能在产品使用中的权重，摆放的位置决定着该功能的重要程度。作为文件管理系统，文件管理自然是一方面，当文件不断积累后，如何从茫茫的文件库中重新找到所需的文件又是非常重要的一环。从这个角度而言，搜索在这个系统中自然也算是高频的功能，所以能在页面上常驻自然就再好不过了，这样用户在想用的时候可以一眼找到，而结合 MiniO 系统现有的特色，左侧的菜单栏始终常驻页面，所以将搜索放在左侧导航栏是个不错的选择，另外左侧的列表样式在前端实现上也容易保持统一。
搜索功能入口的添加
搜索框默认状态
搜索框输入状态
匹配内容的时候，如果做得更好一点是可以对用户的输入进行一些纠正的，因为是人来进行交互就有理解偏差，输入是用户理解的行为，输出是系统理解的行为。比如用户在百度搜索框中输入 “tuipiao” 拼音也可以关联到“退票”相关的联想词。
百度输入退票的拼音
关键词联想后返回的结果存在多个的情况下，一般也要考虑到排序问题，一般来说排序越靠前则越接近用户想要的，在这里因为我们是静态的文件搜索，所以暂时就按照内容的更新时间倒序来排，最近更新的文件排在最前面。
除此之外，任何产品环节的设计都需要考虑一些边界情况，比如用户输入关键词后，内容还没有被返回，这个时候为了缓解用户的焦虑感，可以展示一个正在请求结果的加载状态，当服务器告知了结果但是并没有匹配到文件的时候，则明确展示一个无搜索结果的状态给到用户。
请求加载中…
没有匹配到结果的状态
好的，今天就先码到这里了，这次展示更多的是面向用户端的交互逻辑，下一期来展开聊一聊对应界面的前端开发环节，有什么好的发现，可以在底部留言一起交流分享~。
下一期聊一聊产品全流程中的前端开发环节。
