如何设计空状态与无搜索结果页面

一个空白的项目列表，可能意味着用户从来没有创建过项目，也可能意味着这一次搜索没有找到匹配项目。两种页面看起来都留着一块空白区域，却需要不同的解释，也需要提供不同的操作。

空集合与无搜索结果的实际差别，在于内容为什么没有显示出来。对于真正为空的集合，通常需要给用户一个开始的入口，或解释内容会通过什么方式出现在这里。对于没有搜索结果的页面，则需要帮助用户修改查询、筛选条件或搜索范围，因为这些条件让原本可用的内容没有被显示出来。如果两种情况都只提供“创建项目”，一个简单的搜索问题就可能变成重复创建的工作。

无搜索结果也是空状态的一种。这里真正有用的区分，是“集合本身没有内容”和“本次查询没有匹配项”：前者要等内容加入后才会改变，后者则会在请求条件改变后发生变化。

先问：做什么才能让内容出现

写标题之前，先补全这句话：“用户做了什么之后，这里就会出现内容？”答案往往足以帮助你判断，这个空白页面是在提供有用的信息，还是只有一段通用提示。

如果答案是“创建第一个项目”，页面可以解释项目里包含什么，并提供创建入口。如果答案是“移除 Archived（已归档）筛选”，页面就应帮助用户修改筛选条件。如果答案是“等请求完成”，界面其实还在加载。如果答案是“重新获得访问权限”，那么创建按钮可能无助于解决问题，甚至根本不允许使用。

这个问题还能避免一种常见的文案错误：因为看不到任何记录行，就断言没有数据。当前视图可能只知道，没有用户有权访问的记录符合这次请求。提示应当如实反映它所掌握的信息，而不应对整个工作区作出范围更大的断言。

Nielsen Norman Group 关于空状态的文章说明了两个做法的价值：解释系统状态，以及提供合适的任务入口。文章还提醒，不要在内容仍然加载时就显示空结果提示。这些原则可以作为基础，但具体应当怎样设计，仍取决于应用对当前集合和请求掌握了哪些事实。

Power BI 解释内容如何出现，NexTag 展示信息层级的重要性

NN/G 的空状态文章展示了 Microsoft Power BI 的“最近使用”视图，它解释了内容如何进入这个区域：用户打开过的内容，会出现在 Recents 中。关键在于说明了因果关系。这个视图没有暗示整个账户中都没有内容，也没有要求用户一定要新建内容。

NN/G 关于无搜索结果的研究里，还有一个可以对照的案例。在历史版本的 NexTag 搜索页上，一位参与者忽略了尺寸很小的“没有匹配项”提示，转而查看下方更醒目的内容。眼动轨迹没有记录到他注视那条提示。页面虽然提供了后续建议，但用户并没有看到自己为什么需要这些建议。

这并不意味着每个空白页面都要放一个巨大的标题。Power BI 的提示只承担一个局部任务：解释现有工作区中的某个视图。而搜索结果页必须让用户意识到，主要内容区域并没有按预期显示匹配结果。应根据具体情境，让状态提示足够醒目，再让用户容易找到有用的下一步。即使文案确实写在页面上，装饰插画和不相关的推荐内容，也可能打乱这一理解顺序。

不只看空数组，还要根据事实判断状态

只知道返回的记录数为零，还不足以决定显示什么界面。 请求可能仍在等待完成，也可能已经失败、受到权限限制，或成功返回了空结果。在实际实现中，不能只看可见记录的数量，还应结合请求状态和范围选择提示。

检查状态切换时，这张表尤其有用。输入一个查询后，立即替换成另一个，再让两个响应按相反顺序返回。界面必须显示当前请求的状态，旧请求返回的空结果不应清除新请求已经返回的成功结果。这是数据流上的缺陷，再加一张插画也解决不了。

评审时可以问用户：“现在你会怎么做？”先展示页面，不要预先解释当前状态。如果用户因为找不到保留下来的查询词而选择创建项目，说明恢复操作的控件需要调整。如果用户觉得页面还没完成而继续等待，就需要说清楚处理是否已经结束。记录用户怎样理解页面，而不只是记录他们有没有点击预期按钮；一次偶然的正确点击，可能掩盖他们对状态的误解。

根据内容为空的原因写文案

首次使用：给用户一个明确、可信的起点

首次使用的页面，应帮助用户理解自己将要创建的对象。“这里还没有内容”虽然承认了页面为空，却没有解释这个区域的用途。“把项目需求、链接和评审笔记放在一起”，则为新用户提供了更具体的开始理由。

这段解释应配上用户实际能执行的操作。如果创建项目只需要填写名称，“创建项目”可以直接打开这个简单的第一步。如果设置过程需要先连接外部服务，那么操作名称就应说明要连接什么。一个听起来很简单的按钮，如果打开后突然要求完成复杂设置，就可能在刚解决空状态问题后，又制造新的问题。

解释的多少，应当符合用户对任务可能已有的了解。第一次进入项目工作区的人，可能会需要一个简短示例；刚刚主动删除最后一条已保存搜索的人，大概不需要重新学习如何搜索。两种情况下集合都为空，但用户掌握的知识并不相同。

使用示例内容时要谨慎。演示记录可以把抽象概念变得具体，但必须明确标成示例，不能看起来像用户自己的数据。如果示例项目中有“Client approved（客户已批准）”状态，评审者就不应有可能把它误认为真实批准。空状态应减少不确定性，而不是用好看的虚构内容取代它。

没有结果：帮助修改请求

“未找到结果”说明搜索已经结束，却没有交代原因和恢复方式。有用的无结果提示，应让用户看清本次请求与结果之间的联系。对于搜索，让用户输入的查询词保持可见，而且可以编辑；对于筛选，让当前启用的筛选条件继续显示。否则，用户必须先回忆自己刚才提出了什么要求，才能决定应该改哪里。

在这个例子中，可以用“没有项目匹配‘autumn launch’”作为清楚的标题。如果日期筛选可能限制了结果，说明文字可以写：“当前日期范围为 10 月 1—7 日。”即使应用无法判断究竟是查询词还是日期范围导致没有匹配项，这条信息仍然有用。

恢复操作应当改变与问题相关的条件。例如，当前只启用了一个日期筛选时，“清除日期筛选”比“重新开始”更精确。只有确实会移除所有筛选条件时，才适合写“清除所有筛选”；如果操作会保留查询词，也应让用户理解两者的区别。如果一个重置操作悄悄同时改变了搜索和筛选范围，就可能让本来只想修改一项条件的用户感到意外。

Nielsen Norman Group 关于无结果搜索页的建议包括：明确告知搜索结果，保留继续操作的路径，以及避免采用嘲讽用户的语气。运用这些原则时，要结合眼前的任务。项目搜索、商品目录和法律文档库，并不需要相同的建议或图片。

如果展示替代内容，要说明它们是什么。“相关项目”不应该看起来像刚才查询的匹配结果。先解释没有搜索结果，再用独立标签介绍替代内容集合。用户不应为了理解为什么搜索特定内容后出现了看似无关的项目，还得反过来猜测系统的逻辑。

只说系统能确认的话

“不存在项目”是一项范围很大的断言；“没有项目符合这些筛选条件”的范围更窄；“你在这个工作区中看不到任何项目”表达的又是另一种边界。应该根据界面真正掌握的证据选择措辞，而不是根据哪句话刚好能排成一行。

对于包含私有或受限内容的系统，这一点尤为重要。结果为空，不一定意味着对象不存在，也可能意味着用户没有权限看到它。产品团队需要决定可以披露哪些信息，以及哪些恢复操作是合适的。不能仅仅为了让空状态提示更具体，就泄露机密记录的存在。

即使没有权限问题，视图掌握的信息也可能不完整。内容保存后，搜索索引可能还没来得及更新，导入任务也可能仍在处理。如果应用知道有导入正在进行，就可以说明这一状态。如果应用并不知道，就不要为了安抚用户而编造“缺少的项目很快就会出现”的承诺。

可以为这个虚构工作区写一条简单的文案规则：查询成功但没有匹配项时，显示“没有匹配的项目”；确认整个集合的记录数为零时，显示“还没有项目”。查询失败时，两种提示都不用。这样一个简单区分，就能避免网络问题套用首次使用时的乐观语气。

保留足够的结构，让下一步容易完成

空状态页面可以比有内容的列表更简洁，同时仍然保留有用的控件。搜索框、筛选标签、页面标题和集合范围，都能帮助用户理解自己在哪里。如果把这些全部移除，只换成一张居中的插画，页面也许更漂亮，却可能更难让用户继续操作。

对于这个没有搜索结果的项目列表，应把搜索框保留在原来的位置，并继续显示所选工作区。在原本应该展示结果的区域放置说明。这样用户就可以直接修改请求，不必四处寻找因为结果数量变化而移位的控件。

首次使用页面可以有更多设计空间。因为还没有记录需要比较，使用较大的介绍区域可能是合适的。即便如此，也应维持熟悉的导航和清楚的页面标题。用户在点击创建按钮之前，就应该知道自己要把项目建在个人空间，还是共享的团队空间。

不要只根据一句简短的英语来决定页面需要多大空间。应测试较长的项目名称、翻译后更长的提示，以及需要换成两行的筛选条件。空状态页面常常是在宽松的桌面画布上设计，最后却被放进狭窄的侧栏。只能容纳“No items”这种短句的设计，还没有准备好应对真实内容。

选择有用且代价最小的操作

恢复操作应帮助任务继续推进，同时避免不必要地丢弃用户已经完成的工作。 如果用户认真选择了工作区、日期范围和负责人，把所有条件全部清空，就是一次很大的重置。它也许能让结果重新出现，却也破坏了用户原本想调查的上下文。

只要系统支持，就应提供影响更小的改动。移除一个筛选条件，可能比清空整个请求更有用；扩大日期范围，可以保留仍然相关的关键词；返回上一级文件夹，也可能比直接把用户送回应用首页提供更多有效信息。

不要暗示这种较小的操作一定能成功。“移除日期筛选”如实描述了将要执行的操作；“显示你的项目”却承诺了一项结果，而界面未必知道自己能否兑现。如果系统有可靠的预览数量，就可以提供更有把握的建议；否则，操作标签应仅说明能够确认的事实。

创建入口在无结果页面上仍然可能有用，但通常应该处于辅助位置。有些人会先搜索，确认后再决定是否创建。可以保留这条路径，但不要让创建看起来像唯一的恢复方式。如果重复创建的代价很高，可以考虑先说明本次搜索只覆盖当前工作区，而不是过早建议新建对象。

连续检查同一个页面的状态变化

最能暴露问题的评审方式，是走完一小段连续流程，而不是查看一组互不相连的空状态截图。从有内容的列表开始，应用一个会产生零匹配项的筛选，清除该筛选，并确认原来的列表恢复。然后再创建一个确实没有内容的集合，对比两种状态的提示和操作。

在这个虚构工作区中，用户起初能看到当前集合里的六个项目。他们选了一位负责人，而这位负责人在所选的一周里没有项目。结果区域提示没有匹配项，同时保留负责人和日期控件。清除日期筛选后，符合条件的项目会在更宽的时间范围内重新出现，而负责人选择仍然保留。

接着切换到一个没有任何项目的新工作区。同一个结果区域这时会介绍项目的用途，并提供创建入口。因为没有启用筛选，底层集合也确实为空，所以没有必要提供清除筛选的操作。这个界面可以与上一种状态共用字体和间距，但不应共用相同提示。

这些问题既涉及设计，也涉及实现。静态对比可以说明希望实现什么行为，但实际应用仍然需要测试请求时序和状态变化。评审应聚焦于这段简短流程，不必把它扩大成一份与当前任务无关、罗列所有界面状态的目录。

语气要适合情境

个人收藏列表为空时，语气可以轻松、友好；在事故调查期间看到空白审计日志，则需要冷静而准确的说明。同一张笑脸插画和同一句“让我们开始吧！”，并不适合同时用于这两种情况。

考虑用户最可能担心什么。新用户可能会问：“这里应该放什么？”寻找已知文件的人可能会问：“是我失去了权限、找错了位置，还是输错了名称？”检查已完成工作的人，可能只需要确认没有剩余事项。把用户心中的问题说清楚以后，就更容易选择合适的语气。

不要仅仅因为列表中没有记录，就向用户表示祝贺。任务队列为空，可能意味着所有任务都完成了，也可能只是筛选条件把它们隐藏了。只有确认了积极结果，才有理由庆祝。如果应用无法确认，中性的解释会更值得信任。

同样，也不必为普通的首次使用而道歉。一个新集合没有任何记录，本身并没有什么问题。把表示中断或故障的措辞留给真正发生中断的情境，让日常空状态成为正常产品体验的一部分。

让插画配得上占据的空间

插画可以帮助说明集合里将出现什么，也可以帮助用户区分首次使用页面和搜索无结果页面。但它不应把有用的下一步推到首屏之外，也不应让页面看起来无路可走。如果去掉图片以后，提示反而更容易理解，就应调整整个构图，而不是坚持保留装饰。

对于这个工作区示例，一幅简洁的项目卡片线稿，可以展示项目会包含哪些信息。无结果页面则可能只需要一个小的搜索符号，因为查询词和筛选条件已经提供了上下文。这两种状态不必使用同一张大图，也可以保持一致的视觉风格。

必要的解释应当保留为真正的界面文字。插画可以强化筛选条件与结果之间的关系，但即使图片无法显示，文案本身仍应说得通。尤其要留意图片中的细小标签：它们在设计文件里可能很清楚，放进窄布局后却已经无法阅读。

在 OpenDesign 中评审两种状态是否区分清楚

在 OpenDesign 支持的 HTML 预览中，可以方便地比较这些方案。用贴近实际的文案构建空集合与无结果示例，手动调整文字或样式，再通过视口预设检查效果。发送到聊天中的评论，可以指出究竟是哪条提示或哪个操作需要修改。

为了让评审真正有用，请用户解释每个页面发生了什么，以及接下来会怎么做。提问前不要先把页面介绍成“首次使用状态”或“筛选后为空的状态”，因为这些标签会提前给出本来应该由设计传达的答案。如果两个页面让用户产生相同理解，那么它们的差别还不够清楚。

也要在实际运行的应用中核验数据条件：当前查询、权限范围和筛选重置，应当触发设计评审中确认过的对应提示。

一个小判断，避免更大的误解

批准一个空白区域的设计之前，先把它的标题当作一项事实断言来读，检查应用是否掌握了足以作出这项断言的信息。再把主要操作当作对“接下来会改变什么”的承诺来读，检查这个控件是否真的会带来那项改变。