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

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

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

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

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

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

01.不同類型的職責差異

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

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

1.1公司的業(yè)務差異

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

C端關注人性，B端關注組織與業(yè)務；

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

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

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

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

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

1.2產品周期差異

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

產品的探索期

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

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

產品的成長期

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

產品的成熟期

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

產品的衰落期

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

1.3團隊規(guī)模差異

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

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

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

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

從下圖阿里招聘中也可以發(fā)現(xiàn)該崗位的職責基本上圍繞與崗位相關的專業(yè)方向。

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

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

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

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

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

2.1信息收集

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

基礎信息：

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

體驗洞察信息:

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

2.2需求分析

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

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

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

2.3設計探索

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

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

2.4用戶測試

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

2.5設計細化

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

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

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

2.6評審定稿

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

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

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

不是的！

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

2.7跟進開發(fā)

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

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

2.8測試走查

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

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

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

2.9產品上線

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

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

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

03.寫在最后

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

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