一个简洁的界面背后隐藏着什么

我喜欢简约的界面。我的设计方法深受丹麦功能主义的影响，通常在添加新控件之前，我会先考虑哪些元素可以删减。然而，一个界面即便看起来极为克制，也可能要求用户付出相当多的努力。

我此前曾讨论过关于赋能的写作的观点，如果仅停留在让控件更易被发现这一层面，论点会显得有些抽象。因此，我想通过一个具体的小例子来说明：将一篇文章保存以供稍后阅读。

以下版本仅为示意性设计，并非可用性研究或对某款产品的拆解分析。它们展示的是同一篇文章，并提供相同的操作；所不同的是，这些设计在解释该操作时所包含的信息量各异。

保存文章

设想一个阅读列表，每行显示标题、来源和日期。在简约版本中，当鼠标悬停于某一行时，会出现一个书签轮廓图标；点击后，该轮廓变为实心图标。

如果你已经知道该图标的功能，这样的界面设计可谓合理：你将其展开，点击它，注意到状态变化，然后继续操作。文章内容占据了大部分空间，这也正是我们希望的效果。

但若去除这些预设假设呢？你从未使用过这款产品，因此并不清楚这个书签是用于保存、打开已保存的内容，还是将当前文章加入某个收藏集。

在做出决定之前，你首先需要找到它。在触屏设备上，悬停并非一种可靠的控件揭示方式，因此设计还需提供另一种路径。

我们也可以在该行获得键盘焦点时显示该控件。这有助于键盘用户触及该操作，却无法消除对图标含义的疑虑。为屏幕阅读器用户提供可访问名称固然有用，却无法为视觉正常的用户提供我们已移除的直观说明。

为了使设计更为明确，在标题旁放置一个小型的“保存”按钮。激活后，按钮变为“已保存”，并配以附近的提示信息“撤销”。此时，界面不仅为该操作命名，还确认了其状态，并提供了返回的途径。

第二个版本包含了更多可见信息。但我仍然认为，它能更好地帮助初次接触该任务的用户。他们可以直接读取即将发生的结果，而无需从一个图标及其填充变化中推断出其含义。

以上是我基于这些示例的判断。不过，我仍希望观察用户实际使用时的表现，因为在我看来有用的标签，并不能证明整个任务因此变得更容易。

凯文·博内特在回应本文时提出了一个有益的观点（在此转述）：明确的标签可能会占用更多空间，同时减少用户需要自行推断的内容。此外，如果每篇文章都配有“保存”按钮，其可访问名称还需包含文章标题，以便使用屏幕阅读器或语音控制的用户能够分辨正在保存的是哪篇文章。

第五十次访问时会发生什么？

明确的设计同样存在代价。每行配备“保存”按钮会重复同一文字；确认消息可能打断阅读，尤其是在每次点击都会在屏幕一角弹出提示的情况下。

如果每个操作都与文章标题争夺视线，密集的列表也会更难快速浏览。

我会让“保存”按钮保持可见，但在视觉上弱化其地位，使其低于标题。已保存状态也应显示在同一位置，便于用户无需转移注意力即可查看。

对于即时纠正，可在该状态旁提供“撤销”选项；随后则保留一个持久且易于发现的“从已保存中移除”操作。短暂的提示不应成为唯一的返回途径。

如果产品设有专门的已保存文章视图，该处可能需要不同的操作标签。既然你已在查看已保存的内容，那么在每项旁重复显示“已保存”并无太大意义，直接使用“移除”反而更能清晰地传达意图。

在该视图中，由于已知所有项目均为已保存状态，我们可以利用这部分空间进一步说明用户接下来可以进行的操作。上下文本身已经在一定程度上承担了先前重复标签所起的作用。

一个控件在某种场景下可能既快捷又熟悉，而在另一场景下却令人困惑。仅凭孤立的组件截图，我们无法对此作出定论。

也要减少用户的认知负担

针对本例，我的改进建议是：保留简洁的布局，在所有输入方式下均保持操作可见，并用简短的文字加以说明。如果本地的“已保存”状态与“撤销”操作已足够传达信息，便可取消单独的成功提示。

同时，避免添加仅重复“保存”字样的解释性工具提示。

最终，界面将保持相对简洁，操作一目了然，反馈也贴近用户触发的位置。屏幕上仍有部分说明，但需要阅读的独立元素减少了。

为检验效果，我会请用户保存一篇文章、再次找到它并将其移除，观察他们在哪些环节停留，以及对各控件有何预期。随后，我会分别测试触屏与键盘操作，并借助屏幕阅读器检查其状态与操作是否一致。

仅统计可见元素的数量，并不足以了解这些情况。

我依然倾向于删减元素，只是在移除之前，我希望确认这些元素究竟帮助用户理解了什么。对于自己长期设计的界面，很容易忘记自己早已熟知其中的许多细节。