第一篇貼文決定貢獻出我的好同事 —P，他是我認識最文青的RD，UXD（體驗設計部）與軟體工程師工作上會常接觸，很多RD思維都是從他那討教的，幫助我成長許多。設計師與工程師能互相知道彼此領域多些，對於工作上銜接會更無縫。
以下是他辛苦撰寫的文章，感謝他的付出XD
出於懶惰，我們通常強迫使用者按下了那顆「允許」。
Android M之後對於權限(Permission)管理越趨嚴格，尤其要求開發者使用權限前先行通知使用者並且徵得同意(Runtime permissions)，藉以提升使用者關注應用程式安全議題。因此，使用者第一次執行新安裝的應用程式時，便有機會跳出各種權限要求對話框等待使用者允許或拒絕存取該權限。
工程師：「每次碰到使用權限就要跳對話窗，好麻煩！一次請求全部不就好了？不同意就無窮迴圈的跳出請求直到使用者「反安裝」按下「允許」才能開進主頁。」
使用者：「我明明是使用相機，為什麼除了存取相機權限外，還夾帶存取麥克風、GPS定位、撥打電話、聯絡人等等……的奇怪要求？」
上述是工程師或使用者常會碰到的情況：強迫使用者接受允許請求，或請求莫名其妙的權限。如果產品是一個大品牌(Goggle, Apple etc…)或是在商店上評分或下載次數夠高，你可以這樣強迫你的使用者，因為產品本身已經有足夠的信譽可以說服使用者按下允許。抑或產品具備獨特性、不可取代性，你也可以這樣強迫你的使用者，因為使用者找不到其他替代產品。如果都不是，使用者可能直接棄你而去。
說服使用者，而非強迫。
「強迫使用者做事情通常是爛主意，人們不喜歡被強迫，相反的，我們必須說服他們採取行動」 — — 取自《UX從新手開始,，Lesson 82》
既然強迫不可行，” 那我們就誘騙 ” 我們可以透過良好的UX說服使用者並建立使用者對我們產品的信賴。Google在Material.io網站上亦針對權限取得方式提出設計指南。
重要權限(Critical permission)：
通常為產品功能必備的權限，沒有它便不能正常執行，因此通常會在程式開啟時便向使用者提出請求。
- Ask up-front：使用者透過程式類型可預期所使用權限，不用輔以說明。
- Educate up-front：當產品具備歡迎頁面，除了簡介你的產品外，應加入關於權限請求的說明。
次要權限(Secondary permission)：
通常為產品附屬功能，即便無法取得相關權限，使用者僅是無法體驗該功能，而不影響產品核心體驗，因此通常會是使用者意圖想使用該功能時再進行請求即可。
- Ask in context：當某些特定功能使用者嘗試使用時，才進行權限請求。
- Educate in context：當功能被觸發時，輔以適當的上下文描述有助於使用者了解權限，提升取得權限的機率。
我們亦可以透過可用性思考上述劃分方式。權限請求可以有「單純」及「簡單」兩個面向進行思考。
單純：即較少的步驟，可對映重要性。所有權限都被歸類為重要，進行一次性的權限請求。優點是使用者之後不再需要處理權限問題，但缺點顯而易見：缺少彈性及說明。
簡單：即較容易理解，可對映清楚性。針對請求給予詳細說明，讓使用者理解權限請所為何事。缺點是，對於清楚的權限，使用者可能會覺得惱人，例如：相機請求相機權限還附上說明，明顯雞肋。
兩個面相各自有優缺點，因此通常需要彼此搭配，考慮適用的時機。Google透過兩個維度畫分四個象限。對於使用者而言：縱軸控制請求時機，分階段請求對應的權限，使產品逐步瓦解使用者的心防，也讓使用者感受到權限存取控制在己的安全感；透過橫軸，適當的時間點加入必要的說明，說服使用者。對於設計師而言：更容易分類權限請求及設計表達方式。
說服失敗！
使用者拒絕授權，意味前面步驟給予使用者UX環節可能出問題，間接導致使用者不願意或不信任給予相關權限，需要回頭檢討前半部哪個環節出問題。
當說服失敗時，同時需要提供相對補償動作，如：再次說明權限的用途或凸顯功能不可用。因此在流程圖上需要留有檢查點隨時確認權限狀態，狀態若不可用時則需要提供方式讓使用者可以允許。
拒絕的理由百百種，但Android只提供兩種方式拒絕：
- 使用者直接拒絕：若為此類可以等下次使用者使用再次跳出權限請求，或透過詳加說明再一次引導使用者進行核准。
- 已經被拒絕且選擇了不要再問我(Do no ask me again)：根據Android設計，此類通常無法再次跳出權限請求對話框，僅能透過詳加說明並引導使用者至設定(Settings)進行權限的核准。
上左圖為拒絕後的引導範例，透過sankebar (Snakebar 為Android 5.1+新增的Toast設計)提供描述並提供設定引導使用者允許該項權限。上右圖為重要權限被拒絕後，提供滿版說明為何需要這個權限，並引導使用者允許或離開應用程式。
安全就在眼前，但我們卻視而不見。
出於懶惰或經驗，使用者也會默默允許「允許」，縱使不安全。
「權限請求」是為了使用者資料安全而設計，Android將控制權還予使用者，由使用者決定是否信任該產品。或許使用者基於懶惰或先前體驗(跳太多詢問或強迫允許迴圈)，多數使用者已經養成隨意地按下「允許」，而非認真思考該權限賦予的意義，讓安全美意大打折扣。
希望透過這篇文章，可以讓設計師或工程師處理權限處理上可以有更多的想法，而不僅只是誘導使用者按下允許。同時間，良好設計也有助於使用者培養良好的安全檢視習慣。
使用者：哦～原來照相機要錄音權限是因為要錄影喔！ (Allow)
使用者：為什麼照相機要讀取我的聯絡人啦！ (Reject)
設計師 x 工程師。
這邊是寫給小菜菜的自己。
剛開始接觸Android專案的新手(設計師或工程師)，權限要求這部分很容易就被忽略了，因為它不屬於產品功能需求，而是系統層需求。初期會議討論自然不會帶到這一塊，不過一旦發現時需要更動時，可能事情就不適憨人想的那麼簡單。
此外，這個需求出現在Android M版本之後，如果你的產品涵蓋M之前版本(產品需要橫跨版本，是另外一個重要議題，因為不同版本間會有行為變化，需要及早定義)，產品安裝在M之前是不會跳出任何提示(當然你也可以替先前的版本加入適當的說明，提高信任度)，這是流程上需要考慮的地方。
對於設計師：產品需要使用哪些權限其實不清楚，因此設計流程時會遭遇一些困難，但如果有幸看到這篇拙作，你可以先行提醒工程師要求相關的資訊，或者可以先參考Materio IO上的權限分類表，先猜測可能的權限。
對於工程師：因為比較清楚，所以到最後也只有自己清楚 ” 反正UXD沒提麻 “，不過以健康的工作流程而言，當設計師不清楚時，請先提醒設計師，避免之後產生更多問題。另外請不要 ” 作弊 ” 把targetSdkVersion設定小於23，當產品被安裝到高於此版本時，仍以M之前的行為處理(不跳提示)。但Google Play政策正在緊收破碎及安全問題，2018下半年Google Play上targetSdk必須為26+(Android O)才可上架，總言之，該面對還是得面對。
建議兩方面在一開始就註記權限這塊需求，UXD先給定相關處理準則或UI樣板給工程師開發，工程師再回饋相關權限的完整清單給UXD設計。
參照你、我、他。
- Permission — Permission requests should be simple, transparent, and understandable
- UX從新手開始 — — 使用者體驗的100堂必修課, Joel Marsh(2017)，O’REILLY
