从减少点击次数，到降低使用负荷_从减少点击次数，到降低使用负荷载计算

去年秋天，Luke Wroblewski发了一篇名为“Requiring Less Taps in Mobile UI”的文章，并在其中提出了“流体点击手势”的概念，旨在减少用户在特定操作过程中需要执行的点击次数。

他提出的新概念挺有意思；对于“如何控制点击次数”这一问题万分关切的设计师显然也不止Luke一人。

不过我(英文原文作者)个人觉得“更少的点击次数”并不能算是一个很得当的设计目标。在UX设计的过程中，将过多的注意力聚焦在一个特定的点上，相应的风险就是对其他痛点和问题的失控。我们更应该着眼全局，并思考“怎样使这些界面用起来更容易些”。

还有哪些是需要控制的？

如果说点击次数是我们需要关注的痛点之一，那么还有哪些是我们需要从整体的角度加以控制和优化的？

Apple在自家产品及其app设计规范当中始终强调一点 - 缺乏一致性的设计会给用户带来疲劳感。虽然并不是指会令用户放下手机打个盹的那种疲劳，但比喻的说法是正确的。缺乏一致性的设计，也是我们需要控制的痛点之一。

另一方面，以注重产品性能和效率而闻名的Google则强调“如果界面加载时间超过1秒，用户的使用流程就会被中断。”

所以我们在设计和开发流程当中要加以控制的痛点其实有很多，这些都是需要我们综合考虑进来的；将过多资源聚焦在其中的一点，很可能导致其他方面问题的爆发。

降低使用负荷

上面提到的这些痛点，例如过多的点击次数，缺乏一致性的界面，较长的加载时间等等，都可以看做是软件工具强加给用户的负荷。我们真正的目标是从整体上减轻这些负荷，使用户更流畅更高效的使用产品提供的功能来完成目标。

你甚至可以试着通过量化的方式来评估产品的使用负荷，数数看在整个流程中存在多少“负荷点”，例如：

• 界面加载过程中的每一秒都算作一个负荷点。
• 每次点击算作一个负荷点。
• 用户为了寻找那些默认隐藏起来的导航或CTA(Call To Action)而花费的每一秒都算作一个负荷点。
• 在所有这些之前，用户为了使用产品而必须将手机从口袋中掏出来的整个过程算作至少一个负荷点。(Hello Apple Watch!)

着眼于整体体验

要全面的进行量化评估，应该从哪里开始计算呢？完整的流程起始于用户产生了使用产品完成特定目标的动机的那一时刻。

以天气类app为例，用户的使用动机多种多样，我们不妨聚焦于最简单最基本的那一种需求 - “外面天气如何？”

通常，你需要拿出手机，解锁，找到你想要使用的天气app，打开并等待界面与信息加载，查看信息。大体是这样，从使用负荷的角度来讲不算太坏，我们长久以来也就是这样做的。

不过也请试想一下：

• 抬起手腕看看你的Apple Watch，当前的天气信息直接显示在表盘四周的“复杂功能”区域当中。
• 如果你的Android手机就在身边，你可以直接提问“OK Google Now：What’s it like outside?”，然后手机将天气情况朗读出来。

相比于前面提到的“传统”使用流程，这些新方式对使用负荷的降低程度是不言自明的。你可以具体的数一数这些流程当中的“负荷点”，数据也会告诉你谁是赢家。

当然，通知(Notification)对于简化流程、减轻负荷也起着重要的作用。实际上，某些特定类型的通知，譬如Foursquare基于用户所在位置发送的信息，其目标就是在特定的情境中无需用户主动发起查询行为便可以推送正确的信息，极大的简化了流程。

不过，只有在设计的得当时，通知机制才能发挥出智能减负的作用。如果设计不当，它们只会增加用户的负担 - 要么在根本不需要的时候提供信息，要么在用户需要的时候提供没有实际价值的信息 - 如果发现这种情况，你最好把它们当做两个负荷点计算到评估结果当中。

此外，如今越来越多的所谓“隐形app”也在简化流程方面有着自己独到的特性。严格的讲，这些“app”不能被称作app，它们本质上是bots，依存于现有的短消息、邮件或其他社交平台而存在，本身并不拥有独立的UI体系。你在这些现有平台中输入特定的信息，便能完成相应的任务。Slackbot的众多用户会告诉你这样的东西有多好用。

形成竞争力

一款产品在降低使用负荷方面的能力强弱，将是决定它能否走向成功、甚至与庞大对手进行竞争的关键要素之一。

以天气类app“Dark Sky”为例。这款app会在首屏详细而生动的显示出接下来一个小时内将要发生的天气状况变化，这是人们在生活中常会关注的信息。

我们将Dark Sky与著名而且流行的The Weather Channel app做以比较。下面的截图演示了后者从首屏到展示下一小时天气状况信息的整个流程：

对于查看下一小时天气状况这一常见需求来说，Dark Sky相比于TWC至少省掉了3个负荷点，包括两次横向轻扫的手势，以及用户对于“小时天气信息”所在位置的思考，甚至是对该信息是否存在的疑虑。

让我们把情况设想的更加实际和复杂一些：鉴于TWC的流行程度，在你第一次尝试Dark Sky的时候，你的手机里很有可能已经安装着TWC了。所以对于Dark Sky来说，使用负荷当中还包括下载新app这一行为，不过好在只有一次，所以不用计算进常规的流程当中。

对于The Weather Channel这样的“类别霸主”来说，通常会提供庞大的功能体系来一一解决它所占领的产品类别当中的各种需求。功能越来越多，其中总会有一部分被逐渐埋没到需要依靠多次点击、轻扫等操作才能发现的地方，例如汉堡包菜单或是一层层深入的下级界面。一屏界面只有那么大的空间，顾此失彼的矛盾状况将越发严重。

如果你的产品不需要用户背负如此之高的认知与操作负荷便能发现并高效使用其核心功能，并且在这一功能上将体验打磨到极致，那么你就拥有与那些庞然大物进行竞争的力量 - 你至少可以拉拢到那些在多数时间只会用到这些特定功能，却被那些复杂的产品搞的疲惫不堪的用户。

这也是为什么很多庞大产品开始自我解绑的原因，譬如Facebook已经了解到一个小而美的独立app可以帮用户更加轻松的收发消息，用户不必因为这种高频需求而淹没在大型产品的各种复杂功能当中 - 所以我们看到了Facebook Messanger。

小结

降低使用负荷所带来的好处是多方面的。其实作为产品设计人员，我们心里或多或少都知道这样的原则，只是在实际当中，我们时常会忘记从全局层面来考虑各方面的问题。不妨尝试以量化的方式统计产品流程当中的“负荷点”，从整体上对这些问题进行调控和优化，或是尝试不同的产品设计模式来从根本上简化流程、降低负荷。

本文来自Be For Web

译者信息: C7210 - UX玩家、交互设计师、猫奴、guitar fucker，现就职于腾讯ISUX(上海)

译文地址：
http://beforweb.com/node/722