權限專案的設計心法
分享純檢視的文件、給新組員Sktech app的使用權、喔我主管不小心把我從設計師聊天群踢出去了耶？！
使用者權限在數位產品中其實無所不在，卻因為不直接與產品價值掛鉤，很常被忽略。這個邊緣人、角落生物到底要怎麼設計？
使用者權限很技術導向，不是資訊背景出生的設計師，又該怎麼辦呢？
在開始聊權限之前，我想先聊聊自己在相關專案工作過的心得。權限相關的專案準則和很多使用者或消費者任務導向專案不同，適用的設計原則也大不相同。和專注於重複使用率或任務效率的核心功能不同，權限管理專注是任務成功率和除錯率。安全第一很適合用來形容相關專案。
樸實無華且…
說到權限管理頁面，我腦中出現的就是一推表格、很多的可選框、一堆確認步驟以及老到不行的UI。權限設計雖然略顯枯燥（對不起，我說出真心話了），說白一點並不太過吸引人、也不會有人想時不時進去操作，最好快速便利完成工作離開，重點是不要出錯就好。
但就是這個木訥老實的頁面，承擔整個產品中的重責大任。因為這個不要出錯，下可讓機密文件外洩，上可讓公司失去願意花大把鈔票購買服務或產品的大客戶。
確認、確認、再確認
也因此，使用者權限和資安、隱私、收費等項目有著密切關聯，項目中時常需要與各部門進行確認與討論。和很多使用者主導的專案不同，權限設計專案偏向整合與呈現，設計的需求與產品成果一定要經過各個相關單位確認。
需求、易用性與美觀之間的平衡
這種專案基本需要資安面向審核，過關後，設計的重點很大一部分會在於歸內與統整各種條例項目。但同時，設計師的自由度與期望值偏小。雖然視覺呈現與介面互動方式設計師掌有自主權，但內容基本上以表格為主，期望時常是點到為止就好，再往上的每一分設計都是在六十分往上加。而功能或互動的天馬行空終歸需要回到現實，設計師在功能與訊息上受限於內部使用的權限管理模型，未必總是能達到使用者的理想流程。
設計加分題：商業模式與權限整合
上面屬於基本的設計工作內容，但設計師若想，也可以考慮超出專案範圍，將其視為一種挑戰。使用者權限很常和產品的商業模式掛鉤，因此設計師也能從整合產品收費方式角度切入來規劃權限。
最簡單的例子就是，數位產品時常有：免費版、進階版、商用版。依據收費高低，提供的服務與功能不同。團隊使用的合作型產品也常常會有不同使用者類型：（僅限）外部觀看(Viewer)、內部觀看(Viewer)、可編輯(Editor)、可創建或刪除(Manager)、可加入或移除團隊成員(Admin)。
權限可以從不同面向切入，層級也會因此有所不同。
工程術語眾多，我要先懂什麼？
在直接開始進行設計之前，不妨和團隊確認一下權限管理模型：角色取向權限控制Role Based Access Control (RBAC), 權限管理模式Access Control Model (ACM), 屬性取向權限控制Attribute-Based Access Control (ABAC)
這些術語初時讓我一個頭兩個大，直到今日我也無法切確說明其中差異，但他們的運作模式很大程度決定設計與資訊群組化的限制。
絕大多數公司在設計加入團隊之前，便已經由技術部門選定使用上述某一種模式。雖然UX某方面可以從彈性及易用性的角度參與討論，但基本上是由產品需求、維修方便性、安全性、隱私等等多方面評估。信任你的團隊吧！這種決策中UX 是次要的。
身為設計師其實不用太深入了解這些權限設定的細節，但必須了解其差異性以及控制項目上的限制。普遍而言，服務導向(SaaS)產品多為Role Based Access Control (RBAC)，如第一段落所示，可以很明確藉由角色 (Role) 來設定使用者購買的版本、其下能使用的功能，以及像是公司團隊的權限階級。
以Marvel 為例，角色分為：專案所有者 (Owner), 編輯 (Editor), 觀看者 (Viewer), 外部使用者 (External users)。各角色擁有的權限由上至下逐漸受限，只有線性的權限差異而沒有矩陣性的權限差異。Role Based Access Control (RBAC)的好處是能支援服務導向產品的商業模式，同時也更直覺、易用性更強。
以ClubHouse為例，使用者的商業模式皆相同，但同一個房間中有分成主持、發言者以及聽眾。這並沒有一個特別的權限設定頁面，而是按照當下的活動進行調整，比較有可能是透過Access Control Model (ACM)管理。（這邊純屬我個人推測，如果任何人知道實際內容，請不吝於發文更正。）
但如果是支援複數應用程式的平台、更為複雜的產品，Role Based Access Control (RBAC)無法支援細節，因此會轉向Attribute-Based Access Control (ABAC)。Attribute-Based Access Control (ABAC)基本上就是 “我讓你愛怎麼玩就怎麼玩，所有都能客製化喔！”。它的彈性造就產品與客戶需求的成長空間，只是相對會成為使用者體驗的惡夢，光是列出所有的權限細節讓管理者做選擇，心中就會產生：你要不要用.CSV表格更改後載入就好呀？這種想法。
設計重心與重點
實際設計過程，首先抓求穩設計師工作的重心，能讓你在讓人暈頭轉向的術語中站穩使用者需求的腳步！如上面提到的設計原則，基本上設計師最重要的工作有：
- 如何直覺地群組化權限。
- 確保使用的文字與訊息足夠不熟悉產品的操作者作出決定。
- 確保介面上的步驟流程不會過於複雜，一次能進行足夠多的操作。
這些內容都屬於核心使用者設計內容，尤其專精於資訊架構與研究分析。有趣的是，權限頁面很難藉由前期的使用者需求訪問來了解需求與使用目的，但需求與目的其實十分直覺，就是給權限、不要出錯。專案倒是很適合在設計產出後進行易用性測試，可以發現很多按鈕、群組或文案上的盲點。
這篇文章有點類似我幾次參與類似專案的心得總結。在設計師們期望能快速擺脫權限頁面設計的同時（還是只有我？），給予面對類似專案或即將參與專案的各位設計師朋友一點信心及方向。
喜歡我的文章內容，請給予我拍手鼓勵和肯定！讓我們更有動力持續更新新文章。
