ios 在正确的情境中向用户获取iOS权限

Cluster是我设计过的第一个iOS原生应用，整个历程让我学习到了很多在过去的Web设计当中不曾考虑过的东西。在Web世界中，你通常只需要创建页面让用户浏览或使用，而在iOS上，除了引导用户下载并使用你的应用以外，你时常需要向他们索取各方面的权限，例如获取地理位置，或是访问通讯录、相机、照片等等。

在设计Cluster的过程中，我们在很多细微却充满变数的交互环节里花了不少心思，以提升用户的满意度及信任感；其中“怎样向用户索取权限”就是我们关注的重点之一。

关于这一点，我们得出的结论可以概括为：

除非当前确实需要，否则不要向用户索取权限。
索取权限时要让用户明确的了解授权后的好处是什么。

一次性成功获取权限的重要性

对很多应用来说，无法成功获取权限便意味着整体功能和体验的大打折扣。例如LBS类的应用，如果在索取权限时遭到用户的拒绝，那么该应用基本等同于无用了。另外，如果消息推送在你的应用当中扮演着微妙而重要的作用，能使用户保持习惯性的使用，那么获取权限时的失败或许会导致用户的流失。

更坏的是，点击“不允许”是很轻松的，而要撤销这个决定则不太容易，用户至少需要以下五步才能打开授权，而且在应用内部很难为用户列出这些详细的步骤，更没法帮他们直接进入相关设置界面，用户只能靠自己去摸索。

1.退回到系统 2.进入设置 3.找到“隐私”设置项 4.进入“照片” 5.找到需要授权的应用并打开权限

换句话说，如果用户第一次拒绝了授权，使应用无法正常使用，那么应用自身几乎没可能向用户解释怎样修复这一问题。所以我们要尽最大努力确保第一次向用户索取访问权限时用户能点击“好”。

两种常见的设计模式

关于索取访问权限，我们通常会见到两种设计模式。

初次加载时即刻索取(不推荐)

大家应该都见过这种模式。你下载好一个应用，初次打开，界面当中立刻跳出一个提示：“我们可以给你推送消息吗？”然后又是一个提示：“我们可以访问你的相机吗？”接着又是一个“我们可以访问你的通讯录吗？”

除非用户很熟悉或信赖这款产品，否则他们更可能去点击“不允许”。这种方式和走在大街上随便拉一个人过来问“你能和我约会吗？”差不多。

我们在第一版的Cluster里使用了这种方法，结果只有不到40%的用户会同意授权。

让用户了解好处(次佳)

比起没头没脑的向用户索取权限，这种方式略好些，但有效性依然不高。

如上图所示，HeyDay应用在索取权限时会在提示框中对授权之后能得到的好处进行说明。而且，他们是在功能介绍的最后一步向用户索取权限的，这使得用户在决定是否授权之前就已经对应用的功能有了大致的了解(假设用户确实会阅读功能介绍)，从而更有可能通过授权。

我们的Cluster在采用了这种方式之后，一次性通过授权的用户量从40%提升到了66%的样子。

对于某些特定的应用，如果只能在以上两种方式当中进行选择，那么让用户在了解好处之后再决定是否授权，比单纯的提问要有效的多。

我们的探索

我们持续探索着Cluster向用户索取权限的方式，并找到了两种方法，使权限对话框尽可能的在用户想要说“好”的时候才出现。

预授权对话框

我们用到了一个小技巧，也就是在系统弹出授权对话框之前向用户展示我们自己创建的“预授权”对话框。

正像前面所说的，用户在系统层面拒绝对应用授权是很糟的状况，因为要重新打开授权是很麻烦的。不过如果我们在系统级授权对话框之前预先询问，那么即使被用户拒绝，我们也仍然有一次机会能让他们说“好”。

对于Cluster的照片访问授权来说，那些在“预授权”对话框里点击“不允许”的用户当中有46%会在接下来出现的系统级授权对话框中点击“好”。

实现方式比你想象的要简单。你可以增加一个额外的iOS系统对话框，或设计一个定制化的界面，来实现“预授权”。

1.iOS系统风格的预授权对话框

在较早的一个版本中，我们尝试了这种方式，也就是使用iOS系统风格的对话框询问用户两次；其中第一次的就是我们额外增加的“预授权”对话框：

预授权对话框(上图中间的界面)会在应用第一次需要访问照片时弹出，其中的说明文字是“这可以让你从相册中选择照片并添加到群里”；两个按钮分别是“现在不授权”和“给予授权”。如果用户点击“现在不授权”，应用并不会将这个行为认作系统级的“拒绝授权”，而是会在将来需要的时候进行二次询问，其中，我们进一步向用户解释：“Cluster只会上传和分享你所选中的照片”。

那些第一次匆匆忙忙拒绝授权的用户仍然有机会了解情况并改变决策；而根据统计，那些第一次点击了“给予授权”的用户当中只有3%会在第二次询问中点击“不允许”。

虽然这种双重确认的模式看上去有些烦人，但至少对我们来说是相对有效的方式，让我们仍有可能获得那些第一次拒绝了授权的用户。而且根据我们的测试，没有一个被测用户在看到第二个对话框时表现出犹豫或迷茫。

2.具有引导性的预授权浮层

在向用户索取通讯录访问权限的环节里，我们想给用户展示更多的说明信息，以确保更多的用户可以授权应用访问通讯录。这时系统的对话框就显得不够用了，另外灵活性也不足，于是我们设计了一个浮层：

用户决定邀请好友时，我们首先会通过这样一个浮层(如上图中间界面所示)给用户两个选择：一是从系统的通讯录中选择好友，一是手动输入对方的联系方式。我们让用户知道第一种方式更加便捷，但是需要授权；这能使用户尽可能充分的知情，对接下来将要发生的事情有所了解。那些选择了“使用通讯录”的用户在很大程度上已经是对情况有所了解并作出授权决定的，于是在接下来弹出的索取权限对话框中更有可能直接确认授权。

和前面一种方式类似，双重询问的模式感觉是有些麻烦，但在这种情况下，用户可以更多的知情，几乎没有人会点击“不允许”。而且那些一开始选择了手动输入联系方式的用户仍然有退路可以重新选择使用通讯录。

用户自己触发的权限对话框(最为成功的方式)

上面介绍的“预授权”模式，本质上讲，更多的是在减少用户不授权的可能；我们觉得这里依然有优化的空间。通过将问题进行解构，我们意识到，以上方式并没有改变“用户不期望被索取权限”的现实，所以我们继续探索，并尝试了一种让用户自己有意触发授权的方式。

访问照片

过去的版本中，在Cluster创建新空间的第一步就是添加照片。这就意味着用户点击“创建Cluster”之后立刻会看到获取访问照片权限的提示。当时的统计数据是，67%的用户会给予授权。我们认为这一数字仍有提升空间。

我们决定将上传照片的环节向后推迟几步，直到用户首先理解了Cluster推崇的概念到底是什么，能怎样玩儿，然后由他们自己主动产生尝试的欲望，并点击相机图标，接着是“选择照片”，此时再提出获取权限的请求。

这一改变使获取照片权限的通过率从67%上升至89%。

因为在这个时候，用户已经有意去上传照片了，给予应用访问照片的权限是再自然不过的事情了。

访问通讯录

我们曾经问过自己，如果用户同意应用访问他们的通讯录，那么他们能得到的最大的好处是什么？在曾经使用过的“预授权”模式当中，我们允许用户手动输入想要邀请的朋友的联系方式，并希望藉此来促使他们选择“使用通讯录”的方式，同时授权应用访问手机通讯录。这种方式的思路是对的，但问题在于，在用户进行选择之前，他们是无法感觉到手动模式的“痛苦”的，相应的也就难以看到授权访问通讯录的甜头。

最终，我们决定在添加朋友的环节中默认使用手动输入的模式，首先让用户尝到一点点“苦头”，让他们感受到在无法访问通讯录的情况下添加联系人有多空洞。当用户手动输入联系人名字的时候，会发现没有任何查询结果，同时看到“从iPhone通讯录中匹配结果”的选项。这时，用户便会更加主动的去点击这一选项；接下来，我们便向他们索取访问通讯录的权限。

这一改变使获取通讯录权限的通过率达到了100%。