最近接手了一個之前由同事小C在做的項目，是我司服務官網首頁改版的後臺頁面設計，說只要出一下視覺稿即可。我心想後臺頁面結構較簡單、模塊可複用，有現成的交互稿的情況下三四天肯定能搞定。出乎意料的是，全部做完花了十幾天，總共80多個web頁面，關鍵是交互工作基本上重新做了一遍。
這其中必定是有較大的工作習慣與方法的差異，以下就是我對本次工作的回顧，無關對錯，只是自己對交互設計的一點個人見解。
先上其中一頁交互稿：
如上圖所示，如果是以用戶視角，應該基本可以理解這個頁面的基本功能、頁面跳轉等情況了。但交互稿的使用者不是用戶，不能進行籠統地概括，而應在顧全大局的前提下做好最細緻的工作，讓我們的下游工作夥伴（視覺、前後端、測試等）能清晰地理解業務規則、界面元素，可以順利地進行他們的工作、減少溝通成本，從而提升工作效率助力項目順利上線。
以下是我認爲這份交互稿存在的幾個問題：
1）職責未盡
如圖1所示，列表顯示規則、保存反饋提示等信息，都是基本的數據展示與操作反饋，也都關切到產品的用戶體驗，這些信息由我們交互設計師來定義和提供會更合適。同時也讓下游夥伴不用再浪費時間精力去諮詢產品同學了，減少了溝通成本提高了工作效率。同時，如果我們能把每個細節思考清楚、主動承擔起一些貌似應該是產品做的工作，那設計師在團隊中的作用會越來越大，能得到大家更多的認可。
2）交互說明不足
如圖2所示，各表單項的填寫與校驗規則不夠細緻，如果我是前端工程師會有如下疑問：
1）產品名稱：是必填項，那爲空時怎麼提示？不能重複，那重複時怎麼提示？
2）產品圖標：有格式及文件大小的要求，如果用戶上傳不符合要求的文件怎麼辦？
3）是否需要登錄、是否爲諾諾產品：是下拉單選還是多選？有幾個選項？如果只有是或否兩個選項的話，把選項直接平鋪出來不是更方便選擇嗎？另外有沒有默認選中某一項呢？
...
我們所設計的界面都是需要前端工程師用一行一行代碼還原出來的，有些字段的校驗（比如上方的產品名稱不能重複）還需要後端提供接口一起配合校驗，所以實際開發過程中他們思考的會比我們仔細、碰到的問題也更多。如果我們的設計稿沒有考慮仔細，就勢必會增加後期的溝通成本，不利於團隊協作，同時也會降低我們設計師自己的專業性。
3）虛增實體
奧卡姆剃刀原理“如無必要，勿增實體”，在交互設計領域很適用，尤其是2B注重效率的後臺產品。我們要保證每個出現的元素、頁面都是合理的，是有助於用戶完成任務的。如圖3所示，一個產品的信息已經在表格中可以完整展示了，沒有必要再設計一個“查看頁”（如圖4），增加了下游的工作量外，對用戶來講也是一個視覺負擔。
4）頁面形式缺乏考慮
彈窗有結構簡單、減少頁面跳轉等好處，但是當表單項較多時，使用彈窗的形式會有很多兼容性問題，特別是一些小屏電腦上，用戶操作時的視野會受限，不利於把控整體的填寫進度。可以考慮新開一個頁面，使用麪包屑導航指示當前所處位置。
5）操作行爲的可用性不足
如圖5所示，「刪除」是可以批量操作的，但「查看」和「編輯」操作只能針對單條數據進行，每次想要查看或編輯時，需要選中一條數據後再將鼠標移至頁面頂部點擊這兩個按鈕，可用性會大打折扣，所以放置的位置還需要斟酌一下。建議放在每條數據的最後面，直接點擊按鈕進行這條數據的操作。
以上簡單說了我認爲有優化空間的幾點，總之我們最後交付的設計稿，應該是一份可用性高、滿足業務需求和用戶需求的產出物，還能讓我們的工作夥伴順利進行他們的工作。
下圖是我以自己的工作習慣和方法重做的設計稿（交互+視覺）：
結語：交互設計師所需要涉獵的知識領域很廣，大到心理學、人體工程學，小到需要考慮操作反饋、字段命名，還要對技術實現方法有所瞭解，這個過程中需要我們勤于思考、虛心學習，多積累工作經驗。以下是個人經驗認爲一份靠譜的交互稿至少需要具備的幾點：
1）高可用性：交互設計作爲承接上下游的關鍵一環，需要分析業務需求找到合理的解決方案 ，同時要兼顧用戶體驗，保證產品的可用性。如果不去思考，只是把產品的PRD複製過來修飾補充一下，其實是遠遠不夠的。
2）清晰的結構：給頁面加上有規則的序號、準確的標題，能使設計稿井然有序、引導使用者查看。至於是否需要線條箭頭來指示頁面流程要看具體元素、頁面的所屬關係，一些特別的分支流程是很有必要的，但大多時候也不用爲了使用而使用，縱橫交錯的線條其實也是視覺噪音。
3）考慮周到：對於一些特殊情況，比如字段長度超出如何展示、異常情況的處理等，我們都需要去考慮。這個需要平時積累經驗，也可以多做流程圖繪製的練習，對一個流程進行不斷的是否追問，是會怎樣，否又如何提示，直到將整個流程都走完基本就不會有遺漏了。
4）詳盡的交互說明：對於出現在頁面上的元素、字段，除了一些容易理解而且是寫死的（比如表頭標題）、以及和團隊成員達成一致的內容，其他的我們儘量標註交互說明，越詳盡越好。
——以上
謝謝閱讀，歡迎一起探討：）