前天《個保法》正式實施，明確規定了關於使用者資訊及敏感資料的處理規制，人們也逐漸意識到資料許可權的重要性。在未來的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協議