進(jìn)階科普！提高 UED 團(tuán)隊效率的敏捷設(shè)計流程有多好用？

用戶體驗設(shè)計（簡稱UED）注重用戶在使用產(chǎn)品前，使用中和使用后的整體感受，讓產(chǎn)品擁有極致的體驗是每一個 UED 設(shè)計師追求的目標(biāo)，但是在當(dāng)今競爭激烈殘酷的互聯(lián)網(wǎng)大環(huán)境下，為了搶占先機(jī)，敏捷才是取勝的王道。我們單純做好產(chǎn)品體驗是不夠的，用戶體驗會隨著時間的變化而改變，用戶的需求、用戶的動機(jī)都在不斷發(fā)生變化、用戶的期望也會受其它產(chǎn)品的變化而時過境遷。用戶只會忠誠于能夠滿足他的需求的產(chǎn)品。因此除了產(chǎn)品體驗，我們還要快速地滿足了產(chǎn)品的迭代。有沒有什么方式讓我們能保證產(chǎn)品體驗的同時，又能滿足產(chǎn)品的快速迭代呢？產(chǎn)品體驗與敏捷迭代的平衡成為每一個 UED 設(shè)計師的必備基本功，用戶體驗設(shè)計團(tuán)隊的運(yùn)作模式也從傳統(tǒng)的循序漸進(jìn)、串行的瀑布模式發(fā)展到并行的敏捷模式。

通過敏捷流程為產(chǎn)品的體驗保駕護(hù)航

1. 防止需求不確定，反復(fù)更改

如果沒有需求評審，需求的制定和變更就變得隨心所欲，反復(fù)的修改造成項目的效率低下、項目資源被嚴(yán)重浪費(fèi)，產(chǎn)品開發(fā)無限期拖后，最終錯失良機(jī)。

2. 預(yù)留走查時間，保證設(shè)計質(zhì)量

避免項目時間短根本沒時間去做設(shè)計走查，導(dǎo)致產(chǎn)品上線效果與實際設(shè)計相差甚遠(yuǎn)。設(shè)計流程中預(yù)留出走查的時間，為設(shè)計質(zhì)量以及產(chǎn)品上線的時間提供保障。

3. 確保項目按計劃進(jìn)行

項目立項后，各負(fù)責(zé)人對項目計劃進(jìn)行 WBS 分解，對項目各節(jié)點(diǎn)進(jìn)行排期以及人員安排，確定好設(shè)計流程每個節(jié)點(diǎn)的起止時間，明確項目時間表。保證了每個環(huán)節(jié)的時間的合理性。避免團(tuán)隊成員忙閑不均。

4. 協(xié)調(diào)團(tuán)隊成員

清晰的設(shè)計流程能規(guī)劃好團(tuán)隊成員的角色和切入節(jié)點(diǎn)，在項目前期團(tuán)隊成員能提前獲取到相關(guān)的項目信息，保證項目如期進(jìn)行和團(tuán)隊成員的順利協(xié)作。

5. 責(zé)任清晰，便于管理

清晰的設(shè)計流程是設(shè)計項目執(zhí)行的保證，避免出現(xiàn)問題互相推卸責(zé)任，便于管理者對各個環(huán)節(jié)出現(xiàn)的問題加強(qiáng)管理。

傳統(tǒng)瀑布模式流程

過往的企業(yè)做項目一般都是采用瀑布式流程。瀑布流程的特點(diǎn)是各個節(jié)點(diǎn)按順序執(zhí)行，串行的多個節(jié)點(diǎn)流程模式。只有等待前一個階段的完成才能開始下一階段。這種開發(fā)模式被稱為瀑布模式。由項目經(jīng)理產(chǎn)出需求文檔，設(shè)計師依據(jù)需求文檔來設(shè)計，設(shè)計完成后再給到開發(fā)，開發(fā)完成后提交給測試，測試通過后再發(fā)布上線，這個過程是串行的。

△ 瀑布模式圖

其特征在于：

• 瀑布模式是順序的、串行的、由不同職能部門負(fù)責(zé)，運(yùn)作的職能間相互隔離，只有在前一個階段完成才會進(jìn)入下一個階段，交互和協(xié)作較少。下一階段的負(fù)責(zé)部門無法事先了解前期設(shè)計情況，導(dǎo)致后期造成頻繁反饋和大量修改。
• 設(shè)計師是以需求說明文檔為設(shè)計基準(zhǔn)，需求階段無法提建議。
• 設(shè)計受限于對業(yè)務(wù)需求的理解和轉(zhuǎn)化。
• 項目經(jīng)理嚴(yán)格執(zhí)行項目，他盡可能地控制需求的變更和范圍的漫延，因此無法適應(yīng)產(chǎn)品的變化。衡量的標(biāo)準(zhǔn)是項目的完成性。只要滿足需求文檔上的需求就算完成。
• 需求變更的代價隨著時間的推移越來越大，在分析與設(shè)計階段最小，在開發(fā)階段達(dá)到 10 倍，到了發(fā)布之后達(dá)到 100 倍。

綜上所述傳統(tǒng)的瀑布模式形成了職能間的溝通協(xié)調(diào)縫隙，造成設(shè)計障礙。已經(jīng)不能適應(yīng)當(dāng)今產(chǎn)品研發(fā)的復(fù)雜性和多變性。敏捷模式已經(jīng)成為當(dāng)今主流的產(chǎn)品開發(fā)模式。

UED團(tuán)隊的敏捷設(shè)計流程

UED 設(shè)計團(tuán)隊的設(shè)計流程是指一個設(shè)計項目從開始到結(jié)束包含的各階段的工作步驟。

△ 完整項目流程圖

設(shè)計流程概括了從概念到最終產(chǎn)品上線的全過程，它是指導(dǎo)設(shè)計實踐的模型，同時它也是設(shè)計師跨團(tuán)隊協(xié)作溝通與交流的參考依據(jù)。雖然兩種流程略有不同，但他們的本質(zhì)是相同的。完整項目流程適合全新的產(chǎn)品或是大版本的迭代設(shè)計，小功能流程適合小功能而且要求上線緊急的項目。設(shè)計流程可根據(jù)不同設(shè)計項目的需求進(jìn)行調(diào)整，以達(dá)到優(yōu)化的目的。各階段流程如下：

1. 階段一

研究在項目前期對一切與設(shè)計有關(guān)的內(nèi)容進(jìn)行分析研究等。包括了解產(chǎn)品、用戶研究，分析目標(biāo)用戶群體的特點(diǎn)及需求痛點(diǎn)，競品分析，明確產(chǎn)品的用途及市場類似應(yīng)用概況等，形成設(shè)計策略及設(shè)計方向，定義產(chǎn)品的基調(diào)和特征。

2. 階段二

概念 Demo 設(shè)計，根據(jù)前期的設(shè)計思考，提煉最主要的部分，展開最初的概念 Demo 原型設(shè)計。這是整個設(shè)計過程中第一次通過概念草圖的形式快速地把設(shè)計視覺化展示出來。這個階段的目的在于快速捕捉產(chǎn)品的特征，對產(chǎn)品有一個初步的詮釋、勾勒出產(chǎn)品的大概模型。這個過程不能偏離設(shè)計策略，要與設(shè)計策略保持一致性。概念 Demo 原型完成后進(jìn)行團(tuán)隊內(nèi)部評審。

3. 階段三

產(chǎn)品立項產(chǎn)品經(jīng)理整理好需求文檔、DRD（交互說明文檔）、PRD（產(chǎn)品功能描述）、概念 Demo 于公司評審前幾天發(fā)給各職能負(fù)責(zé)人，并對存在的問題進(jìn)行線下溝通。公司評審會上，產(chǎn)品經(jīng)理進(jìn)行演示和講解。評審?fù)ㄟ^將進(jìn)行項目立項，各職能負(fù)責(zé)人對項目計劃進(jìn)行排期以及人員安排。

4. 階段四

交互設(shè)計產(chǎn)品經(jīng)理產(chǎn)出概念 Demo 原型后，交互設(shè)計師根據(jù) DRD（交互說明文檔）對概念 Demo 進(jìn)一步細(xì)化，設(shè)計操作流程并加上頁面交互效果等。完成后進(jìn)行可用性測試和交互評審。

5. 階段五

視覺設(shè)計由視覺設(shè)計師對低保真原型進(jìn)行風(fēng)格設(shè)計。如果是新產(chǎn)品設(shè)計任務(wù)，需要先確定首頁風(fēng)格，風(fēng)格確定后，視覺設(shè)計師輸出產(chǎn)品設(shè)計規(guī)范，由多人協(xié)作的方式設(shè)計出所有產(chǎn)品頁面的效果圖。完成后進(jìn)行視覺設(shè)計內(nèi)審。內(nèi)審?fù)ㄟ^后提交公司評審。

6. 階段六

前端/后臺開發(fā)前端工程師進(jìn)行效果圖切圖、編寫 html 代碼，增加交互動態(tài)功能，開發(fā) JavaScript 模塊等互聯(lián)網(wǎng)的 Web 開發(fā)，并對頁面的兼容性做調(diào)試，保證頁面在多終端多種屏幕尺寸下都有較好的用戶體驗。

7. 階段七

測試走查產(chǎn)品開發(fā)完成后，測試部在內(nèi)部系統(tǒng)發(fā)起設(shè)計走查任務(wù)，由設(shè)計師對視覺以及交互效果進(jìn)行設(shè)計走查，并把存在的問題提交給測試匯總，測試在內(nèi)部系統(tǒng)提交 bug 給開發(fā)修改，開發(fā)完成后，內(nèi)部系統(tǒng)提醒設(shè)計師驗收，直至問題得到解決。

8. 階段八：上線

產(chǎn)品上線后再次進(jìn)行設(shè)計走查；對上線后的用戶反饋收集，為下一版本的迭代提供依據(jù)。

敏捷開發(fā)模式

△ 敏捷模式圖

敏捷模式是一種快速響應(yīng)需求的產(chǎn)品開發(fā)模式。敏捷模式拋棄了過往順序的、功能特定的方法，采用協(xié)同、并行地工作。在開發(fā)之前就將設(shè)計做得很徹底，避免到了開發(fā)階段通過重構(gòu)來解決問題。敏捷模式由與項目的成功息息相關(guān)的人開專題討論會來驅(qū)動。參加討論會的團(tuán)隊是跨知識領(lǐng)域的，包括公司高層領(lǐng)導(dǎo)、產(chǎn)品經(jīng)理、設(shè)計師、開發(fā)、測試、運(yùn)營等，能從公司戰(zhàn)略、產(chǎn)品戰(zhàn)略、品牌戰(zhàn)略等多個角度進(jìn)行思考，并能快速對項目達(dá)成共同的愿景。設(shè)計師得以利用跨知識領(lǐng)域的智慧，并將其作為設(shè)計靈感的來源，保證產(chǎn)品往正確的方向設(shè)計。

其特點(diǎn)在于：

• 可進(jìn)行更小的功能模塊的迭代，以便更快、更頻繁地改進(jìn)產(chǎn)品。
• 構(gòu)建產(chǎn)品的階段非常短。
• 由多個不同知識領(lǐng)域的團(tuán)隊協(xié)作共同創(chuàng)建愿景，不再是一堆獨(dú)立的個體。
• 設(shè)計方式更靈活，不再局限于按文檔工作。卡片、便簽紙、白板都可以是思考和交流的方式，設(shè)計從項目的開始甚至在項目開始之前就開始，設(shè)計與其它項目活并行，貫穿整個項目生命周期，并且在產(chǎn)品上線后很長時間持續(xù)。
• 體驗設(shè)計與整體業(yè)務(wù)戰(zhàn)略對齊，與產(chǎn)品戰(zhàn)略、業(yè)務(wù)戰(zhàn)略、體驗戰(zhàn)略、產(chǎn)品戰(zhàn)略、品牌戰(zhàn)略、營銷戰(zhàn)略、用戶服務(wù)戰(zhàn)略等緊密互聯(lián)。

1. 產(chǎn)品戰(zhàn)略

產(chǎn)品戰(zhàn)略是對產(chǎn)品的全局性謀劃。產(chǎn)品戰(zhàn)略研究解決的問題是產(chǎn)品的定位，產(chǎn)品的商業(yè)模式以及如何提高企業(yè)競爭能力。產(chǎn)品戰(zhàn)略決定著企業(yè)的勝敗興衰和生死存亡。

2.?業(yè)務(wù)戰(zhàn)略

業(yè)務(wù)戰(zhàn)略是公司的首要愿景，它是業(yè)務(wù)存在的根源。它的存在是為了長期的可持續(xù)成長。業(yè)務(wù)戰(zhàn)略包括核心價值、任務(wù)以及組織的目標(biāo)，它是核心競爭力和奉獻(xiàn)的基礎(chǔ)。

3. 體驗戰(zhàn)略

體驗戰(zhàn)略是用戶參與的活動、事件和交互之和，它會刺激情感上的響應(yīng)，形成感知并最終影響用戶行為。

4.?品牌戰(zhàn)略

品牌戰(zhàn)略受業(yè)務(wù)戰(zhàn)略驅(qū)動，通過潛在用戶的需求、期望和動機(jī)來設(shè)計出吸引人的方案。品牌戰(zhàn)略通過品牌標(biāo)識（名稱、圖形、顏色、吉祥物等）形成品牌形象被公眾所認(rèn)同并成為目標(biāo)用戶的價值符號。

總結(jié)

綜上所述，溝通協(xié)調(diào)是團(tuán)隊管理中的重中之重，上述對設(shè)計團(tuán)隊運(yùn)作特征的分析為團(tuán)隊管理提供了一定的基礎(chǔ)。雖然各 UED 設(shè)計團(tuán)隊的運(yùn)作模式不盡相同，國外的設(shè)計管理學(xué)者也提出了不同的設(shè)計團(tuán)隊運(yùn)作模型，但大多數(shù)都是異曲同工，都在某種程序上體現(xiàn)了敏捷模式的思想。一個好的團(tuán)隊運(yùn)作模式能促進(jìn)設(shè)計團(tuán)隊職能之間的溝通和協(xié)作，使團(tuán)隊運(yùn)作變得更輕松簡單，提升了團(tuán)隊的運(yùn)作效率，實現(xiàn)效率、業(yè)績提升。

歡迎關(guān)注作者的微信公眾號：「UXD全鏈路設(shè)計」