交互設計師在現實產品設計流程中，如何積極地參與并完成設計工作呢？本文作者從項目開發流程和項目中的設計管理流程兩個方面，對日常工作中的交互流程進行了總結分析，一起來看一下吧。

前文針對日常交互設計師的日常職責梳理，沒看過的同學可以先看之前的文章。

職務細節梳理完之后，咱們對該干的事有了一個初步的了解，那我們如何在現實產品設計流程中積極地參與并完成設計工作呢？一起來看看吧~

01 項目開發流程

公司內部的項目基本上圍繞產品展開，項目迭代周期可能因為不同公司的項目而有所不同，但是大體可以分為瀑布模式與敏捷開發模式。

1. 瀑布開發模式

瀑布模式一般在需求相對穩定的傳統B端公司中應用廣泛，這類項目研發周期長，有著嚴格的階段管理，整個階段呈現一個線性結構，即每個階段必須有產出物后才能進入下一個階段，因此該模式特別強調里程碑，重視文檔的管理，每個角色只是不同階段中的螺絲釘，大家只關心自己的業務。

2. 敏捷開發模式

然而在互聯網環境下，軟件需要在滿足市場需求的基礎上快速迭代，確保研發的節奏與交付的質量。

敏捷開發模式一定程度上滿足了當下瞬息萬變的市場需求。因為產品的最終目標是為了讓客戶滿意，這就需要它具有靈活性，為了滿足客戶需求主動進行變更，適合需求不明確、創新性或者快速搶占市場的項目。

無論是敏捷開發或者瀑布開發模式，都存在各自的優缺點。我們多數團隊采用兩種模式的結合來進行研發管理，較多的就是每一周或者兩周進行一次迭代，它的核心是減少每次迭代的顆粒度。該模式下先把客戶最關心的模塊交付或者上線，剩余的功能在實際的場景中快速迭代上線，如此循環保證整個項目組的工作效率。

02 項目中的設計管理流程

1. 項目啟動階段

基于對需求的理解，產品經理需要與技術人員一起參與業務調研，規劃產品的功能范圍以及與公司現有技術能力的融合，確保業務理解的一致性。完成調研后，產品經理會基于對業務的理解以及行業經驗的沉淀，構思出相關的解決方案。這期間可能因為多方因素（客戶、領導、競品、同事、產品本身問題）的參與，會變動頻繁需求。

為了掌握主動權，在項目啟動階段，我們設計師需要主動了解以下幾點：

• 產品目標有哪些？
• 產品的緊急程度，需求的排期；
• 他們對新產品有哪些需求？當前產品他們在用時有什么困惑；
• 需求方的背景是什么樣的背景？在什么樣的場景下使用；
• 競品是什么？產品有沒有做相關的全鏈路大圖？

啟動初的業務會議特別重要，我們需要直接跟業務方或者產品提出參與。按照慣例一般該會議階段很少邀請設計，這時候更需要我們的主動。

在該階段，雖然有些專業名詞可能并不是很清楚，但是在開始前期就進入的話可以對當前產品背景以及需求有著更多的理解。

2. 項目規劃階段

在規劃階段，產品需要根據需求，整理產品的信息架構圖以及業務流程圖，輸出需求文檔以及原型圖（有時候沒時間的話需要交互設計師輸出原型圖）。

該階段主要針對當前產品所做的工作安排，會議上產品經理召集開發、測試、交互設計師等人員一起，官宣需求文檔以及確定各模塊排期。在這里產品會收集基于風險、難點和資源等方面建議，及早發現問題，最終確定并完善前端、設計、后端、測試的排期表格內容。

在需求評審會議上我們主要的工作是聆聽，有關當下設計的困惑我們也不應該遮掩，需要當場詢問，避免后續返工。在預估排期時，我們要準確預估設計的開始與結束周期（設計周期緊張需要在會上就提出來，讓負責人協調整體進度或者增加人手），讓工作更加有目標感。

3. 項目執行階段

1）項目設計階段

該階段我們交互設計與后端開發并行開始，后端需要準備數據庫、接口以及服務器環境，而我們也需要同步開始設計了。

圍繞需求文檔，有部分設計師可能會根據里面的功能描述，參考組內的設計規范直接把文檔視覺化。但這可能不是我們職責所在，因為這種針對需求文檔的直譯只是產品對于當前業務邏輯的體現，并沒有根據用戶目標的權重進行重新構思。

面對產品的需求文檔或者產品提供的原型頁面，我們需要考慮2點：

1. 當前的產品目標是什么？當前的方案是否滿足目標的實現？
2. 圍繞當前需求，是否可以通過我們的設計來幫助業務更好的完成目標？

我們要做一個有思考能力的設計師，在了解設計目標后，可以通過用戶的使用場景（把用戶使用的過程描述出來）發現頁面存在的問題，評價當前的設計是否合理。

這里有一個注意點就是當某一個體驗流程已經讓用戶形成固定的思維或者行業以及有了相對應的行為習慣，我們則需要遵從當前設計，只做微體驗的提升即可。畢竟B端的行業屬性，用戶通常會有一些行業特征（常用的操作步驟），如果我們只站在自身角度考慮，則會提升用戶的使用成本（畢竟產品買過去他們是實際操作者）畢竟時間就是金錢，用戶對效率有著極高的要求。

2）項目評審階段

等設計的工作完成之后就要進入評審階段，該階段的主要目的是為了讓各方圍繞產品設計方案做充分交流，最終達成一致的意見。即使在評審會上大家分歧很大，也可以知道接下來我們要做的方向是什么（通過團隊決策，降低產品風險）。為了讓大家在評審之前明確評審目的，我們在發評審通知的時候可以把此次會議的幾個目的列出來，這樣在把控評審會議的時候目標感更強。

評審會階段特別重要，因為其他團隊可能并不清楚設計的成因，所以它也是我們設計獲得團隊信任的階段，在這里我們可以把自己的設計思路與思考表達出來，這樣就知道了當前的設計思路與業務目標之間的關系，從而有利于團隊建立對設計方案的依賴。

3）開發測試階段

設計稿完成評審之后就可以進入前端開發階段，等前后端一起過一遍整體流程后就可以通過郵件進行提測了。

測試人員根據測試用例（產品需求文檔）測試完成后由產品經理驗收。對于測試而言，該階段的驗收標準就是產品的是否正常使用，各功能邏輯是不是按照需求文檔一一實現的，有沒有嚴重的bug，若有問題則需要在上線前提出解決。

這一步也需要我們交互設計師參與，確保上線后產品的交互邏輯是否與設計稿保持一致，畢竟當用戶實際場景中用的不爽，這個鍋還得是設計師的責任，所以交互驗收也是保證設計真正能落地的重要一步。設計走查后需要輸出走查清單，確保開發可以按照清單內容逐一修復。

所有的bug改完之會叫產品來進行最終的驗收，這是整體走查的最后一步了，此時產品會把全流程在走一遍，是否符合預期，無誤后打包上線。

4. 項目收尾階段

很多同學覺得上線后就沒事了，這其實是一種錯誤的想法。

一般在產品上線的2周之內問題最為集中，這里我們可以重點關注用戶的體驗反饋以及上線后的數據如何。當收集反饋的過程中某個問題比較集中時可以復盤問題點以及以后將如何規避。

產品上線后的復盤對于我們設計師而言特別重要，復盤可以從目標回顧、結果評估、原因分析以及經驗總結這四個維度來展開。這種以學習為主導的復盤可以加速我們的能力成長，畢竟我們都不希望踩同樣的坑，我們需要在之前的基礎上不斷的積累自己知識庫，構筑我們的專業護城河。

03 寫在最后

上述項目流程在不同的公司可能因項目復雜程度的不同而有變化，流程中不變的則是及時溝通。

溝通是確保每個階段對齊愿景、對齊目標、對齊問題、對齊質量的重要保障。在不同階段需要保證結果的留痕，千萬不要默默無聞！

以上只是我對產品工作流程的粗略總結，希望該文章對你有所啟發，也歡迎感興趣的同學一起探討~

今年的Flag就是要輸出交互設計系列課程，也期待大家對我的關注與監督。