请求授权的设计逻辑

获取授权于一款产品的本质是获得更多的触达、拉回用户以及体现产品魅力的可能性。请求授权已经不是一个简单的功能，而是对用户心理揣摩、全局产品思考的设计问题。...





获取授权于一款产品的本质是获得更多的触达、拉回用户以及体现产品魅力的可能性。请求授权已经不是一个简单的功能，而是对用户心理揣摩、全局产品思考的设计问题。

很早之前我们在周刊中聊过一次关于请求用户授权的设计，不过在关注点上更偏向于设计形式上的差异。

在之后的时间里陆陆续续遇到一些相关的问题，尤其是前段时间某位同学咨询的一个具体的案例，会让大家发现请求授权不仅仅是一个设计形式的问题。

同样，在我们今天 Design System 这个母命题下，请求授权的设计是一项为用户提供更好的使用体验以及连接用户的工作。

除了设计形式，我们还需要思考如何将它更好的融入到用户的使用中。所以这期的周刊我们将换一个角度来继续聊一聊请求授权的设计。

请求授权解决什么问题

相较于 PC 移动设备更加的随身，再加上各种传感设备的支持我们能创造出更多有趣的组合，也就造就了丰富多彩的移动应用程序市场。

我们在日常生活中很多重度使用的产品甚至都强依赖于摄像头、地理位置来提供更好的服务，这也就意味着如果缺少了这些功能的支持，使用体验将会大打折扣。

也正是由于移动应用程序市场的繁荣，对于用户获取的竞争也变得异常激烈。上次的周刊中我们曾提到过，移动互联网市场分析平台 Quettra 曾经有过一份数据：

大量的应用在用户安装 3 天后失去 80% 的活跃用户而 30 天内这个数字会增加到近 90% 。在这样的现状下 Push Notification 成为了拉回用户最为核心的手段之一。

不过这早已不是几年前的移动互联网时代了。用户对智能手机、移动应用程序越来越了解，一些开发厂商也越来越喜欢滥用用户给予的信任。

以至于大量的用户看到请求授权就会非常的谨慎，尽可能的避免隐私给暴露出去。

在这样的大背景下，请求授权已经不是一个简单的功能，而是对用户心理揣摩、全局产品思考的设计问题。

对于一款产品来说，本质是让有更多触达、拉回用户的机会以及体验产品整体魅力的可能性。

无论将来我们还会需要什么样的授权，请求授权本质只是一个功能和载体。而从设计上我们需要去思考如何更好的让用户认同、接受并给予我们授权。

请求授权的设计形式

基本上每当我们下载安装一个新的 app 都会遇到一系列的请求授权，比如网络访问、地理位置、相册访问、通讯录等。

这个环节并非所有人都会特别的去关注，从设计形式的角度来看，我们最常见的无非是以下几类。但实际上这里面有不少的细致活儿，接下来我们就来逐一讨论。



01. 即刻请求授权

打开应用时立刻请求授权，这是操作系统所提供的最基础解决方案。迄今为止依旧很多的产品会使用这种“粗暴”的方式来请求用户授权。

就算这其中有些产品具备一定的知名度，在这个情境下用户会更倾向于拒绝授权，至少最扰人的通知权限会选择拒绝。



02.强化获取授权原因

在如今用户对授权如此敏感的年代，使用这种方法来请求授权无疑是自己挖了一个大坑。因为一旦用户拒绝了授权，之后想要让用户再次开启是非常繁琐的。

所以在吃过亏之后，很多产品开始意识到需要认真对待授权这件事儿。于是开始从文案的解释和情感传递上去向用户解释，引导用户给予授权。



03.在 Onboarding 过程中请求授权

为了更好的展示产品特性，很多 app 都会为新下载的用户增加一个 Onboarding 功能。

相较于上面的这种形式，Onboarding 有更大的空间来介绍产品的特性，在当前情景中来进行授权请求也能提升用户的认同度。



04.在适当的场景下请求授权

当然我们也发现了一些更聪明的做法，不在一开始就一通弹框去请求授权，而是放在用户真正需要使用到它们的时候。

比如下面这块应用，在用户填写收件人信息时再来请求用户授权通讯录的访问。



相对于前面的几种做法它所出现的时间节点会更好。当用户输入一位联系人的信息时发现并没有结果，这个时候再来请求用户提供通讯录的授权，用户的意愿度也将远高于刚进入应用的时候。

到这里大家可能会有一些感觉了，请求授权的设计不仅仅在于那个弹框，文案、情景、时间节点都是影响其最终结果的重要因素。现在我们可以再来系统的理一理整个思路了。

请求授权的设计逻辑

Google 在 Material Design 中有一篇专门介绍授权设计的思考，这里面非常好的一点是将关注视角从请求授权的设计形式转移到授权信息本身上。从授权信息的重要度和用户理解度两个维度上结合起来考虑。



我们将图片里的信息翻译一下再展开详细分析。首先这里设计两个概念：决定性和清晰度。



决定性更偏向于产品的角度，也就是这些被授权的功能（比如地理位置、摄像头权限）是否是产品使用的核心，也就是如果没有这些权限是否这个产品就无法正常运作。

清晰度则更偏向于用户角度，为什么要获取这个权限用户是否有足够的认知，或者说是认同感。

拿女生们最爱用的美颜相机来举例，大家都很清楚它是用来拍照的，既然安装这款应用基本上也不会对摄像头授权的请求进行拒绝。

但对于很多平台型产品来说，这些授权可能并非核心功能所需，想要用户能够认同则需要给予更多的解释或教育。

Google 的这个象限图很好的诠释了授权设计的判断逻辑，不过在具体使用上并没有那么方便。所以在其基础上我重新绘制了一个流程图，帮助大家更好的进行选择。





以上是 Design System 系列的第 13 期的节选内容，在接下来的全文内容中（付费部分）我们将继续通过实际案例的分析来从设计形式，结合产品全局来进一步分分析授权的设计思路。

加入 PinDesign 会员，获取本期主题「请求授权的设计逻辑」的全文内容及本系列前 2 期周刊的赠送，年付会员将获得 Design System 系列所有（01~12）文章的赠送。

Design System 是 PinDesign 周刊的一个新系列，基于「Design Systems」的理念对产品的系统性设计的经验总结。希望将自己的感受和经验分享给大家，辅助大家的阅读。

Design System 系列已更新：

1. 什么是 Design Principles
2. 什么是 Design System
3. Components 与  Patterns 有什么区别
4. 你该为产品设计怎样的气质
5. Design System 中的 Design Token
6. Design Pattern 实例 - 用户通知与中断
7. Design Pattern  组合实例 - 列表页设计思考
8. Design Pattern 划分方式是对设计的逻辑思考
9. Design Pattern - 页面的信息展示逻辑
10. Design Pattern - 换个角度谈表单设计
11. 购物车的设计逻辑
12. 筛选与排序的设计逻辑

点击「阅读原文」了解会员计划

    关注 Pinapps