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

前文針對(duì)日常交互設(shè)計(jì)師的日常職責(zé)梳理，沒看過的同學(xué)可以先看之前的文章。

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

01 項(xiàng)目開發(fā)流程

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

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

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

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

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

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

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

02 項(xiàng)目中的設(shè)計(jì)管理流程

1. 項(xiàng)目啟動(dòng)階段

基于對(duì)需求的理解，產(chǎn)品經(jīng)理需要與技術(shù)人員一起參與業(yè)務(wù)調(diào)研，規(guī)劃產(chǎn)品的功能范圍以及與公司現(xiàn)有技術(shù)能力的融合，確保業(yè)務(wù)理解的一致性。完成調(diào)研后，產(chǎn)品經(jīng)理會(huì)基于對(duì)業(yè)務(wù)的理解以及行業(yè)經(jīng)驗(yàn)的沉淀，構(gòu)思出相關(guān)的解決方案。這期間可能因?yàn)槎喾揭蛩兀蛻?、領(lǐng)導(dǎo)、競(jìng)品、同事、產(chǎn)品本身問題）的參與，會(huì)變動(dòng)頻繁需求。

為了掌握主動(dòng)權(quán)，在項(xiàng)目啟動(dòng)階段，我們?cè)O(shè)計(jì)師需要主動(dòng)了解以下幾點(diǎn)：

• 產(chǎn)品目標(biāo)有哪些？
• 產(chǎn)品的緊急程度，需求的排期；
• 他們對(duì)新產(chǎn)品有哪些需求？當(dāng)前產(chǎn)品他們?cè)谟脮r(shí)有什么困惑；
• 需求方的背景是什么樣的背景？在什么樣的場(chǎng)景下使用；
• 競(jìng)品是什么？產(chǎn)品有沒有做相關(guān)的全鏈路大圖？

啟動(dòng)初的業(yè)務(wù)會(huì)議特別重要，我們需要直接跟業(yè)務(wù)方或者產(chǎn)品提出參與。按照慣例一般該會(huì)議階段很少邀請(qǐng)?jiān)O(shè)計(jì)，這時(shí)候更需要我們的主動(dòng)。

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

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

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

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

在需求評(píng)審會(huì)議上我們主要的工作是聆聽，有關(guān)當(dāng)下設(shè)計(jì)的困惑我們也不應(yīng)該遮掩，需要當(dāng)場(chǎng)詢問，避免后續(xù)返工。在預(yù)估排期時(shí)，我們要準(zhǔn)確預(yù)估設(shè)計(jì)的開始與結(jié)束周期（設(shè)計(jì)周期緊張需要在會(huì)上就提出來，讓負(fù)責(zé)人協(xié)調(diào)整體進(jìn)度或者增加人手），讓工作更加有目標(biāo)感。

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

1）項(xiàng)目設(shè)計(jì)階段

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

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

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

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

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

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

2）項(xiàng)目評(píng)審階段

等設(shè)計(jì)的工作完成之后就要進(jìn)入評(píng)審階段，該階段的主要目的是為了讓各方圍繞產(chǎn)品設(shè)計(jì)方案做充分交流，最終達(dá)成一致的意見。即使在評(píng)審會(huì)上大家分歧很大，也可以知道接下來我們要做的方向是什么（通過團(tuán)隊(duì)決策，降低產(chǎn)品風(fēng)險(xiǎn)）。為了讓大家在評(píng)審之前明確評(píng)審目的，我們?cè)诎l(fā)評(píng)審?fù)ㄖ臅r(shí)候可以把此次會(huì)議的幾個(gè)目的列出來，這樣在把控評(píng)審會(huì)議的時(shí)候目標(biāo)感更強(qiáng)。

評(píng)審會(huì)階段特別重要，因?yàn)槠渌麍F(tuán)隊(duì)可能并不清楚設(shè)計(jì)的成因，所以它也是我們?cè)O(shè)計(jì)獲得團(tuán)隊(duì)信任的階段，在這里我們可以把自己的設(shè)計(jì)思路與思考表達(dá)出來，這樣就知道了當(dāng)前的設(shè)計(jì)思路與業(yè)務(wù)目標(biāo)之間的關(guān)系，從而有利于團(tuán)隊(duì)建立對(duì)設(shè)計(jì)方案的依賴。

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

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

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

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

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

4. 項(xiàng)目收尾階段

很多同學(xué)覺得上線后就沒事了，這其實(shí)是一種錯(cuò)誤的想法。

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

產(chǎn)品上線后的復(fù)盤對(duì)于我們?cè)O(shè)計(jì)師而言特別重要，復(fù)盤可以從目標(biāo)回顧、結(jié)果評(píng)估、原因分析以及經(jīng)驗(yàn)總結(jié)這四個(gè)維度來展開。這種以學(xué)習(xí)為主導(dǎo)的復(fù)盤可以加速我們的能力成長(zhǎng)，畢竟我們都不希望踩同樣的坑，我們需要在之前的基礎(chǔ)上不斷的積累自己知識(shí)庫(kù)，構(gòu)筑我們的專業(yè)護(hù)城河。

03 寫在最后

上述項(xiàng)目流程在不同的公司可能因項(xiàng)目復(fù)雜程度的不同而有變化，流程中不變的則是及時(shí)溝通。

溝通是確保每個(gè)階段對(duì)齊愿景、對(duì)齊目標(biāo)、對(duì)齊問題、對(duì)齊質(zhì)量的重要保障。在不同階段需要保證結(jié)果的留痕，千萬(wàn)不要默默無聞！

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

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