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

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

職務細節(jié)梳理完之后，咱們對該干的事有了一個初步的了解，那我們?nèi)绾卧诂F(xiàn)實產(chǎn)品設計流程中積極地參與并完成設計工作呢？一起來看看吧~

01 項目開發(fā)流程

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

1. 瀑布開發(fā)模式

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

2. 敏捷開發(fā)模式

然而在互聯(lián)網(wǎng)環(huán)境下，軟件需要在滿足市場需求的基礎上快速迭代，確保研發(fā)的節(jié)奏與交付的質量。

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

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

02 項目中的設計管理流程

1. 項目啟動階段

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

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

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

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

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

2. 項目規(guī)劃階段

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

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

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

3. 項目執(zhí)行階段

1）項目設計階段

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

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

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

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

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

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

2）項目評審階段

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

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

3）開發(fā)測試階段

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

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

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

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

4. 項目收尾階段

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

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

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

03 寫在最后

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

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

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

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