交互設計師如何進行風險預判？

 　　在公司工作，任何職業都不可能單兵作戰，協作是永恆的主題，而每一個需求和任務的實現，都是各方通力合作的成果。作為交互設計師，除了做好自己的設計工作之外，還需要花費大量的時間與產品、運營、客戶端開發、前端開發、後端開發一起協作和溝通。

　　通常的合作方式是：產品經理撰寫 PRD 文檔並召開需求評審，各方一起參與評估需求，看看哪裡可以實現、哪裡有風險、哪裡做不到，最後幾經修改確定方案，投入設計，再進行交互評審、視覺評審，最後進入開發和走查。而交互設計、視覺設計因為位於開發實現之前、產品需求之後，扮演著一個承上啟下的作用，是對產品經理需求的诠釋和實現，也是為開發工程師繪制的工程藍圖。

　　但在實際工作中，我們經常遇到下面幾種情況：

　　業務上，你做的方案有可能影響到了其他業務邏輯，如修改了下單規則會影響預售、限購等功能規則，或者你影響其他業務方的流量、曝光率等，這都稱之為業務風險。

　　做好的設計稿在交互評審時，發現設計內容可能影響其他非本次需求范圍內的頁面，如風格不一致、交互方式不一致等，這稱之為設計風險;

　　所使用的交互方案技術上無法實現，可能是代碼邏輯不好實現(如接口調用方面的限制)，可能是這種交互方式本身技術不能做到(如炫酷的動效)，也有可能是受時間、人力所限，這稱之為技術風險。

　　做好對這三類風險的預判，可以幫助交互設計師極大減少無用功，避免反復交互評審;能夠經常對風險做出預判的設計師一定是對設計規范和業務邏輯非常熟悉的，這必然成為你的核心競爭力;當然，去做一個不僅僅會畫圖的設計師，相信同事們一定會對你贊不絕口，尤其在大團隊，口碑可是極其重要的。

　　業務風險預判

　　很多設計師喜歡拿到需求就馬上開始畫圖，並很快陷入到設計細節中，如字體字號、Toast 還是 Notification 等。殊不知，花點時間理解需求和業務邏輯，百利而無一害。建議設計師在平時就要對所負責產品線的業務邏輯有深入的了解，空閒的時候多去了解了解其他同事的工作內容是很有必要的。尤其是大型產品，往往業務之間存在高度交叉重疊，需求經常會互相影響。

　　舉個簡單的例子，大家可以去看一下，幾乎所有的電商產品，已經生成訂單號的訂單都是沒有辦法修改收貨地址的(如待付款等狀態)，而且經常有收到用戶反饋說希望可以在付款之前修改收貨地址，否則需要重新加入購物車提交訂單。最初我發現這個情況，以為這是技術限制，即可能已經生成的訂單在系統中會存在一個確定的編碼，而改動其中的內容可能成本較高，尤其在大流量情況下會有技術風險。但事實上深入了解後，發現這是一個業務風險：電商產品中，除了普通購買商品，還有諸如搶購、區域限售、預訂等消費形式，對於庫存的計算規則也各不相同，如果允許修改訂單地址，可能出現修改後的地址不支持相關服務或沒有庫存等情況。

　　如何進行業務風險預判?最重要的，是對業務邏輯、場景非常熟悉，才能知道你所做的設計會對別人產生什麼影響，才能明確『設計界限』;其次，尤其要注意那些多個業務場景共存於一個頁面的情況，非常有可能互相邏輯糾葛，牽一發而動全身;最後，還要深度理解需求的內涵，搞清楚這個設計任務最核心是解決什麼問題，提升什麼指標，千萬不要單純從用戶體驗出發，忘記設計的商業價值。

　　設計風險預判

　　大公司往往會有自己的設計規范，可能是組件形式、可能是顏色規范、也可能是視覺風格，總之常說，我們不是組件的生產者，而是組件的搬運工——沒錯，很多時候做的是利用已有組件搭建頁面的工

　　作。因此，當你在接到需求時，需要對可能遇到的設計風險進行預判。

　　組件的擴展性非常重要，當你在頁面中引入一個新的組件時，首先要判斷它自身能否承擔已有的業務需求(文案展示、頁面跳轉、視覺展示空間)，其次更要考慮它的擴展性，當多個不同屬性的項目同時存在於其中時能否有效展示?

　　對於頁面布局，需要考慮適配問題。你所做的設計方案可有考慮小屏幕用戶的直觀感受：iPhone 6 也許可以一行放4個按鈕，那 iPhone 5 甚至更小尺寸的手機如何展示?色彩的選用也要考慮屏幕的色差，一直在 iOS 上查看設計稿的設計師也請一定要准備一台 Android 手機看看顯示效果。

　　同一個客戶端的同一個業務流程中，交互體驗需要盡可能的一致。也許你改動的只是支付環節中的某一個頁面，但是在其中使用新的彈窗就必須考慮其他頁面的信息提醒是否也使用了這個彈窗，還是有其他的呈現形式。如果周邊頁面對於同一類信息的展示都有固定的樣式，切不要搞特立獨行，失去端對端的體驗往往會造成巨大的用戶認知障礙。

　　技術風險預判

　　由於技術是最終的實現環節，並且常常是設計師最不了解的領域，因此有意識地對技術進行風險預判就顯得尤為重要。除了有些是技術本身不能實現的，還有諸多內容是受限於當前的技術方案，都要額外注意。舉幾個簡單的例子供大家參考：

　　在設計中是否對常規組件提出了新的要求?

　　系統組件本身就會有很多的限制，比如你想在 iOS 自帶選擇時間的那個滾輪裡，對不同的選項進行顏色區分，幾乎就是不可能的，這屬於系統組件不允許的范疇。而團隊自己的產品可能有很久的積累，所用到的各種組件也有相應的限制，比如有些按鈕可能沒有 Disable 的狀態無法置灰、有些 Label 組件中同一行的文字無法對單獨的詞語進行顏色區分(比如：本件商品18.00元，你想要單獨對18.00設置紅色，其他是黑色，就可能會遇到這個問題)，請時刻提醒自己，能用現有組件解決的絕不要開發出新功能，盡可能不要使用新的組件，這成本遠超你的想象。

　　同一個業務邏輯在多端的交互方式是否不一致?

　　交互方式不一致也可能是為了用戶體驗，比如移動端本來就和 Web 端場景不同，交互自然也不同。但是請注意，產品的無線端和 Web 端非常有可能共同一套後台系統甚至接口，你的多端多體驗就有很大的概率導致這個接口需要開發來調整。比如同一行文案，在 Web 上是單行顯示，在無線上由於空間所限可能需要分成兩行，這就有可能需要額外的開發成本。

　　設計方案是否需要多次接口調用，影響性能?

　　技術真的不像你想象的那麼簡單。某產品在促銷期間，有限時優惠活動，交互設計師可能認為只需要判斷用戶下單的時間是否在優惠期限內就可以了，殊不知系統有可能是進入下單頁就要請求一次時間、點擊下單要請求一次時間、還要和設定的時間進行一次對比，來來回回調用接口兩三次，非常有可能在大流量並發的時候影響性能。

　　還需要注意的是，你的設計是否需要多個數據同時傳輸，比如商品名、SKU、優惠信息、運費等，它們很有可能來自不同的接口，不是一次性吐給你的。這種情況就還需要考慮如果其中有一個數據傳輸失敗(信號不好)怎麼辦?是給用戶提醒全部失敗需要重新刷新，還是把別的都顯示出來僅僅提示出錯的內容，還是自動多次刷新，都需要經過深思熟慮。

　　設計方案是否可能過於炫酷，有技術實現難度?

　　過於復雜的動效固然逼格滿滿，但是開發同學最怕這種非常規交互。看似簡單的彈性位移效果，就有可能要花費大量時間進行調試，更可能需要引入額外的第三方動效庫來實現。在用戶體驗以及交互美觀度的同時，也請一定要衡量一下開發成本，在能滿足需求的前提下采用最有效的形式，切不要盲目追求動畫的炫酷。

　　說了這麼多，還是那句話——只會畫圖的設計師不會是滿分的設計師。設計本身固然重要，但在工作中，學會與其他崗位的同學相互合作更能體現設計師的價值。提前對各類風險進行預判，利己利人，會幫助你快速成長。