編者按：本文從啟蒙、基礎、強化、進階4個方面，列舉了UI設計師學習交互的路徑和方法。

交互自學干貨：

一、為什么 UI 設計師要懂交互？

近幾年的互聯網市場，有不少公司提出了“全鏈路設計師”、“用戶體驗設計師”的說法，合并交互與 UI 崗，一時間眾說紛紜：有人說是高要求，有人則說這是一場變相的“人力壓縮”。

其實，設計師作為一個高度復合型的崗位，雖有 UI、交互、產品設計等細分，但無論是哪個細分崗位，都需要對業務、場景、用戶、技術實現有所掌握，才能給出最佳的設計方案。高度競爭的市場環境下，單純的“美化產品原型稿”，早已喪失了獲得高回報工作的可能性。

因此，才會對設計師的要求越來越趨于綜合化。放眼如今的 UI 設計師招聘描述：用戶體驗、交互可行性、數據分析……這些曾屬于交互設計師的職責，已普遍的出現在UI設計師的必備技能中。

至此，我們可以危言聳聽地說一句：“單一的 UI 設計已經逐漸滿足不了互聯網市場的需求”；但也正因為如此，我們才要豐富起自己的武器庫，去創作更大的價值……

二、UI 設計師該如何學習交互呢？

1. 啟蒙篇：站在用戶的角度上思考問題

筆者曾經也是一位 UI 設計師，在工作中由于項目從 C 端逐漸偏向 B 端，工作重心也就需要從視覺傾向于產品邏輯、交互體驗上了。崗位名稱從“UI 設計師”到“用戶體驗設計師”再到“交互設計師”。

這其中最大的轉變就是：將自己從“站在畫面美觀的角度上”思考問題，轉變為“站在用戶的角度上”去思考問題（也許我之前是個不懂設計的美工）。

舉個簡單的例子，之前做一個叉車工使用的 PDA 把槍界面：

現場實施人員給我帶來一個小需求，為避免叉車工在操作的時候誤觸，需要把底部的操作按鈕向上移；

我在上移了 16px 之后依然被要求不夠，“繼續上移，再上移！”

站在設計規范的角度上，我與實施人員幾番 battle 之下……他發給我一張現場叉車工人的手的照片，我這才明白這么做的理由：

長期的重活導致他們的手骨節粗大；再加上在搬貨途中使用 PDA 的抖動性增強，使他們的操作誤區比普通人大了許多。

在了解用戶與場景之后，再看向那個 PDA 界面操作按鈕下大片的空白，瞬間顯得合理了……

2. 基礎篇：如何畫出合理的界面？

首先，筆者建議大家可以結合自身項目，從基礎層面開始學習，由小至大、由簡入繁。

一來，是因為項目流程中原本崗位配合本就嚴絲合縫，要么是已有交互、要么是產品經理產出交互原型稿，可能并不會給你很大的試錯空間；

二來，則是因為各位分析過大場景的能力可能不足，直接上手反倒容易短期內沒有產出，影響學習的情緒……

基礎內容主要包括三個部分：工具、控件、設計原則

① 工具

這里會有很多 UI 童鞋問的一個問題就是：我需要學習 Axure 軟件嗎？

個人建議：Axure 可以但沒必要, 反正我現在沒用到。各位既然能夠畫出精美的高保真效果圖，那么低保真的交互稿還畫不出來嗎？

工具如何并不重要，如今用 Sketch、Figma 畫原型的交互設計師很多，而且這樣更方便與視覺同學之間的產出物轉化。

所以大家倒不必將過多的時間精力放在軟件上，別讓軟件成為學習路上的第一個攔路虎。

② 控件

IOS、Android、MacOS、Windows 各端、各平臺的設計規范&控件是設計的基礎，無論你是 UI 還是交互，都應該熟練使用各個平臺、系統的組件使用場景。

只是 UI 與交互的側重點可能不一樣, 很多 UI 設計師過分注重組件的樣式，而忽略了它們的用戶使用場景。所以組件究竟該如何學習？

a. 熟記組件的使用場景

這個組件在什么情況下會用到？只有熟記使用場景，才能在需求到手時，快速實現功能。

這些內容在各組件共享平臺的使用指南中都有詳細介紹，以 element 為例：基礎用法、相似組件區別都有標明（如下圖）。

b. 各端組件不要混用

不同端的同種功能組件會有很大的操作區別，比如：濫用移動端與 PC 端之間的組件，就會影響到用戶的體驗。

以加載方式為例：web 端常見的分頁加載就不適合出現在移動端，移動端主打的輕量化操作體驗，多以滾動&點擊的方式觸發加載。

③ 設計原則

如何畫出一張合理的界面布局？那么你一定離不開交互設計的七大定律。

對于交互設計七大定律，想必大家多多少少都有了解：格式塔原理、7±2 法則、席克定律、費茨定律、奧卡姆剃刀原理、復雜性守恒定律等。

以上定律的詳細定義，筆者在此就不一一摘抄了，想要知道的童鞋可以上網搜一搜。下面我具體只講我是如何學習這些定律的，那就是：多看案例！看得多了，自然就會用了。

以費茨定律舉例：

帶入這個定律去看下面的實際方案：

詳情頁面“返回”按鈕究竟擺在哪里，比較合適呢？

我們選取了幾個 App 詳情頁面的查看，最常見的兩個樣式，左上角 VS 左下角，那么哪個方案操作更便捷呢？

帶入用戶手指操作的場景，如果是雙手操作，那么兩個方案區別不大；但如果是單手操作，通過單手拇指觸屏的操作熱力圖來看，左上角的返回按鈕屬于“難觸及區域”，而左下角則是“操作便捷區域”，帶入費茨定律，我們就能得出左下角的返回按鈕操作更快捷！

溫馨提示：

其實這些交互的定律就如同我們 UI 的設計規則一樣，可以在做設計的時候去參考，卻不能照本宣科，脫離實際場景。以免出現筆者前文中“一味追求規范，而忽略用戶痛點”的教訓。

3. 強化篇：如何做出好用的功能？

一個好用功能的前提，得是一個能用的功能。所以我們要先讓流程閉環，功能跑起來；然后再做優化，逐步完善……

① 先做出一個能用的功能：流程閉環

我們在做每一個版本需求時，產品經理都會給到一條功能的業務流程，而這條業務流程是沒有辦法直接轉化成頁面的。設計師們需要將“業務流程”轉化為“用戶操作步驟”，再轉化為“界面”。

舉一個最經典的審批流程的例子：

業務流程大家都很熟悉：發起-審批-結束；其中包括了兩類用戶：發起人&審批人。以發起人為例，向下拆分他的用戶操作步驟；再從操作步驟中推導出界面（如下圖）：

② 讓功能變的好用：深挖用戶場景

當閉環的操作流程已經搭建完成，我們就需要考慮，如何讓它變得更加好用了。

這一環節我們需要深度挖掘用戶場景：弄清楚“誰？在什么情況下？要做什么？”，然后與用戶共情，帶入場景去思考問題……

繼續以發起審批為例：

在這一過程中，審批發起人（用戶）+在提交了審批之后（場景）+想要知道審批的結果（目標）。

帶入用戶的角度，去思考這個場景下，他們的心理活動，他們會有什么想法？再以此為需求，逐步完善我們的功能：

這里可能又有童鞋發問了：我沒有這么強的共情能力，想不到這么多用戶的可能性怎么辦？

那么，交互設計師的核心技巧：用戶調研、可用性測試、數據埋點、競品分析……就可以了解一下了！通過這些方法，就能又快、又準的幫你做出一個好用的功能。

4. 進階篇：設計賦能業務（績效加分項）

“賦能業務”是設計師工作中最重要的一點，相信這個詞在大家的績效匯報中經常看到。

如果說不懂“用戶體驗”的 UI 只是一個畫圖機器的話，那么不懂“賦能業務”的交互則是一個畫原型圖的機器。

① 如何賦能業務？

首先要弄清你的業務目標是什么？然后再圍繞著業務目標去細化拆分：

1. 思考自身設計，拆分設計任務
2. 了解項目組其他崗位成員的拆分任務，找準發力點，向下拆分

舉個例子，一個證件審核后臺的案例：

審核后臺的客服人力不足，導致工單積壓，用戶頻頻電話投訴催辦。業務方要求在一個月內，在不增加客服人員編制的情況下，將催辦類投訴工單降低 80%！

收到這個業務目標后，項目組內全體成員都在針對業務目標思考方案、制定各自的任務：

第一步，設計師團隊從設計出發，拆分設計任務：

1. 去調研客服人員審核流程，做操作步驟精簡提效；
2. 再去調研投訴用戶的心理，增加審核進度反饋功能，緩解用戶焦躁情緒；

然而，這些體驗層級的優化雖有奏效，卻很難擔起降低 80%投訴率的大額目標。

第二步，理清團隊其他崗位的任務內容及策略，向下拆分：

通過溝通，大數據團隊針對該目標提出了通過 OCR 識別技術（光學字符識別技術：通過掃描將印刷文字轉為圖片，再利用文字識別技術轉化為可使用的文字輸入），智能審核證件的方案。然而卻因為 OCR 識別錯誤率太高，導致近一半的工單仍然需要人工審核。

那么此時，設計師就可以在提升 OCR 識別成功率的目標下，向下拆分自己的設計目標了。

去調研 OCR 識別率低的基礎情況：除去技術層面的問題，用戶上傳照片不規范、傾斜、反光、重要信息未拍全等都會導致識別失敗。

那么對于這些問題，上傳審核步驟的指引優化就是關鍵所在！

最后，團隊一起實現了降低 80%投訴率的大目標，而設計師在項目過程中，既解決了用戶遇到的問題、又解決了團隊遇到的問題，做到了真正的賦能業務！

尾聲

漫長的文章終于接近尾聲了……

最后一句臨別贈言送給大家（也是筆者在學習交互的時候，一位老師送給我的）：

不必太過死磕各個崗位的工作范圍，沒有哪個行業內的專家能夠給交互、視覺、以及任何一份崗位的工作范圍去下定義。百度百科上能搜到的所有針對崗位的描述，也都只是包括但不限于。

所以，不必被他人設限，也不必給自己設限……

總而言之一句話，學習和提升是自己的事情，預祝各位成功！

歡迎關注「網易UEDC」公眾號：