应用授权设计思考(上)

前天《个保法》正式实施，明确规定了关于用户信息及敏感数据的处理规制，人们也逐渐意识到数据权限的重要性。在未来的APP设计中，如何在兼顾数据安全和用户感受的前提下，更合理的设计授权，成为重要的关注点。本章将从平台权限的差异出发，结合授权形式，讨论一下应用授权的设计原则和方法。

请求授权的平台差异

权限差异

iOS把权限分为用户隐私权限和系统服务权限两种类型。用户隐私包括相机、麦克风、通讯录、语音、日历等；系统服务包括网络、通知、VPN等。以上两种权限都需要用户授权，才能启动服务。

Android把权限分为危险权限和普通权限两种类型。危险权限包括日历、相机、通讯录、定位、麦克风、短信、存储等九个权限组；普通权限则包括包括网络、通知等。危险权限需要用户授权，但普通权限无需用户授权，自动默认开启。

授权区别

1:辅助说明文本的自定义差别

在Android中所有的系统授权弹窗，都是不能添加辅助文字说明的，但在iOS中涉及到用户隐私的权限，在请求授权时都可以添加简单的自定义文本说明。

2:请求授权的频次

Android的系统授权弹窗可以请求多次，用户首次进入应用，如果没有给予授权的话，那么再次进入时，应用还会调用系统授权框询问让用户授权，除非手动勾选禁止（定制化系统除外）。

iOS系统授权弹窗始终只会出现一次，如用户不允许授权，则以后只能通过给用户提供设置路径，让用户自行打开权限开关。

综合以上内容，总结如下图，可以看出不同平台的常用权限是不同的，并且是否默认开启、请求频次也都有差异，设计过程中同样需要有意识的区别对待。

为什么要请求授权

有些权限能让APP的服务更加贴心。比如，天气应用的 Push Notification 推送可以在恶劣风暴来临之前，提前精准的预报给用户，方便用户出行。

而有些授权必须用户确认，应用才能正常运行。最典型的比如说数据权限，用户在使用应用之前，按照工信部要求在iOS10之后的系统，都会被询问 “是否允许使用移动数据”，一定程度上保护用户流量不会被无端消耗。

授权请求的设计形式

01-直接弹窗请求授权

这种简单粗暴的方式，在国内也最为常见，初次使用过程中不分场合差异，直接弹框索取权限。当用户不足够了解和信任这款产品，或者说尚还不清楚权限请求和产品核心功能的关系的时候，只会被当做干扰，直接拒绝。

02-功能列表集中授权

当用户第一次尝试在Periscope拍摄视频发布广播的时候，应用会把拍摄视频所需关联功能camera、microphone及location权限以列表请求的形式呈现给用户，鼓励用户一并授权。这样做虽无可厚非，但仍会给用户带来的很大的压力。

03-强化请求重要性

在粗暴授权这事被用户多次打脸之后，很多产品开始意识到更好劝导用户给予授权的重要性，所以在图形、文案和形式的使用上更加注重感性，强调开启后会正向给予用户收益或者拒绝后暗示用户会损失更多。

04-在 Onboarding 过程中请求授权

很多产品会在产品的Onboarding中嵌入需要授权指引，系统化的Onboarding区域展示内容更多更独立，授权理由的呈现也更充分。伴随着前置递进式的产品功能介绍，这类请求容易获取用户的理解并完成授权。

05-在适当场景下请求授权

相比较而言，场景化的授权选取的时间节点最好，请求更符合用户预期并且也与用户的操作行为息息相关，是在需要用户参与到授权中来的恰当给予。

比如Slack注册账号过程中建议用户添加好友一起共建项目，系统提供的邮箱、通讯录、共享链接都是相关的关系渠道。用户自然会想起社交关系中的通讯录朋友，此时提示用户开启通讯录权限，则显得水到渠成，比前面几类都要平顺的多。

因篇幅原因，这一部分我们主要讨论请求授权的平台差异和设计形式，更多有关授权设计原则和策略的部分请看下篇。

------------------------------------------

图片授权基于CC0协议