今天要分享的是与麦克风权限相关功能的一些分析。
全文分为三部分：
应用获取麦克风权限的一些常见节点与形式
授权判断的节点与形式
竞品及场景分析
麦克风权限：
iOS操作系统中，应用权限有一项称为“麦克风”，顾名思义，就是应用使用手机硬件“麦克风”的权限，以满足录音或通话的需求，在Android中此权限也称为“录音”
笔者最近在做一款学前教育产品，其中有一个“实时指导孩子发音是否正确”的功能需要获取麦克风权限，看了一些竞品后说下我对于此权限的一些思考。
一、应用获取麦克风权限的一些常见节点与形式：
首次打开应用：在进入应用之前会显示系统自带的授权弹窗进行用户授权，有些重视用户体验的产品会先显示一个“权限及使用目的介绍”的弹窗，介绍在使用应用时需要用户授权的一些权限及将用这些权限满足哪些功能的正常运行。关闭弹窗后，弹出系统自带的授权弹窗。我理解只要是普通的存储、网络、麦克风权限可以直接显示系统授权弹窗，这个流程用户已经很熟悉，尽量减少用户在进入应用前点击次数的门槛。
到使用需要麦克风权限的功能节点：这么做的目的一方面减少用户进入应用前的门槛，还可以直接让用户明白，是这个功能需要用到麦克风权限，如果想用就会进行授权。但是这里有一点细节，就是需要限制在获取到权限后再开始应用进程，否则就会有这么一个现象，比如某录歌软件，用户点击开始录的时候，显示授权弹窗，结果用户还没有进行授权，录歌就开始了，导致再授权后还需要重头开始，增加了用户操作门槛。
一些有特定逻辑的节点：有些产品为了后置授权流程降低用户进入应用的门槛，会在进入一些二级页面并在使用需要权限的功能之前显示授权弹窗，这样的形式主要用在功能场景感比较强的产品上，再拿录歌这个产品举例，用户即将开始录制自己的作品，这个时候正好在酝酿录歌的状态，结果状态好了正要开始录，突然出现一个授权弹窗，是不是就受到干扰了，授权之后状态还得重新酝酿，这个场景可能会表现得用户太矫情了，但是如果将授权流程前置一点，在用户进入开始录歌的页面之前进行就会让体验更顺一点。
二、授权判断的节点及形式：
授权判断，就是判断用户是否授权
这一点我先说下Android与iOS的差异：
Android对于权限的状态分为三种：允许、询问、拒绝，允许就是已经授权，询问是在使用此权限时再次显示授权弹窗，如果是询问会在使用需要权限的功能时显示授权弹窗，拒绝就是未授权
iOS的权限状态只有两种：开启、关闭，但是如果没有显示过授权弹窗且用户未手动关闭时，会默认为使用功能时询问，其实逻辑上都有三种状态，但是在用户操作层面，Android用户可以在没想好之后要不要授权时手动设置某个权限为询问，更人性一点
在使用时两端在用户关闭权限后，除应用有特定的权限判断流程会再次引导用户进行权限设置外，功能都不能正常运行，所以，授权判断的流程很重要，在与人性博弈外直接关乎到产品体验
判断节点：从逻辑上讲主要分为两种，与上面说到授权的第2、3相同，一种是在使用功能时、一种是特定的功能使用的前置流程中，应该有一些产品也会在启动应用时，比如就只用麦克风的应用。
形式：涉及到产品能否正常运行且修改权限设置属于低频操作，所以形式上会比较强硬，正常流程都是未授权时显示提醒弹窗限制使用功能，提醒弹窗上显示需要授权文案和去设置/关闭按钮，如果不显示提醒弹窗，用户在全然不知产品状态的情况下使用了功能然后发现不好使，就开始骂“这特么什么垃圾产品”了
三、竞品及场景分析
举个小猴英语的例子：
小猴英语的授权弹窗是在首次启动，授权判断是在进入课程之前，已授权则开始播放课程内容，未授权显示权限提醒弹窗，不授权不得进入课程
基于这个流程我想到以下几个场景：
首次启动授权，常规授权流程，家长正常情况下一定是学前教育应用的首次启动者，首次启动时询问家长不会出现误操作导致产品不能正常运行的情况，而且在小猴英语这款产品中，进入应用后的每一个流程都影响着家长用户的付费转化，所以后置授权流程不合适
进入课程之前进行授权判断，小猴英语的课程是分为多个模块的，见下图，并不是每个模块都会用到麦克风权限，但是为什么要在进入模块之前呢，这样会不会有点太过强硬导致用户因为不授权就看不了都不用麦克风权限的模块？
小猴英语应用截图
不会
我理解应该是以下这几个原因：
1.小猴英语是一款重视在儿童兴趣中到达教学目的的产品，很多时候家长可能给打开课程就让孩子自己去看了，如果在学习中途显示授权弹窗很有可能导致孩子误操作
2.与上面说到在特定的节点中授权目的相同，不打扰孩子学习流程，虽然是多个模块，但是流程上都属于学习流程，学前教育阶段的孩子很容易受到其他事物的影响而分心
所以，一切都是为了最好的用户体验。
网友评论