隐私用户体验：更好的通知和权限请求

• 第 1 部分：Web 表单中的隐私问题和隐私
• 第 2 部分：更好的 Cookie 同意体验
• 第 3 部分：更好的通知 UX 和权限请求
• 第 4 部分：隐私意识设计框架

想象一下，你参加某个你真的不想迟到的会议迟到了。 你匆匆穿上鞋子和外套，拿起门钥匙，抓住门把手——只是为了及时出门。 下楼时，你把手伸进口袋，掏出手机查看地铁时刻表或叫出租车。

瞥一眼屏幕就足以让您大汗淋漓：您意识到自己忘记为手机充电一夜，而它正在以剩余 2% 的电量运行。 当您满怀希望和信念奔跑在街上时，您调暗屏幕亮度并在主屏幕上寻找正确的应用程序图标。 当然，就在那一刻，大量的通知会从你的屏幕上倾泻而下，要求你全神贯注地关注新的关注者、更新、提醒和消息。

您很有可能非常清楚这是什么感觉。 在这种情况下，您对级联通知堆栈采取行动的可能性有多大？ 几分钟后，当您错过连接时，您有多大可能完全关闭通知？ 这是通知实际上以最具破坏性的方式进入的情况之一，尽管所有精心设计的用户流和精美的宝贵像素。

有如此多的应用程序和服务、人员、机器和聊天机器人在争夺我们的注意力，保持专注是一种需要细细品味和保护的奢侈品，因此难怪现在通知不享有良好的声誉。 不仅如此，他们也常常觉得不合时宜，而且也很容易被操纵。

“它们经常出现在它们最不相关的时候，它们会产生一种错误的紧迫感，稀释注意力并造成挫败感。”

— Alex Potrivaev，对讲机

这适用于主屏幕上的浮动窗口，以及工具栏中的全能未读计数。 这也适用于被屏蔽为通知的营销消息，以及分解为许多小消息以永久吸引对服务的关注的社交更新。

所有这些通知都需要立即关注，并且感觉非常具有侵略性，发挥着我们不想错过并与我们的社交群体保持联系的愿望。 事实上，它们以一种黑暗模式无法做到的方式破坏隐私——通过无条件地要求和吸引注意力，无论用户当前在做什么。

然而，他们觉得有侵略性并不是通知的错。 是我们将它们设计成经常妨碍它们。 用户不想错过重要的通知，错过及时的消息或有限的销售，但他们也不想被永无止境的嘈杂更新潮所困扰。 如果后者发生得太频繁，用户就会完全关闭通知，正如一位用户所说，由于“绝望地乞求关注”，用户通常会对应用程序和品牌产生苦涩的回味。 一个罪魁祸首可能会毁掉其他所有人，尽管事实上没有通知与另一个通知不同。

通知的多面性

通知本质上是一种干扰； 它们将用户的注意力带到他们不知道或可能想要提醒的（潜在的）重大事件上。 因此，他们可以非常有帮助和相关，提供帮助，并为日常生活带来结构和秩序。 直到他们不是。

一般来说，通知可以是信息性的（日历提醒、延迟通知、选举之夜结果）或鼓励行动（批准付款、安装更新、确认好友请求）。 它们可以从各种来源流式传输，并可能产生各种影响：

• 当用户与 Web 界面交互时， UI 通知在 UI 中显示为微妙的卡片——因此，它们被广泛接受并且比它们的一些对应物更少侵入性。
• 即使用户没有访问 UI，浏览器内的推送通知也更难消除，并引起人们的注意。
• 应用内通知存在于桌面和移动应用程序中，可以像 UI 通知一样简陋，但可以在推送到主屏幕或通知中心的消息中扮演更核心的角色。
• 操作系统通知（例如软件更新或移动运营商更改）也混在一起，通常与各种笔记、日历更新以及介于两者之间的所有内容一起出现。
• 最后，来自聊天机器人、推荐系统和真人的通知可以进入电子邮件、SMS 和社交消息应用程序。

你可以看到通知——考虑到它们的所有风格和来源——在某些时候可能会变得不堪重负。 但这并不是说我们对收到的每条通知都给予完全相同的关注。 对于绝大多数用户来说，最终安装由操作系统通知提示的软件更新可能需要数周时间，而确认或拒绝新的 LinkedIn 或 Facebook 请求通常不会超过几个小时。

并非每个通知都是平等的，用户给予他们的关注程度将取决于其性质，或者更具体地说，取决于触发通知的方式和时间。

Shankar Balasubramanian 在他关于“通知系统的批判性分析”的文章中进行了出色的研究，将通知触发器分为几组：

我们不能推断出一组触发器总是比另一组更有效，但是来自每一组的一些通知往往比其他组更能吸引注意力：

• 人们更关心来自亲密朋友和亲戚的新消息、来自选定同事的工作时间通知、银行交易和重要警报、日历通知、预定事件、警报以及任何可操作和等待的确认或发布。
• 一般而言，人们不太关心新闻更新、社交信息更新、公告、新功能、崩溃报告、网络通知、信息和自动消息。

不出所料，用户倾向于立即关注低电量通知或付款确认； 此外，日历提醒、进度更新（例如包裹递送 ETA）和一对一消息比其他通知更重要。 事实上，在我们与用户进行的每一次对话中，来自另一个人的消息的价值远高于任何自动通知。 当然，如果用户不耐烦地等待通知，优先级可能会略有变化，但只有少数人会不顾一切地急于检查照片上的第 77 位。

所以通知可以不同，不同的通知会有不同的感知； 然而，越是个性化、相关和及时的通知，我们应该期望的参与度越高。 但这对通知的设计意味着什么，我们如何才能让它们的侵入性更小、更高效？

不要依赖通用默认值：设置通知模式

客户选择注册服务通常是有充分理由的。 没有多少人早上醒来希望当天创建一个新帐户。 事实上，他们可能会觉得您的服务可以帮助他们完成日常任务，或者可以改善他们的工作流程。 希望他们不需要通知来了解服务的工作方式，但他们可能需要接收通知来了解服务提供的价值。

也许他们收到了来自潜在雇主的重要信息，或者也许有一个约会资料匹配值得一看。 他们可能不想错过这些消息，因为他们已经有一段时间忘记签入服务了。 作为设计师，我们需要在组合中加入恰到好处的通知，以保持客户的积极性，同时只向他们提供相关且可操作的指针。

不幸的是，对于大多数服务来说，注册并不少见，只是过了一会儿才意识到收件箱里塞满了各种消息（主要是纯粹的信息），通常是一个接一个地发送，而且很少有可操作性。 尤其是电子邮件通知通常在默认情况下打开，通过同意冗长且难以管理的条款和条件来暗示用户的同意。 没有人喜欢被一堆不请自来的消息轰炸，这对于垃圾邮件和不需要的通知一样适用。

与其默认为所有客户设置默认通知频率，我们可以开始非常不频繁地仅发送一些精选通知。 当客户继续使用该界面时，我们可以要求他们决定他们喜欢的通知类型和频率。 Cookie 同意提示也是如此：我们可以提供预定义的推荐选项，包括“平静模式”（低频）、“常规模式”（中频）和“高级用户模式”（高频）。

不过，我们甚至可以比这更细化。 例如，Basecamp 引入了“始终在线”和“工作可以等待”选项作为其入职体验的一部分，因此新客户可以选择是否希望在发生通知时（随时）接收通知，或选择特定时间可以发送通知的范围和日期。 或者，反过来，我们可以在用户不想被打扰时询问他们，并在那时暂停通知。 并非每个客户都希望在工作时间以外或周末收到与工作相关的通知，即使他们的同事可能会在地球另一端的周六晚上加班。

随着时间的推移，通知的格式也可能需要调整。 用户可以选择“摘要模式”，而不是在事件发生时逐一发送通知，将所有通知分组到每天或每周特定时间发送的单个独立消息中。

这是 Slack 在通知方面提供的设置之一。 事实上，系统也会随着时间的推移调整通知的频率。 最初，由于 Slack 频道可能非常安静，系统会为每条发布的消息发送通知。 随着活动变得更加频繁，Slack 建议降低通知级别，以便仅在实际提及时才通知用户。

Slack 提供的另一个功能是允许用户突出显示选择的单词，以便用户只有在提到他们关心的主题时才会收到通知：

听起来通知的频率在这一点上受到了太多关注，但当被问及通知的常见痛点时，迄今为止，最常见的问题是它们的高频率，即使这些消息是相关的或可操作的。

底线是：开始缓慢而稳定地发送通知； 设置通知模式，并提供精细的选项，例如触发器的选择和通知的格式。 发送太少总比发送太多好：如果客户希望在错误的时间选择退出大量让他们紧张的通知，您可能不会再有机会了。

谨慎选择时机

我们可能不愿意承认这一点，但对我们中的许多人来说，这一天并不是从对初升的太阳的和平、专注的问候开始的； 相反，它始于对我们手机发光的屏幕进行乏味，反射性的一瞥。 更具体地说，我们每天早上看到的第一件事甚至不是当前时间或我们所爱的人，而是我们睡觉时不知疲倦地堆积起来的一堆通知。

这种心态不一定是提醒用户更新的隐私政策、闪亮的新功能或需要最终确定的未偿费用的最佳机会。 不过，新的社交分享和来自社交圈的反应等个人通知可能更具相关性，就像即将到来的约会和当天的待办事项一样。

时间很重要，及时的通知也很重要。 您可能不想在半夜打扰您的客户，因为他们会因时差严重而到达偏远的目的地。 因此，最好跟踪时区和当地时间的变化，并相应地调整通知的传递。 另一方面，当重要通知不再相关时出现，客户不会特别高兴，因此如果他们正在跟踪重要事件或公告，您必须确定该事件是否足够重要以干扰他们一个不舒服的时间。

您的分析将告诉您用户何时可能对您的通知采取行动，因此最好根据时间研究和跟踪响应，并在该时间触发通知的发送。 例如，如果客户最愿意在早上分享消息，则将通知推迟到当地时间早上的适当时间。

通过设计避免压力情况

对于通知，时间并不是唯一需要考虑的重要属性。 还记得本节开头那个希望抓住他们联系的可怜角色吗？ 在电池电量极低的情况下释放一组通知并不是一个好主意，而且当用户正在为连接而苦苦挣扎或专注于驾驶汽车等任务时，它同样会适得其反。 如果您可以评估电池电量和连接质量，最好避免在用户状况不佳时发送通知。 当然，通知也必须是相关的，所以如果您也可以评估用户的位置，请避免发送根本不适用的与位置相关的通知。

有时很难保留通知，因为它们可能对用户的当前活动至关重要。 如果用户正在开车，按照导航器应用程序中的指示，您可能需要提供更持久和谦虚的通知，告知因道路事故而建议的路线变更。 在这种情况下，就像其他重要通知一样，我们可以显示一个浮动按钮“有新更新可用。 刷新。” 与阻止访问内容的通知相比，它的侵入性要小得多，但它在指示页面或页面状态可能已过时并且有新信息可用方面同样有效。

事实上，即使是基于用户过去的行为，也不必在特定的默认时间发送通知，而是可以探索硬币的另一面并利用快乐和成功的时刻来代替。 汇款服务 TransferWise 会在客户收到付款时显示通知——这不是在 App Store 上要求对应用进行评论的绝佳时机吗？ 我们可以跟踪重要的里程碑，并在达到高级功能时及时通知用户，正如 Luke Wroblewski 所说的那样。

通过分组通知减少频率

在给定的日子里，只有适量的通知没有黄金法则。 就像每个通知都不同一样，每个客户的偏好和动机也不同。 为了保持用户的参与度，您可能需要根据客户的覆盖面或偏好逐步发布通知块。 这就是逐渐分组的地方，正如 Intercom 产品设计师 Alex Potrivaev 在“设计智能通知”一文中所解释的那样。

这个想法很简单。 如果您知道您的客户平均每个帖子得到的反应少于五个，那么为每个人提供一个独特的通知可能是个好主意。 如果消息来自重要事件，例如来自密友、家人或有影响力的人的消息，您也可能会触发通知。 此外，正如我们所知，由另一个人的操作触发的通知比自动通知更有价值，优先考虑并主要关注特定客户的个人通知。

一旦通知的数量增加，我们就可以开始对它们进行分组并在适当的时候提供简洁的摘要。 例如，Facebook 将通知汇总在非侵入式块中，每一行都突出显示一种类型的事件，例如对特定消息的反应（“Stoyan Stefanov 和其他 48 人对您的帖子做出反应……”） 。 另一方面，LinkedIn 似乎一个接一个地触发了几乎每一个事件（“Stoyan Stefanov 评论了你的帖子”） ，因此污染了通知流，使其难以扫描和使用。

当然，根据用户的历史记录，我们可以自定义的不仅仅是通知分组。 一旦我们知道用户对新照片的点赞有何反应，无论他们是短暂地看了一眼，还是深入了解了每条通知，我们就可以在下次提供更好的通知。 正如亚历克斯总结的：

“根据您通常与内容交互的方式，可以提供更好的措辞和结构选择，并且根据默认行为，您可能会看到结构不同的通知。”

当然，这也需要持续的反馈循环。

允许用户暂停或暂停通知

几乎没有任何公司会忽视其客户数据的价值。 事实上，我们可以通过引入反馈循环获得有价值的长期见解； 也就是说，不断为客户提供“查看更多”或“查看更少”特定类型通知的选项。 但就像我们倾向于将残疾视为一种开/关状态（您要么有残疾，要么没有），我们经常觉得我们可以仅根据用户过去的行为来准确预测用户的行为。

然而，现实很少是非黑即白的。 我们的用户可能会因为一只手臂抱着婴儿而暂时受到阻碍，或者由于最近发生的不幸事故，他们发现自己的情况也会以同样的方式波动。 响应传入通知的快速操作（例如打盹）可以帮助缓解问题，尽管是暂时的。

用户的上下文不断变化。 如果您发现参与率异常下降，或者您预计即将收到大量通知（可能是生日、结婚纪念日或选举之夜），请考虑提供静音、暂停或暂停通知的选项，也许在接下来的 24 小时内。

这可能与我们的直觉大相径庭，因为我们可能希望在客户突然沉默时重新吸引他们，或者我们可能希望在重要事件发生时最大限度地提高他们的参与度。 但是，在大多数情况下，按通知的频率进行操作太危险了。 很容易达到一个看似无害的通知会引导客户离开的地步，即使从长远来看也是如此。 用户暂时不活跃或不想活跃可能有充分的理由，而且通常情况下，它与服务完全无关。

另一种选择是建议更改用于使用通知的媒体。 用户倾向于将不同程度的紧迫性与不同的沟通渠道联系起来。 应用内通知、推送通知和短信被认为比好的电子邮件更具侵入性，因此当频率超过某个阈值时，您可能希望推动用户从推送通知切换到每日电子邮件摘要。

设置阈值并建立通知决策树

但是，阈值不容易正确设置。 重要事件应触发即时通知，以便及时收到。 不太重要的事件可以等待，但将客户的注意力吸引到服务上可能会很有用。 必须无情地过滤掉可能不相关的通知，以便为重要通知留出时间和空间来珍惜和重视。

一般来说，较短的通知，例如来自朋友和同事的消息，如果它们不紧急，则最适合作为 UI 通知，或者如果它们是推送通知，则最适合。 较长的通知最好作为电子邮件发送——无论它们是否紧急。 这个经验法则会因服务而异，因此您可以建立一个通知决策树，根据紧急程度、长度和频率来跟踪哪种媒体最适合特定类型的通知。 此外，您可以定义阈值并在达到阈值时触发暂停或调整设置的提示。

使选择加入和选择退出显而易见

如今，几乎可以预期一项服务会走向极端，使客户很难选择退出全能通知。 巧妙地隐藏在界面偏远角落的晦涩措辞和晦涩标签并不少见。 很少有其他设计考虑因素会对品牌造成更大的伤害和破坏。 当用户无法轻松调整设置时，他们会使用重炮，将电子邮件通知标记为垃圾邮件，或在操作系统设置或浏览器设置中阻止通知。 对于网站或应用程序，没有简单的方法可以从中恢复，除非再次乞求订阅。

一个更简单的方法是对通知提供非常精细的控制，包括它们的内容、格式、频率和请勿打扰时间。 我们可以提供一个选项来回复最近的通知，用“更少的电子邮件”或“停止”来更改频率，绕过网站登录或应用程序登录（Notion.so 就是这样做的）。 对于应用程序，提供集成到应用程序中的通知首选项，而不是依赖于操作系统原生设置。 在那里，您还可以解释用户对每种通知的期望，甚至可以举例说明它们的外观。

实际上，如果确实需要，许多用户会在这两个地方搜索通知设置，但是他们找到那个模糊设置的时间越长，他们就越没有耐心。 实际上，大多数用户会在他们对最近的通知感到沮丧或恼火时寻求一种关闭通知的方法。 这不是一种令人愉快的心态，作为一项服务，您可能不想不必要地扩展这种心态，而代价是让您的付费客户感到唠叨和困惑。

不过，不要忘记探索硬币的另一面。 当用户更有可能订阅通知时，识别用户旅程的各个部分； 例如，一旦在网上商店成功下订单，或已确认航班预订。 在这两种情况下，通知都可以帮助客户跟踪延误或及时取回登机牌。 这也是建议实时推送通知的好时机，这也意味着首先要征得客户的许可才能发送这些提醒。 这个话题值得单独讨论。

请求许可，谦虚的方式

有些网站很有特色，不是吗？ 自我放纵，内心不礼貌，也非常不讨人喜欢。 您有多少次偶然发现一个看似谦虚、朴实无华的页面，只是为了迎接一个奇妙的权限提示，请求向您发送通知？ 你还没有读过一个字，但它就在那里，已经在要求一个长期的承诺——坦率地说，这是一个相当具有侵略性的承诺。

就用户体验而言，在加载时显示权限提示可能是给人留下糟糕第一印象的最佳方式，而且在大多数情况下是不可逆转的错误。 从 2019 年 1 月开始，Chrome 更改了触发原生提示时显示的选项。 虽然用户可能可以关闭通知以便稍后对其做出反应，但现在他们必须选择是“接受”还是“阻止”通知。 后者会导致整个站点的 Web 通知被永久阻止，除非用户最终通过浏览器设置的荒野找到了访问权限。 难怪绝大多数用户会立即屏蔽此类提示，根本没有阅读其内容。

从策略上讲，最好仅在用户实际接受的可能性很高时才请求许可。 为此，我们需要向客户解释为什么我们实际上需要他们的许可，以及我们可以为他们提供什么价值作为回报。 在实践中，这种策略通常以“双重请求模式”的形式实施。 我们不是立即请求许可，而是先等待一定数量的参与：可能是几次页面访问、一些交互、在网站上花费的一定时间。 最终，我们可以强调用户可以订阅通知的事实以及通知的价值，或者我们需要他们的许可才能获得更准确、位置感知的搜索结果。 有时页面的上下文就足够了，例如当用户访问商店定位器页面时界面想要询问地理位置时。

在所有这些情况下，一个突出的号召性用语按钮会等待用户最愿意采取行动的那一刻。 如果用户选择点击按钮，我们可以假设他们可能会继续执行该操作。 因此，一旦单击，该按钮将提示实际的本机权限请求。

本质上，我们将权限提示分解为两个请求：

1. 内置在 UI 中的请求，
2. 浏览器级别的本机请求。

正如亚当林奇所说，如果用户仍然撤销权限，可能是由于在本地浏览器提示中误点击或误点击，我们需要显示一个后备页面，解释如何通过他们的浏览器设置手动启用权限（或链接到解释）。 显然，如果用户已经授予权限，则显示通知请求是没有意义的。 我们可以使用 Permissions API 通过单个异步接口查询任何权限的状态，并相应地调整 UI。

相同的策略可以应用于任何类型的权限请求，例如访问地理位置、相机、麦克风、蓝牙、MIDI、WebUSB 等。 不过，UI 通知提示的措辞和外观在这里至关重要，因此最好跟踪每个权限或功能的参与度和接受率，并据此采取行动。 这让我们成为了其中之王——跟踪通知的主要指标。

跟踪通知指标

通常，发送通知的目的并非纯粹是为了通知客户正在发生或即将发生的事件。 好的通知是有用且可操作的，可以帮助客户和企业实现他们的目标。 为此，必须首先发现和定义相关指标。

作为最低限度，我们可能首先需要知道我们发送的通知是否相关。

• 通知的措辞、格式和频率是否推动了我们想要实现的预期行动（无论是社交分享、在网站上花费的时间还是购买）？
• 什么样的通知比其他通知更重要？
• 通知是否真的将用户带回应用程序？
• 从发送通知到用户返回网站或应用程序需要多长时间？
• 在点击通知和用户离开网站之间平均花费多少时间？

针对不同级别的用户（初学者、普通用户和高级用户）尝试措辞、长度、发送时间以及通知的分组和频率。 例如，用户往往更容易接受那些感觉更随意而不像系统通知的对话消息。 提及其行为触发通知的实际人的姓名也可能很有用。

开始缓慢发送通知以跟踪其潜在的负面影响从来都不是一个坏主意——无论是选择退出还是应用程序卸载。 通过首先向一个小组发送一组通知，您仍然有机会“在为时已晚之前调整或取消任何有害的通知活动”，正如 Nick Babich 在“什么是好的通知”中所说的那样。

所有这些努力都有一个相同的目标：避免重大干扰并防止我们的客户感到疲劳，同时在他们需要知道的时间告知他们他们想知道的内容。 但是，如果 cookie 提示只是烦人，而频繁的通知只是一种干扰，那么当涉及到个人数据的安全性及其管理方式时，客户往往会有更紧迫的担忧。

值得注意的是，通知在 Android 和 iOS 上的请求、分组和显示方式存在显着差异，因此如果您正在设计原生或混合应用程序，则需要详细检查它们。 例如，在 iOS 上，用户在启动或稍后使用应用程序之前不会设置应用程序通知，而 Android 用户可以在安装期间选择退出通知，默认行为是选择加入。 PWA 发送的推送通知的行为类似于相应操作系统上的本机通知。

Admittedly, these issues will not be raised immediately, but as customers keep using an interface and contribute more and more personal data, doubts and concerns start appearing more frequently, especially if more people from their social circles are involved. Some of these issues are easy refinements, but others are substantial and often underestimated blockers.

In the final article of the series, we'll be looking into notifications UX and permission requests, and how we can design the experience around them better, with the user's privacy in mind.

• Part 1: Privacy Concerns And Privacy In Web Forms
• 第 2 部分：更好的 Cookie 同意体验
• Part 3: Better Notifications UX And Permission Requests
• 第 4 部分：隐私意识设计框架

Useful Resources And References

• “Designing Notifications For Apps,” Shashank Sahay
• “Different Types Of Notifications: Websites, Apps And Beyond,” Joanna Martin
• “It's Time For Notifications To Get Smart,” Alex Potrivaev
• “Improving User Experience With Real-Time Features,” Lauren Plews