作為一位合格的互動設計師，需要在理性和感性的結合下完成工作。既要有理性地抽絲剝繭，提煉總結的能力；又要有貼近用戶關注情感的細膩。
新人設計師可能都會遇到這樣的問題：在設計一個複雜需求的時候，各種場景、可能性在腦中來回亂竄，常常覺得邏輯不夠嚴密。設計完成後，又被各路人質疑，提出各種異常場景，導致頻繁修改，縫縫補補。最終可能會出現兩種不好的結果：
只做了部分場景，很多異常場景沒考慮到，最終因為細節的不完整導致整個設計不可用。什麼功能都做了，用戶依然不滿意，表示找不到想要的功能。本文就以「企業內部權限分配平臺」的需求為案例，整理了之前處理複雜需求的一些思路。來講講在互動設計的過程中，如何避免以上兩種情況，讓我們的工作更好地服務用戶，體現價值。
一、理解需求
首先，我想任何設計師在設計產品的時候第一步都是理解需求，這包括了需求的目標背景、角色場景、產品邏輯等，不同的需求的側重點會不同。以「企業內部權限分配平臺」的需求為例，目標背景和角色都比較簡單，但是一般涉及權限的產品，背後的邏輯就會很複雜，場景情況也很多。
和產品溝通，和用戶溝通，甚至網上找資料，都是理解需求的一些好方法。比如本次設計的需求是關於權限分配，這一篇《角色權限設計的100種解法》，就很好地幫助我理解權限分配背後的設計邏輯。
包括理解需求內的專有名詞，為其建立特殊的標識樣式，也是幫助自己、團隊、用戶更好地理解產品需求的一種方式。
名詞解釋
二、需求結構化
我是一個沒有感情的邏輯設計師
我們在最初思考需求的時候，肯定會從場景/問題出發，想著怎麼去解決這個問題，是以「人」的思維來思考這個問題的，這是必然的，也是正確的。但此時我們的思維是散點式的，例如當我們想到權限分配的需求時，可能會說：「這次我們要新增一個「崗位」的概念，讓權限和崗位綁定，不要和人綁定」，「對了，還有人員離職這個問題困擾業務很久了，我們這次要在人員離職的時候xxxxxx」。
所以，在最初的需求框架確定後，我得到的是這樣兩段文字：
看上去已經非常全面了，但由於我們是散點式地收集需求，很多時候可能還是會遺漏，或者說錯誤關聯了內在邏輯，導致一些邏輯衝突、漏洞。
此時，我們需要將我們的思維從「散點式收集」轉為「結構化梳理」。從需求說明裡抽絲剝繭，我們可以得到：
用戶角色有三類：超級管理員、業務管理員、HR。操作對象是：部門、崗位、人員、權限包。可執行的操作包括傳統的：增、刪、改、查，還有和本次業務相關的「關聯」，即權限的賦予。
各個對象之間的關係又是怎樣呢？我們把所有的對象兩兩組合，再把沒有關係的刪掉。
也就是：
在部門可以下設立崗位，崗位必須從屬部門人員必須從屬某一部門人員必須從屬某一崗位權限包可以賦予給部門權限包可以賦予給崗位人員和權限包沒有任何直接關聯，這也是本次權限分配的核心這個具體的業務邏輯並不重要，不需要去費心理解，重要的是這樣一種結構化思考的方法，可以應用在後續各種各種的設計中。
對象間的關聯，再和我們剛才梳理的人物、操作相結合，就可以還原成一系列的需求描述：[角色]可以在[A對象]下[操作][B對象]，例如：超級管理員可以在部門下新增崗位。
至此，我們已經可以建立【需求→功能對應表】
其中，紅色部分都是在之前散點式的需求羅列中沒有考慮到的功能點，通過結構化的梳理，我們可以提前把它們都一一補全。
這個過程可以減少我們最小顆粒功能點的遺漏，避免在做完大部分設計後，突然發現遺漏了xx功能，任務時間點又已經到了，慌慌忙忙地加功能，就可能會影響整體的設計思路和框架。
三、設計的減法：只考慮主流程
完成了功能點的整理歸納後，就可以開始我們的界面設計啦！在最初的界面設計中，這三點需要做減法：
優先進行框架設計，不要在一開始就考慮細節。優先完成主流程，再考慮異常場景。按照功能對應表將各個模塊獨立設計完成，再添加快捷操作。當然，可以先把可能存在的異常、細節都記錄下來，以便後續補充。
比如，在人員權限分配的界面結構中，分為三個大模塊：
在有了界面框架和功能對應表後，我們做設計會變得比較簡單，按照之前整理的【需求→功能對應表】，把每個小顆粒的功能細節填充到界面框架內即可。
四、設計的加法：回歸場景，考慮細節
當主流程設計完畢之後，我們就要開始做加法了。在之前，我們一直是用一種純理性的視角來完成我們的設計，保持純理性的設計會有兩個問題：
很多業務場景靠邏輯思維是無法想像的，必須設身處地站在用戶去思考，才能理解場景，進而補充可能的體驗細節。純理性的設計，可能在功能點上是完整的，但在用戶體驗上是缺失的。例如，純從邏輯思維角度你能想到在一個企業裡有人是沒有任何部門歸屬的嗎？然而現實中就存在這樣的情況：外包人員。
不結合實際場景，我們也不知道用戶一天需要處理多少次重複操作，目前的設計對他是否足夠便捷。
作為一個企業內部權限分配平臺，我們可以把部、崗位、人員等對象作為初始線索，站在不同的用戶使用角度，沿著線索去全面地思考場景，修改功能。有一些實在難以理解的業務，找用戶聊聊也是一個好方法。
我們可以很快地找到下面這些特殊場景：
1. 人員變動
新增人員流程：找到新加入部門→找到崗位→添加人，由於企業內部還有一個最基礎的OA系統，那麼HR是否會需要重複操作，一個人員在不同平臺添加兩次？這是否增加了他的工作成本？
人員變動頻繁，是否容易遺忘？
處理方法：行政架構自動同步，紅點待辦。
我們與OA系統數據打通，自動形成四類待辦紅點：
人員新增；人員離職；行政部門新增；行政部門刪除。這樣HR就不需要重複做新人員的添加操作，只需要業務管理員把OA內無法覆蓋的人員崗位設定好就可以，也不會出現遺漏的情況。
2. 高管兼職
例如某位高管：本身為A部門負責人，臨時兼任B部門負責人，那麼當他不再負責B部門時，該如何處理他的崗位？離職？轉崗？似乎都不合適。
處理方法：新增崗位移除功能。
3. 外包人員
了解到現實情況中，外包人員是沒有部門歸屬的，但是實際上他們肯定也有自己負責的業務範圍和崗位，在初始化時如何安置沒有部門的人？
處理方法：新增一個部門，叫做「無崗位人員」，並且標紅作為待辦，提醒操作者去處理這些「無崗位人員」。
4. 人員離職/轉崗
在進行功能設計整合時，我考慮是否「人員離職」應該叫「人員刪除」更系統化？是否可以直接整合為一個「人員編輯」的功能，將離職、轉崗的操作合併？（實際上這2個功能操作起來確實比較相似）
處理方法：最終我依然保留了「人員離職」、「人員轉崗」的功能，因為這樣更場景化，用戶清晰地知道自己當前該操作什麼。
目前對一個人進行離職操作的路徑是：找到原部門→找到崗位→找到人→處理離職。
而我們的企業有2500+員工，對於離職操作者HR來說，這個路徑是否現實？是否快捷？
處理方法：新增搜索功能，直接搜索人名→處理離職，這個功能也方便了其他找人的場景。
4. 其他
諸如此類的考慮還有很多，例如新建部門的時候是否會有空部門，在企業進行組織架構重組時是否會有大批量的人員、組織變動，進而需要有批量操作，等等。找到最初的線索，站在用戶的角度沿著線索思考，進行全局掃描，就會發現很多需要做加法的地方，發現的方式可以是觀察、訪談、思考，任何方式。
在已經保證了主流程的簡潔、清晰後，再用全局掃描的方式去搜集特殊場景，給我們的設計做加法，可以保證我們整體的設計框架是清晰可用的，而特殊場景是散落在骨幹上的各種小分支。
如果我們可以做到，對所有的主幹場景、分支場景瞭然於心，並且有自己的優先級考慮，那麼對於項目成員、用戶提出的質疑，我們也有足夠的理由來證明自己設計的合理性。
當然，場景基本考慮全面後，還有最後一步，就是統一交互、完善細節，這一步也是設計上的加法。
五、總結
以上，就是一個針對案例，總結來說有四個大步驟：
從實際場景出發，發現問題，理解需求；需求結構化：把本源的場景、需求結構化成功能對應表；設計的減法：先解決最根本的問題；設計的加法：回歸場景，全面考慮。所以，互動設計師是需要理性和感性的結合，要有完全理性抽絲剝繭，提煉總結的能力，也要有貼近用戶關注情感的細膩。把自己的工作規範化，減少無效付出，也是我們的一種能力，希望本篇文章對新人設計師有一些幫助，也歡迎大家一起探討交流。
作者：傅文娟，網易UEDC互動設計師，曾負責直播、閱讀等C端產品的互動設計，近年來開始轉戰企業級B端產品設計。
本文來源於人人都是產品經理合作媒體@網易UEDC，作者@傅文娟
題圖來自Unsplash，基於CC0協議