你知道吗？平均每个应用在安装3天内就会流失80%的活跃用户。多数人下载一个应用，打开一次，然后就卸载了。这是因为用户尝试许多应用，在接下来几天内决定要卸载其中哪些。
是应用品质低劣导致用户这样的行为吗？不尽然，但一款应用的首次交互，在树立整体印象方面扮演重要角色（无论印象好与坏）。用户打开一款新应用时，最不想看到的，就是一大串弹框请求获取权限。
这种操作在用户体验上会造成极其负面的影响，往往导致应用被抛弃。应用要在索要权限之前与用户沟通，这样才能使用户保持投入。本文可以帮助你避开索取权限时的常见陷阱，让你步入正轨。
说到请求权限，最糟糕的就是在没有任何通知与解释的情况下，用权限请求对用户狂轰滥炸。过早或者一次获取太多权限是常见的错误。然而，许多应用仍然如此——成为了用户打开应用首先看到的东西。例如，Gmail的Inbox甚至在引导页之前就开始索取权限，没有任何信息和上下文说明。
图片来源：Gmail的Inbox
发送权限请求时，你当然希望所有用户都接受。要达成这个目的，就应当建立一套权限策略。权限策略取决于你所请求的权限类型的明确与重要程度。非常重要的权限应当预先请求，次要权限可以在情景中再请求。
权限请求模式。图片来源：Material Design
确定用户是否接受请求的最关键因素，是它们何时需要用到。
简单的原则：除非需要，否则不要请求获取权限。
对许多应用而言，获取不到数据权限会改变整个用户体验。例如，如果应用需要依赖短信服务，拒绝这项权限就导致这款应用无法使用。所幸，用户会希望消息类应用获取短信权限，所以把它前置是有意义的。
图片来源：Google环聊
如果某个功能的运转需要获取多个权限，只请求相应权限，不要过头。
总结：确保用户清晰理解应用是做什么的（基于应用的描述或之前的熟悉经历），只预先请求用户希望应用获取的权限。
通常情况下，如果新用户一上来就体验到一连串权限请求，你就错失了一个吸引用户的重要机会。应用要在情景中请求权限，并且告知用户这项权限能提供什么。因为只要用户被吸引，他们就更容易接受请求。
图片来源：thinkwithgoogle
总结：在进行相关任务时请求获取权限，用户更容易接受。
应用应该清晰阐明为何需要每项权限，要提供功能的名称或详细解释。记住，如果想要用户同意，就要礼貌地请求。
简单的原则：清晰无疑说明用户将会获得什么，以此换取他们的允许。
对于不太明确的权限，需要教导用户这项权限包含什么。如果你的应用有引导页，可以用它来解释应用的功能，还有为何会出现意料之外的权限请求。
图片来源：Material Design
在情境中对权限做出解释，也是个很好的例子——它有助于增长用户兴趣，加深用户对于此权限的理解。向用户解释允许这项权限会带来的好处。
图片来源：Google地图
可以在请求之前提供一张背景图，对权限请求做出解释。Foursquare就用了一张背景图来解释为何应用需要这项特殊权限。
图片来源：Foursquare
iOS的默认请求，每个功能只能触发一次。最坏的情况就是用户拒绝了系统权限，因为在iOS中要找回那个权限非常复杂。多数情况下，最好是“预先”请求用户允许，然后在放出真实的iOS权限获取提示。
Cluster就是个预先请求的例子。Cluster的流程中包含了一个情景创建界面、一个预先请求、然后才是最终的权限请求。使用预先请求对话框，几乎彻底解决了Cluster的“不允许”问题。
“预先请求”是一种预先的教育型权限对话框。图片来源：Cluster
用户触发的对话框甚至比情景创建界面更有效，因为用户盼着请求出现，更愿意允许权限获取，他们想要使用这个功能。等到需要某个功能时再请求权限。例如当用户点按Cluster中的相机时，才会触发相机的权限。
在用户尝试使用这项功能时，才提醒用户允许权限。图片来源：Cluster
由于拒绝权限可能会导致某个功能无法按照预期使用，当权限被拒绝时，应当向用户做出解释。
简单的原则：当权限被拒绝时应当提供反馈。
如果由于关键权限被拒绝，导致应用无法运行，要解释这项权限为何需要，提供一个链接打开设置界面，然用户开启它。
下面的例子是Google环聊界面，解释了应用正常运转所需的权限。
图片来源：Google环聊
显然，每个应用各不相同，但你应该思考用户何时需要获取手机各部分的数据，并且确保他们希望得到征询。用户体验的改善是不间断的。不要错失用户允许权限的良机！测试每种情况，验证哪种最适合你。
非常感谢！
译文链接：http://colachan.com/post/3506
原文链接：http://babich.biz/mobile-ux-design-the-right-ways-to-ask-users-for-permissions/
作者信息：
Nick Babich
