4000字干貨！B端交互設(shè)計師的工作流程總結(jié)

寫在前面

近期看到京東設(shè)計中心 JDC 的一篇文章「交互設(shè)計師的成長體驗地圖：初入職場篇」，文章從新人設(shè)計師角度出發(fā)，梳理出一張交互設(shè)計師的成長體驗地圖，幫助新人交互設(shè)計師快速了解交互設(shè)計工作流程，以及過程中遇到的痛點和解決策略。受到該文章的啟發(fā)，我結(jié)合自己的工作經(jīng)歷，梳理出一個B端交互設(shè)計師的工作流程框架，向大家展示B端交互設(shè)計師工作流程主要分成哪幾個階段？每個階段分別需要做什么？都存在什么痛點？有什么解決策略？

交互設(shè)計師工作流程

目前在公司的產(chǎn)品研發(fā)流程中，交互設(shè)計師參與的階段主要有五個：需求階段、設(shè)計階段、開發(fā)階段、測試階段、上線階段，如圖所示

1. 需求階段

主要事項

事項 1：了解項目概況

在接到需求時，需要先對整體項目情況做大概的了解，包括項目背景和目標、項目周期、需求清單、設(shè)計周期等等。

事項 2：理清業(yè)務(wù)需求

結(jié)合產(chǎn)品提供的資料和原型了解關(guān)鍵業(yè)務(wù)流程，邊梳理邊記錄問題。過程中將有疑問的地方反復(fù)與產(chǎn)品和業(yè)務(wù)進行溝通確認，確保雙方理解一致。

事項 3：評估工期，協(xié)調(diào)資源

設(shè)計師需要結(jié)合項目情況和需求量，初步判斷所需設(shè)計資源以及設(shè)計周期，確保工作能夠往前推行。

痛點及解決策略

痛點 1：需求溝通過程中獲取不到想要的信息

接到需求后找產(chǎn)品溝通，但對項目背景不太了解，在較短的溝通時間內(nèi)獲取不到自己想要的信息。

策略：

• 提前要資料。需求溝通前先找產(chǎn)品經(jīng)理要項目資料、需求文檔等等。自己花時間查閱下，先對整體項目有個大概的了解，查閱過程中記錄待確認的問題
• 列「需求溝通清單」。提前準備好一份需求溝通清單，能大大提升需求溝通效率和質(zhì)量。以下內(nèi)容是我進行初次需求溝通時會重點關(guān)注的內(nèi)容（見如下表格）
• 當面或電話溝通。避免文字溝通會有信息失真

需求溝通清單

痛點 2：對需求存疑時，如何評估其合理性

需求溝通過程中，如果發(fā)現(xiàn)某些需求不合理時，可考慮采用以下策略應(yīng)對。

策略：

• 了解需求背景。在溝通過程中如果對某個需求的合理性存在疑問時，不要急于否定，先聽聽產(chǎn)品描述需求產(chǎn)生的背景，確定需求涉及的用戶角色以及使用場景，再去判斷這個需求的合理性
• 提供新思路。在溝通過程中可以提供一些新思路，與產(chǎn)品一起探討

痛點 3：需要準確預(yù)估需求量，爭取合理的設(shè)計周期

當設(shè)計資源緊張又遇到一些緊急需求時，如果對需求量預(yù)估不準確，可能會有設(shè)計延期的風(fēng)險。

策略：

• 初步評估設(shè)計周期。通過需求溝通預(yù)估需求量，結(jié)合項目周期初步判斷預(yù)留的設(shè)計周期是否合理
• 各設(shè)計角色參與評估工期。確定項目所需設(shè)計資源（交互、UI和視覺），各自評估所需設(shè)計工期，保證團隊內(nèi)部的良好配合。切忌按照自己的經(jīng)驗去評估其他角色同事的工期
• 預(yù)估設(shè)計資源風(fēng)險。了解團隊現(xiàn)有資源情況是否匹配項目要求，如有風(fēng)險，先跟產(chǎn)品溝通是否可以做些調(diào)整（如分批交付、只設(shè)計關(guān)鍵頁面...）。如果不被采納，則需向上匯報，說明情況后再做下一步?jīng)Q策

痛點 4：原型缺失或不規(guī)范

產(chǎn)品提供的原型不規(guī)范，或者沒有提供原型，這也是設(shè)計師經(jīng)常遇到的事情。

策略：

• 制定「原型輸入標準」，規(guī)范產(chǎn)品原型設(shè)計
• 提供規(guī)范案例參考。產(chǎn)品經(jīng)理原型設(shè)計能力參差不齊，如果遇到不知道怎么畫原型的情況，可以提供規(guī)范的產(chǎn)品原型案例給產(chǎn)品經(jīng)理參考

2. 設(shè)計階段

主要事項

事項 1：競品分析和用戶調(diào)研

競品分析和用戶調(diào)研需視項目情況而定，如果時間充裕，建議在設(shè)計之前進行這兩項工作，為設(shè)計方案提供強有力的客觀依據(jù)。

事項 2：設(shè)計執(zhí)行

• 設(shè)計輸出（規(guī)范的交互稿、清晰的交互說明）
• 設(shè)計評審（盡量拉通產(chǎn)品、業(yè)務(wù)、UI和開發(fā)等相關(guān)人員參加，確保達成一致）
• 設(shè)計驗證（時間允許的情況下，可進行可用性測試，降低上線后的體驗風(fēng)險）
• 設(shè)計沉淀（沉淀典型頁面模板，廢棄方案也有價值，不要丟棄，建議寫明本次廢棄的原因）

事項 3：把控設(shè)計進度和質(zhì)量

在現(xiàn)有研發(fā)流程中，交互設(shè)計師通常作為項目對接人，需要對項目整體設(shè)計進度和質(zhì)量進行把控。

痛點及解決策略

痛點 1：設(shè)計方案受到多方挑戰(zhàn)，修改次數(shù)多

產(chǎn)品和業(yè)務(wù)有自己的想法，要求設(shè)計師按他們的想法修改方案。

策略：

• 站在對方角度看問題。如果覺得產(chǎn)品或業(yè)務(wù)方提出的方案不合理時，先不要急于否定他們。先了解他們提出這種方案的理由，這樣更能夠提出滿足業(yè)務(wù)需求的方案，也更容易說服對方
• 進行用戶調(diào)研或競品分析，為設(shè)計方案提供有力的客觀依據(jù)

痛點 2：交互設(shè)計需要考慮周全，比較耗時

策略：

• 先抓流程，再抓細節(jié)。交互設(shè)計重點是在流程和邏輯梳理，切忌花太多時間鉆研到細節(jié)里去，導(dǎo)致延誤了整體設(shè)計進度。下圖依次為真實項目中的「任務(wù)流程圖」和「頁面流程圖」。

任務(wù)流程圖

頁面流程圖

痛點 3：開發(fā)過程發(fā)現(xiàn)設(shè)計方案較難實現(xiàn)，需要調(diào)整

策略：

• 邀請開發(fā)參加設(shè)計評審。在設(shè)計評審階段邀請相關(guān)開發(fā)人員參與，提前評估技術(shù)實現(xiàn)風(fēng)險
• 進行設(shè)計宣講。在設(shè)計方案定稿后要跟開發(fā)人員進行宣講，確保對方案理解準確

3. 開發(fā)階段

主要事項

事項 1：提供必要的設(shè)計支持

開發(fā)有疑問時，需要進行解答和處理，提供相應(yīng)的設(shè)計支持。

事項 2：應(yīng)對需求變更

在開發(fā)過程中產(chǎn)生需求變更，設(shè)計師需根據(jù)變更內(nèi)容進行評估，判斷是否需要調(diào)整方案。

痛點及解決策略

痛點 1：交互稿存在細節(jié)未考慮周全

在設(shè)計周期緊張時，交互稿難免有疏漏，在開發(fā)過程中需要頻繁補充細節(jié)內(nèi)容

策略：

• 按照規(guī)范輸出交互稿及交互說明，給下游同事提供良好的閱讀體驗
• 考慮各種可能性。輸出交互稿時不能只考慮正常狀態(tài)，也要考慮各種異常狀態(tài)、特殊狀態(tài)
• 沉淀典型模板。將一些常用的典型頁面沉淀為模板，便于需求迭代時快速復(fù)用，縮短設(shè)計周期

痛點 2：發(fā)生需求變更時直接按變更后方案開發(fā)

發(fā)生需求變更時未及時知會設(shè)計師，直接按產(chǎn)品或業(yè)務(wù)的想法進行開發(fā)，設(shè)計師難以按照原有設(shè)計方案進行驗收，產(chǎn)品體驗無法把控。

策略：

• 建立需求變更反饋機制，涉及界面變更時需及時知會設(shè)計師
• 調(diào)整方案需多方評審確認，才能交給開發(fā)進行實現(xiàn)

4. 測試階段

主要事項

事項 1：獲取測試環(huán)境，進行設(shè)計驗收

在進入設(shè)計驗收時，需找產(chǎn)品提供測試環(huán)境地址、賬號和密碼，同時需提前配好需要測試的相關(guān)數(shù)據(jù)。依照設(shè)計方案執(zhí)行設(shè)計驗收，發(fā)現(xiàn)問題并提交開發(fā)修改。

事項 2：跟蹤問題處理

跟蹤設(shè)計驗收問題開發(fā)處理進度，直到問題關(guān)閉，確保達到上線標準。

痛點及解決策略

痛點 1：未預(yù)留足夠的設(shè)計驗收時間

有時候項目組并未預(yù)留足夠的設(shè)計驗收時間，導(dǎo)致需求未經(jīng)驗收就直接上線，影響到產(chǎn)品體驗質(zhì)量。

策略：

• 提前宣貫。在設(shè)計定稿后進入開發(fā)前，要向產(chǎn)品經(jīng)理了解幾時會進入測試，同時宣貫一定要預(yù)留時間給UED進行設(shè)計驗收
• 了解關(guān)鍵測試節(jié)點，定期跟蹤。提前了解項目測試時間節(jié)點，定期詢問進度，提醒產(chǎn)品經(jīng)理通知UED進行設(shè)計驗收。
• 將設(shè)計驗收環(huán)節(jié)納入研發(fā)流程。將設(shè)計驗收環(huán)節(jié)納入到產(chǎn)品研發(fā)流程中，通過線上系統(tǒng)進行管理，在項目初期就需要明確設(shè)計驗收時間。

痛點 2：開發(fā)還原度低，驗收耗時長

界面難以 100%按設(shè)計稿實現(xiàn)，主要原因如下

• 直接用的第三方組件庫或者系統(tǒng)架構(gòu)較難改動，沒按設(shè)計規(guī)范調(diào)整
• 開發(fā)沒有理解清楚需求
• 開發(fā)過程存在需求變更或技術(shù)實現(xiàn)有難度，按照自己的想法更改了實現(xiàn)方案，但沒知會到UED，導(dǎo)致實現(xiàn)效果與UI稿不一致

策略：

• 建立用戶體驗設(shè)計驗收標準。各角色需遵照標準執(zhí)行，驗收結(jié)果作為上線準出標準
• 邀請開發(fā)同事參與設(shè)計評審，提前預(yù)估技術(shù)實現(xiàn)風(fēng)險
• 開發(fā)過程加強溝通。有任何涉及界面變更的內(nèi)容都需要知會UED，再一起評估是否調(diào)整方案

痛點 3：設(shè)計驗收場景覆蓋不全

設(shè)計定稿與設(shè)計驗收時間通常會有一個較長的時間間隔，加上 B 端產(chǎn)品業(yè)務(wù)路程會相對復(fù)雜，在設(shè)計驗收時會遺忘一些業(yè)務(wù)邏輯。

策略：

• 編寫交互測試用例。在設(shè)計定稿后，這個時間點對業(yè)務(wù)是最熟悉的，趁著這個時間梳理出一些關(guān)鍵的業(yè)務(wù)場景，編寫操作流程和步驟，供后續(xù)驗收時參考

交互測試用例

5. 上線階段

主要事項

事項 1：上線后設(shè)計支持

協(xié)助產(chǎn)品跟蹤上線情況并提供相應(yīng)的設(shè)計支持。

事項 2：進行項目復(fù)盤

建議在項目上線后就進行一次項目復(fù)盤（包含設(shè)計成果以及團隊協(xié)作）。復(fù)盤是設(shè)計師一項很重要的能力，沉淀好的經(jīng)驗，總結(jié)項目過程中存在的問題及解決思路，為后續(xù)更好地推進項目打下基礎(chǔ)。

痛點及解決策略

痛點 1：設(shè)計成果缺乏數(shù)據(jù)驗證

不是每個系統(tǒng)都有完整的數(shù)據(jù)埋點機制，設(shè)計成果在上線后得不到客觀驗證數(shù)據(jù)驗證。

策略：

進行用戶調(diào)研。如果沒有進行數(shù)據(jù)埋點，則可考慮上線一段時間后（建議是1個月左右），找一些目標用戶進行調(diào)研，以用戶反饋內(nèi)容作為設(shè)計效果的驗證。

痛點 2：復(fù)盤時找不到素材

復(fù)盤通常是項目結(jié)束后進行的，需要重新花時間去回顧整個項目過程中所產(chǎn)生的設(shè)計思路以及存在的問題。時間一久，有些材料可能已經(jīng)找不到了。

策略：

• 項目初期建立復(fù)盤大綱。項目開始前期就想好項目上線后要復(fù)盤什么內(nèi)容，建立一個大綱。在項目執(zhí)行過程中就可以圍繞大綱（比如設(shè)計亮點、設(shè)計方案存在問題及解決方案、項目協(xié)作問題及解決思路、下一步計劃等等），碎片式地往里面收集素材并進行階段性整理。
• 及時總結(jié)設(shè)計思路。隨著項目推進，時間一長可能已經(jīng)想不起當初為什么要這樣設(shè)計，因此需要及時將設(shè)計思路沉淀下
• 建立項目問題收集表。項目過程中遇到問題隨時記錄（包括解決思路）

工作流程框架

以上內(nèi)容總結(jié)成以下框架，可供實際工作中進行參考。

工作流程框架

最后總結(jié)

可能有人會問“「框架」會不會限制設(shè)計師發(fā)揮？”，我的答案是“不會”。「框架」并不是用來約束設(shè)計師的行為，而是提供一個指引。有了「框架」，交互設(shè)計師在接到需求后，能夠以一個更全局的視角去應(yīng)對，知道接下來有哪些事情要做，需要先做什么，有哪些方法可等等，這在一定程度上提高了工作效率。當然，「框架」不是萬能的，以上內(nèi)容僅為個人經(jīng)驗總結(jié)，在實際執(zhí)行過程中需根據(jù)不同項目情況進行靈活調(diào)整和優(yōu)化。就像文章開頭所說，“使用「框架」解決問題不一定是最優(yōu)的方案，但一定是性價比高的方案。”希望文章內(nèi)容對大家有所啟發(fā)，在實際工作中輸出適用于自己的一套框架。