越來越多企業開始重視交互設計在互聯網產品中發揮的作用，那么交互設計師的日常職責是什么？不同的業務方向、組織架構、公司規模，工作內容會有怎樣的差異？作者進行了詳細的說明，一起來看看吧~

隨著工業智能化以及互聯網的大規模發展，在現如今用戶為王的環境下，用戶體驗在企業中的地位尤為重要，因為它直接影響到企業產品在市場中的競爭力，進而決定了其在激烈的商業競爭中的獲利。

產品想要獲得更好的用戶體驗，這其中的交互邏輯必須要符合用戶的需求。

以互聯網產品為例，由于它們產品類型、功能接近，免費使用，因此用戶的背叛成本也較低。為了讓自家產品脫穎而出，獲得更多的產品忠誠度，企業也越來越重視交互在互聯網設計中的地位。

由于業務方向、組織架構、公司規模等多方差異，交互設計在不同公司中的職責也有所不同。

今天本文將圍繞交互的職責展開，包括不同公司以及產品不同階段的職責差別、交互設計流程等，一起來看看吧~

01.不同類型的職責差異

有同學會有疑惑為什么講差異，直接陳述工作流程中每一步的工作職責會不會更好？

這是因為我們周圍有很多同學會抱怨自己公司沒有留有足夠的時間去調研分析，不重視交互體驗，干的事很雜，沒有完整的流程等，這些現狀的背后可能有三方面因素：公司的業務差異、產品的發展差異、團隊規模差異。

1.1公司的業務差異

B端與C端的交互設計師因為業務方向的差別，服務人群、用戶需求、產品訴求等發力點等都不一致。這就導致了它們交互的工作職責有所差異。

C端關注人性，B端關注組織與業務；

C端產品“秀軟件”，B端產品“賣軟件”；

C端注重流量思維，B端注重效率思維。

在C端公司中需求的挖掘得通過用戶畫像、數據分析等方法，通過對用戶行為的分析獲得。在設計中關注市場流行趨勢，重視用戶的偏愛和建議，借助不同的交互呈現，引起共鳴。這就需要我們交互設計師具備多種分析、調研且提煉需求的職責，在該行業的交互設計師發力的發力點很多。

B端的需求雖然明確，但是場景、功能、業務流程、信息架構要遠比C端更加復雜，這就需要我們交互設計師具有熟練掌握相對應的行業知識，縷清業務邏輯的職責。

在B端設計中，交互設計師要解決的始終都是如何提升產品的工作效率，為了滿足效率有時候即使體驗不好，但為了適應已經形成用戶習慣的交互不得不妥協，因此在該行業中，實際的交互體驗呈現可能并沒有C端那么豐富。

1.2產品周期差異

在產品發展的不同階段，交互設計的職責也有所不同。

產品的探索期

這時候的產品目標是產品方向的探索。用戶是誰？需要解決什么樣的痛點？競品是誰？與它的差異點是什么？

該階段對于我們交互設計師特別重要，我們需要通過競品分析、配合產品保證核心功能交互流程暢通的情況下，低成本的驗證方向的可行性。在實際工作的時候可能會涉及快速產品的快速上線，這時候我們不需要過多的糾結于細節，只要大方向對就可以。

產品的成長期

重點工作在于拉新。此時我們需要配合運營進行拉新活動的設計，除了主要功能的體驗外，要時刻關注數據指標，通過指標的不同挖掘可能的增長點。

產品的成熟期

伴隨著產品已經進入了穩定階段，我們的關注點要改為用戶的活躍與產品的營收。我們可以通過對核心功能體驗的打磨增加用戶的滿意度與營收的轉化。

產品的衰落期

我們要積極創新尋求新的機會點，例如通過用戶訪談查明流失原因，通過市場分析尋求新的增長點。這時候不建議設計師花較多精力去追求極致的用戶體驗（即使再努力收益也很有限），因為這可能是我們產品本身出了較為嚴重的問題，我們也無法阻止。

1.3團隊規模差異

經常聽同學說在大廠里面干的很明確，基本僅局限于本職工作，而在小公司內啥都要干，不單單畫原型圖，而且還得標注交互，甚至還得出視覺稿。

為什么一些大廠與小公司對于交互設計的職責差距這么大？

大公司與小公司的差異也意味著公司內部部門多、團隊多，很多項目的完成牽扯到不同部門的合作。為了保證每一個流程的順利推進，公司內部的每個崗位都有明確的崗位描述，定義清晰，每個員工就像是一個螺絲釘，保證著公司的正常運轉。

為了讓團隊員工快速上手，每個崗位還有對應的SOP（標準作業程序），確保團隊內每一個新員工都可以做深做精。

從下圖阿里招聘中也可以發現該崗位的職責基本上圍繞與崗位相關的專業方向。

通過在該崗位多年的沉淀，也可以確保你成為該領域的導師甚至專家。

而小公司內部由于規模較小，這就需要員工身兼多職。有時候產品經理忙的時候直接甩出一份產品需求文檔，需要交互完成剩余的所有設計工作，包括業務理解、體驗優化、設計稿輸出、交互規范編寫等。

下圖的招聘體現了公司對于設計崗位多職能的要求，只要跟設計沾邊的都得參與。

02.交互設計師的具體職責

講完交互職責之間的差異，我們接下來看看交互設計師在具體的工作項目中的職責是什么。

2.1信息收集

在開始階段，我們需要收集項目有關的基礎信息以及體驗洞察信息。在溝通這些信息前，我們優先對接產品經理，向他尋求項目相關資料，并準備需求溝通清單，保證當面對接需求時候的效率以及質量。

基礎信息：

了解當前項目在整個敏捷開發中的優先級，如果優先級特別高的話需要提前排期。了解當前的業務目標以及用戶目標。通過與開發的對接，明確當前的技術實現能力，保證設計的落地閉環。

體驗洞察信息:

通過梳理產品的全鏈路大圖，快速熟悉當前的產品結構以及功能。借助競品分析、數據分析或者用研報告等提煉設計的發力點，為設計方法提供強有力的客觀依據。結合項目本身遇到的問題進行有針對性的研究，并給出不同樣式的比較作為輔助，這也是交互設計不同于產品側競品分析的區別。

2.2需求分析

圍繞項目的業務目標、體驗目標以及當前團隊的技術水平得出此次的設計目標以及排期。

它需要我們圍繞真正的用戶使用場景（不要憑空捏造出用戶的痛點）找出當前迭代中最急迫解決的3個問題，并給這三個問題劃分優先級。

在這一階段，我們要準確預估設計周期，避免因為設計資源緊張導致的延期。如遇緊急項目，我們可以分批交付，先出關鍵頁面的方法來應對。

2.3設計探索

這一步需要我們圍繞設計目標探索可能的解決方案，通過可視化幫助團隊聚焦目標和評估成本（這里的可視化指的是流程圖以及低保真原型）。在該階段要保持與需求方的討論同步，探索不同場景中的設計假設與團隊對齊目標。

在設計探索中并不需要展示產品所有的邏輯，而是圍繞當前迭代中的目標去呈現不同角色在不同場景中的流程。探索中交互草圖對于交互細節、具體字段、顯示方式等可以放寬要求，確保流程簡單高效。

2.4用戶測試

當前需要與組內的資深設計師或者設計專家合作發起敏捷測試，在開發前期發現并修復體驗問題，確保交互方向的正確性。

2.5設計細化

在我們的交互初稿評審通過后，整合評審建議開始設計的進一步細化。該環節我們需要依照規范和真實字段素材產出高保真原型。此時的高保真設計稿應該注意：

• 簡潔扼要的說明說有細節（足夠讓開發理解）；
• 表達出基本的視覺優先級順序；
• 關鍵業務制作可交互的真實原型，保證所有體驗細節的精準點擊；

交互設計在與UI設計配合的時候需要輸出交互原型圖以及交互設計文檔，這份文檔會貫穿UI設計與開發的整個流程中。UI設計會根據交互文檔中書寫的規則來完成視覺稿，前端開發也會根據交互文檔中的規則來書寫頁面結構。

2.6評審定稿

交互高保真完成后一般會有一個規模較大的評審定稿環節，評審環節我們需要把與當前項目相關的所有人（重點是那些能拍板做決策的人）都邀請過來，避免設計稿被來回推翻。評審后把會議記錄抄送給所有相關人員。

在設計方案確定后也要與開發同學進行對接，保證方案理解的準確性。

那是不是所有的反饋都得等這個會議才知道？

不是的！

這個會議之前的討論才是真正的環節，在此之前我們就需要盡可能的讓相關信息達成共識，會議只是一個官宣的流程。例如在評審前我們需要與開發人員對接，保證方案實現的可行性。

2.7跟進開發

這一步我們要緊密的對接開發，因為在實際的工作中我們難免會有疏忽或者開發會對部分交互細節的理解不清楚，此時需要我們提供相對應的解答與支撐。在日常工作中我們可以沉淀一些典型場景的模板，以便縮短周期。

跟進開發環節需要我們跟蹤設計還原度以及數據埋點。該階段最頭疼的是交互細節的補充，因為在一些緊急狀態下交互難免會有遺漏，這期間需頻繁及時的補充設計細節。

2.8測試走查

產品上線后的內容需要做一個交互的走查（這個階段，測試會介入，來看這個程序會存在什么bug，然后讓開發去修補bug）。雖然有測試的介入，但是他們往往不會檢查體驗的問題，而是程序的問題。

我們交互幫助測試去查看，咱們開發出的產品是不是可以讓用戶順利使用，保證產品的易用以及好用，特別是異?；蛘咛厥鉅顟B。依據當前產品比對設計稿進行還原度排查，留意交互邏輯、狀態和效果的精確還原。

這邊值得注意的是，在B端產品的驗收中，由于業務復雜，我們可能有時候光顧著交互邏輯而忽視了業務邏輯，這時候需要讓需求方或者產品側介入，首先保證產品業務場景以及操作流程上的合理化，然后再由咱們設計進一步驗收。

2.9產品上線

產品上線后到了我們的設計總結階段，我們需要通過數據監測和真實的用戶反饋沉淀心得，總結問題和提煉解決思路，避免在后續的工作中踩同樣的坑。

這一步千萬不要船過水無痕，每次項目后的總結可以作為設計師職業成長的重要基石。這些真實的業務數據也可以向團隊佐證咱們設計的價值。

在B端場景下可能缺乏必要的數據驗證，此時需要我們對一些用戶進行問卷調研，以真實的反饋驗證我們的設計。

03.寫在最后

這些有關交互設計師的職責是不是一成不變的？不是的！

這些職責框架只是簡要的概述了交互設計師在拿到需求后具體的流程，但是具體的步驟則需要根據具體的項目情況進行優化。