向用户征询iOS授权的五种常见设计模式

对于iOS app，当功能涉及到推送通知、访问照片或调用相机、获取地理位置等等时，都需要向用户申请授权。申请会发生在app运行的过程中，而不是像Android那样在安装的时候就莫名其妙的问用户是否同意app调用某些系统功能。不过如今Android也在向iOS的方式靠拢。

对于产品设计方而言，这里最大的问题在于，iOS只给你一次机会去征询授权 – 一旦那些缺乏耐心和理性的用户(多数用户)出于无论什么原因而拒绝授权，其结果就是要么无法使用关键功能，要么需要退出app去到系统的Settings里面重新设置授权然后再回到app。所以，怎样尽可能确保用户在初次使用产品时一次性通过授权？这是一个既有挑战性，同时又有点意思的话题。

我们归纳了市面上常见的五种设计模式，供大家根据自己产品的实际情况进行参考。

直接问，然后祈祷

很多app会在初次使用的过程中直接弹框索取权限。确实是最简单的实现方式，但被拒的可能性也最大(除了那些足够大牌到用户没理由不信任的产品)，用户如果决定重新授权，必须完整执行前面提到的设置流程，因为这个弹框是唯一一次决定的机会。

有些功能相对复杂的app更是会在初次加载的时候就执行一系列的授权申请，先是要求调用相机，然后问是否允许获取地理位置，最后还要让你授权接收消息通知。某些时候，这种简单粗暴的方式也确实可用，比如前面提到的，用户已经足够了解和信任这款产品的情况下。但对于多数产品，你不能做这样的假设；即便对于那些大牌，说到底也无法100%确保用户不会看走眼或习惯性的点击拒绝。

诱导用户

从本质上讲仍然是“直接问”的模式，但这类app会在询问时通过一些小技巧变着法的诱导用户点击“允许”。实现成本不会比第一种高出很多，但获取授权的几率会增大。看看Lyft的做法：

问两次，让用户有所准备

你也可以使用变通的方式在某种程度上突破“只能问一次”的局限，譬如在真正的系统对话框出现之前展示一个定制化的“假”的对话框。

如上图所示，左屏当中的对话框完全是定制化的UI元素，用户点击OK之后才会出现真正的iOS授权申请。这种方式有两点好处：

• 如果用户在“假”的申请中拒绝授权，那么你不会浪费掉唯一的那次“真”的系统授权机会，只需要关闭对话框即可；当用户将来再次需要用到相关功能时，你仍然可以通过这种方式征询授权。
• “假”的对话框在形式上可以自由发挥，譬如加入更多教学内容或引导元素。

两次提问的情境是可以根据实际情况进行控制的，例如Shazam这样，将第一次机会放在进入实际app之前，与引导页当中的内容整合起来。

等用户用到相关功能时再问

另一种更加情境化的常见模式就是等到用户实际用到与系统权限相关的功能时再征询授权，例如当用户点击“当前位置”按钮时，询问是否允许使用当前地理位置，或是当用户进入拍照界面时，询问是否允许调用系统相机。

这种模式的优点很明显，就是用户在实际功能情境中会对将要发生的事情更具预期，所以通过授权的可能性就更高。

推荐阅读“案例学习 – 引导用户授权app发送通知的实战技巧”一文，了解如何将模式3和模式4整合使用。

清单模式

如果app较为复杂，功能涉及到的系统授权较多，那么与一个接一个的弹框相比，清单模式更具积极的引导性。例如下图所示的Periscope所做的这样，将所需授权的信息以清单的形式展示出来，使其在感觉上像是某种正式的任务流程，用户每点击一个任务便会弹出一个授权申请，同意授权后，该任务完成。

如果用户拒绝授权？

无论怎样努力，用户还是有可能拒绝授权。这种情况下，一些app会简单的告诉用户怎样一步一步进入iOS的设置当中打开授权。

不过从iOS 8开始，app可以在自己的界面中提供deep-link将用户直接带去系统设置界面。下图演示的就是一旦用户拒绝在Shazam当中授权，他们仍可以点击“Go to Settings”按钮，一键进入系统设置，重新打开授权。

当然，这并不属于引导用户进行授权的模式，但相比于从前来说，至少算是不错的补救措施。

译文代表原作者观点。

本文来自Be For Web

译者：C7210

英文原文:https://medium.com/product-breakdown/5-ways-to-ask-users-for-ios-permi…