空状态 UI 设计：内容缺失时引导用户迈出下一步

1. 诊断内容为何为空

将空状态看作产品状况的报告，而不是装饰界面的机会。询问界面出现前发生了什么、系统知道什么，以及用户能否改变当前情况。尼尔森诺曼集团指出，空状态可以传达状态、帮助学习，并提供进入关键任务的路径。但要利用这些机会，首先必须正确识别当前状态。

尤其不要在请求仍在进行时显示“没有项目”。应保持加载指示器或骨架屏可见，直到结果明确。如果请求失败，要说明故障和恢复选项；如果请求成功但返回零个项目，要说明没有匹配内容。这样的区分能防止用户将暂时延迟或系统问题误认为真实结果。

2. 撰写与原因相符的文案

用标题点明状态，辅助文字则解释其含义或如何继续。标题应易于扫读。只有句子能回答真实问题时才补充说明。Apple 的写作指南建议在空白界面提供清晰的下一步、使用以行动为导向的标签，并直接说明如何解决错误。避免以俏皮表达掩盖含义，避免“这里什么都没有”等含糊标题，也不要责怪用户。

例如，假设一个收藏页在首次使用时显示“你保存的指南会出现在这里”，接着提示“保存指南，以便日后查看”，并提供“浏览指南”按钮。完成的待办清单则可以显示“所有事项都已完成”，并提供“查看已完成任务”。两者描述的是不同情况：前者教用户如何填充功能，后者确认成功完成任务。

对于搜索成功但没有匹配项的情况，假设提示可以写成“没有与‘兰花’匹配的项目”，并建议“试试范围更广的词，或清除筛选条件”。尽可能保留查询词，并确保筛选变更可以撤销。网络故障时，应写“无法加载项目”，并提供“重试”。系统尚未完成检查时，不要声称不存在项目。

• 指出相关对象或筛选条件，让提示即使脱离上下文也能看懂。
• 在按钮上使用动词，例如“创建项目”“清除筛选条件”或“重试”。
• 将说明放在受影响内容附近，并同时使用文字，不要只依赖颜色或图像。
• 避免“哎呀”、责备语气和技术代码，除非用户需要代码来解决问题。

3. 让下一步有用，而非机械地提供按钮

当用户有合理的方式改变现状或继续任务时，提供操作。首次使用通常适合创建或添加；无结果时可清除限制条件；错误时可重试。而清空的收件箱或完成的锻炼可能根本不需要操作。不要只为让面板看起来可交互，就在每种状态中强塞按钮。

恢复操作应与问题程度相称。刷新失败通常只需行内说明和重试，而非阻断式警报。Apple 建议让反馈形式与信息的重要性相匹配，仅在关键且可采取行动的情况使用警报。对于搜索，应保留用户已做的输入，并提供合理的调整方式，而非悄悄修改查询。Material Design 还建议，在确实有帮助时，可使用入门内容、简短教学内容或明确标注的最佳匹配结果作为替代。

只有在插画能提供背景、温度或辨识度时才使用。它不应与提示信息争夺注意力，也不应让用户误以为装饰图片可交互。紧凑的筛选结果可能只需要简单图标；首次使用的工作区则可以展示一小段未来会容纳的内容示例。如果加入入门内容，要让用户容易识别和移除。

• 选择一个直接针对原因的主要操作。
• 只有在能回答用户可能提出的后续问题时，才增加次要帮助路径。
• 当空结果是好消息时，使用低调的完成提示。
• 确保键盘和屏幕阅读器用户也能理解操作。

4. 审视整个状态，而不只是插画

在实际容器中检查空状态：全屏首次使用视图、小型侧边栏和筛选后的表格，空间和信息层级需求各不相同。将提示放在它所描述的区域附近。放大文字或换行时仍须易读，且主要操作无需靠识别颜色也应容易找到。还要测试状态转换：从加载到空状态、从加载到错误、从重试到成功，以及调整筛选条件后重新出现结果。

实用的资料库评审从触发条件和预期恢复方式开始。对每种模式，记录状态、标题、可选说明、主要操作、次要路径，以及用户选择后的结果。比较截图的结构和视觉层级，再结合上下文检查产品行为；静态图片无法告诉你错误是否可恢复，或结果是否真的为空。可浏览 ScreenKits UI 资料库获取视觉参考，并探索所有类别，寻找相邻的设计模式。

• 用户能否分辨内容是不存在、仍在加载，还是因错误而无法获取？
• 提示是否反映当前查询、筛选条件、账户或已完成的任务？
• 操作是否保留有用的输入，并带来可见的结果？
• 该状态在小尺寸、较长的本地化文案和辅助技术下是否仍有效？
• 用户能否从错误中恢复，或找到调整无结果搜索的方法？