我可以給你發(fā)推送通知嗎？我可以查看你的通訊錄嗎？我可以知道你在哪里嗎？我可以看看你的照片嗎？
iOS用戶在初次使用一個App時，基本上都會遇到類似這樣的彈窗問候。由于iOS的沙盒機制，第三方App在調(diào)用數(shù)據(jù)這方面遭到了諸多限制，蘋果僅僅開放了部分接口（相冊，聯(lián)系人，地理位置等）供開發(fā)者使用。不僅如此，每一部分的數(shù)據(jù)接口都需要用戶允許才能取得調(diào)用權(quán)限。而這一步，恰恰是會影響到整個用戶體驗的關(guān)鍵因素。
但在體驗各種App的實際過程中，你會發(fā)現(xiàn)大部分開發(fā)者在這一關(guān)鍵細節(jié)上簡直是毫不用心。要知道，一旦用戶在看到彈窗時選擇了“不允許”，再要讓他們“反悔”幾乎沒有可能。因為要完成這一步，用戶需要另外做五步操作（如下圖）。

關(guān)于這個問題，Cluster的聯(lián)合創(chuàng)始人兼設(shè)計師Brenden Mulligan有非常具備參考價值的案例整理和思考。
他提到現(xiàn)有App最常用的兩種方式，也是Cluster最初版本使用的方式，其實并不高效：
用戶一打開App，就彈窗要求取得權(quán)限。這種情況下，用戶選擇允許的比例僅有30%到40%。
在要求權(quán)限之前“教育”用戶，告訴用戶為什么要這么做，能獲得什么好處。這種情況下，用戶選擇允許的比例為40%到66%。
但這顯然還不夠，任何一個公司都不愿意看到這么大的流失率。畢竟一旦用戶在系統(tǒng)層面不給予授權(quán)，他留在這個App的時間也就不久了。于是，Brenden Mulligan在這個細節(jié)上又做了三次調(diào)整，并成功將權(quán)限通過率提升到了相當(dāng)樂觀的水平。
他是怎么做到的？用他的話來說就是——情境很重要，彈窗應(yīng)該在用戶希望其出現(xiàn)的時候再出現(xiàn)，也就是“由用戶自行觸發(fā)彈窗”。他以Cluster在要求相冊、通訊錄、推送通知三大權(quán)限為例進行了闡述：
應(yīng)該什么時候要求相冊權(quán)限？Cluster選擇了在用戶進行“選取照片”這一步操作的時候，而非在此之前的任何一步操作。僅這個調(diào)整，權(quán)限通過率就從67%提升到了89%。

在要求通訊錄權(quán)限這一方面，Cluster選擇了“先讓用戶嘗點苦頭”。當(dāng)用戶發(fā)現(xiàn)他們幾乎無法搜索到朋友的時候，點選“顯示通訊錄好友”并允許通訊錄獲取權(quán)限的比例達到了100%。

而在要求推送通知之前，Cluster問了一個合情合理的問題：“是否希望在朋友加入時通知你？”這樣處理的結(jié)果與通訊錄權(quán)限類似，選擇了“通知我”的用戶都允許了Cluster推送通知。

盡管Cluster的這個案例可能并不適用于每個App，但Brenden Mulligan所提到的細節(jié)處理確實值得App開發(fā)者和設(shè)計師給予“額外關(guān)照”。畢竟用戶是App發(fā)展的基礎(chǔ)，體驗則是用戶留下來的保證。嘗試用“同理心”去處理好這些細節(jié)，事半功倍或許就不是一種妄想了。