在產(chǎn)品設(shè)計過程中，有種方法叫敏捷開發(fā)，叫瀑布流模式；在體驗設(shè)計中，也有類似的方法——精益體驗設(shè)計。這篇文章，我們就從這種方法的歷史和流程角度，來說說這個方法如何與敏捷開發(fā)相結(jié)合。

01 寫在前面

在上一篇文章中，介紹了在軟件時代無論是產(chǎn)品的體驗設(shè)計還是技術(shù)研發(fā)，其底層的流程管理都是在參照傳統(tǒng)制造業(yè)生產(chǎn)流程下的瀑布流模式。當然，任何產(chǎn)品研發(fā)生產(chǎn)模式都不是完美的，所以也講述了瀑布流模式的三個缺點。

傳統(tǒng)企業(yè)我們需要非常詳盡的設(shè)計，因為我們是有生產(chǎn)環(huán)節(jié)的，需要實體的銷售模式投放市場，這要求設(shè)計不能產(chǎn)生半點差錯，不然成本會很高。

隨著互聯(lián)網(wǎng)的高速發(fā)展，使得用戶對于數(shù)字化產(chǎn)品的迭代更新速度的預(yù)期越來越高，加之軟件SaaS化的浪潮席卷而來。數(shù)字化產(chǎn)品的速度和靈活性取代精度和可預(yù)測性成為極具競爭力的優(yōu)勢。

數(shù)字化產(chǎn)品的研發(fā)生產(chǎn)不再受制于實體產(chǎn)品的生產(chǎn)流程，可以隨時縮短的生產(chǎn)周期要快速適應(yīng)這瞬息萬變的市場，“一次性的完美設(shè)計” 已經(jīng)不再受用。瀑布流的設(shè)計研發(fā)模式顯然在互聯(lián)網(wǎng)時代已經(jīng)無法成為主流的數(shù)字化產(chǎn)品研發(fā)模式，這就迫使企業(yè)不斷尋找可以替代瀑布流模式的新設(shè)計研發(fā)流程管理模式。

數(shù)字化產(chǎn)品研發(fā)流程的主流模式也至此從瀑布流模式進入到敏捷模式，如下圖所示。

從瀑布流到敏捷

以快速迭代為核心產(chǎn)品開發(fā)思維的——敏捷開發(fā)模式，成為互聯(lián)網(wǎng)時代數(shù)字化產(chǎn)品設(shè)計研發(fā)流程的新寵。

02 互聯(lián)網(wǎng)時代的產(chǎn)品研發(fā)流程

敏捷開發(fā)的重點在于快速迭代。它每2-4周發(fā)布一套新的可交付的功能，是隨著時間的推移對產(chǎn)品進行更新，而不是一次性更新。它是基于假設(shè)、實驗、快速發(fā)布和實時測量而建立的。在敏捷開發(fā)中沒有編輯階段，沒有盡善盡美。正如Bre Pettis在2009年所說的，每一次迭代完成都是趨向更加完美。

瀑布流式的工作流程需要“測量兩次，去掉一次”，這比從到處都是 iPhone 的世界中淘汰諾基亞要更快。

從2001年提出的敏捷開發(fā)宣言可以看出，這種開發(fā)模式是比較符合工程師文化的。在敏捷開發(fā)宣言的指引之下產(chǎn)生了多種多樣的敏捷開發(fā)方法，如沖刺和迭代式Scrum方法。

一個典型的數(shù)字化產(chǎn)品的敏捷開發(fā)流程如下圖所示，如下圖所示。

典型的敏捷開發(fā)流程

在敏捷開發(fā)大行其道的今天，我這里就不詳細介紹這樣產(chǎn)品研發(fā)流程細節(jié)。只是在這樣一種主流的產(chǎn)品開發(fā)流程中，發(fā)現(xiàn)了一個小問題：

“對于2周一迭代的產(chǎn)品發(fā)布周期，體驗設(shè)計團隊幾乎沒有時間去執(zhí)行他們傳統(tǒng)的設(shè)計流程。在敏捷研發(fā)流程中，體驗設(shè)計變成了一個絆腳石?！?/p>

面對不能改變的阻礙，大多數(shù)產(chǎn)品研發(fā)團隊會簡單地放棄用戶體驗。取而代之的是，他們雇用了能夠在兩周內(nèi)快速交付的年輕平面設(shè)計師。這些設(shè)計師并不是真正的用戶體驗從業(yè)者，至少不是傳統(tǒng)意義上的，但他們對于以用戶為中心的設(shè)計是有基本認知的，至少能避免犯最糟糕的錯誤。

或者是選擇使用設(shè)計外包，因為設(shè)計外包中的設(shè)計師一般都是優(yōu)先滿足開發(fā)需要，成為團隊里面的編外“美工”。

這種情況與產(chǎn)品開發(fā)團隊也可以合作順利。

敏捷假設(shè)的前提是Product Backlog（待開發(fā)事項）是已經(jīng)清晰定義的需求，大部分敏捷開發(fā)實踐中更關(guān)注快速迭代的環(huán)節(jié)，而忽視用戶故事、需求分析、設(shè)計規(guī)范；快速的迭代時間使得用戶體驗設(shè)計師沒有時間深入思考、執(zhí)行體驗設(shè)計過程；敏捷認為細節(jié)將通過迭代自行解決，現(xiàn)狀是細節(jié)從未被解決，如下圖所示。

在敏捷開發(fā)中被忽略的部分

敏捷開發(fā)終究是一種開發(fā)方法，并不利于體驗設(shè)計師的工作。

03 精益體驗設(shè)計（Lean UX）

精益創(chuàng)業(yè)是一種發(fā)展商業(yè)模式與開發(fā)產(chǎn)品的方法，由埃里克·萊斯在2011年首次提出。根據(jù)埃里克·萊斯之前在數(shù)個美國新創(chuàng)公司的工作經(jīng)驗，他認為新創(chuàng)團隊可以借由整合「以實驗驗證商業(yè)假設(shè)」、「快速更新、迭代產(chǎn)品」、以及他所提出的最簡可行產(chǎn)品（簡稱MVP）及「驗證式學(xué)習(xí)」，來縮短他們的產(chǎn)品開發(fā)周期。

精益創(chuàng)業(yè)方法論產(chǎn)生的背景是根據(jù)統(tǒng)計，在全球范圍內(nèi)創(chuàng)業(yè)公司失敗率高達90%，其中排在第一位的原因是找不到市場：“沒有人需要他們做出來的產(chǎn)品”。

精益創(chuàng)業(yè)的方法早在上世紀90年代的硅谷就已經(jīng)嶄露頭角。但是精益（lean）這個詞最早可以追溯到豐田的精益生產(chǎn)理論。豐田的精益生產(chǎn)理論是為了高效生產(chǎn)商品，但沒有回答應(yīng)該產(chǎn)生什么商品的問題。

精益體驗設(shè)計是 Jeff Gothelf 通過精益創(chuàng)業(yè)方法論，試圖解決UX在敏捷中實踐存在的問題。讓UX能夠在敏捷開發(fā)略漸清晰的流程里，基于用戶的反饋快速迭代設(shè)計。

什么是精益體驗設(shè)計？ 使用協(xié)作、跨職能合作的方式，不依賴完備的文檔，強調(diào)讓整個團隊對真實產(chǎn)品體驗達成共識，從而盡快把產(chǎn)品的本質(zhì)表現(xiàn)出來，如下圖所示。

精益體驗設(shè)計流程

首先了解一下經(jīng)驗證認知的基本單元–精益循環(huán)。我們建立假設(shè)，并根據(jù)假設(shè)建立一個“待驗證假設(shè)”，隨即對它進行定量評估獲得測試數(shù)據(jù)，這些數(shù)據(jù)包含了終端用戶對于”待驗證假設(shè)”的認知及價值衡量，通過數(shù)據(jù)學(xué)習(xí)驗證其是否正確，如果答案肯定，開發(fā)過程向前推進；如果答案否定，則返回假設(shè)原點，修正假設(shè)后再次循環(huán)直到“待驗證假設(shè)”肯定，這就是一個循環(huán)。

傳統(tǒng)的設(shè)計是基于需求的，而精益體驗設(shè)計是基于成果的。

可以看出，Lean UX強調(diào)了快速設(shè)計，快速用戶反饋與迭代。通過精益體驗設(shè)計流程，讓體驗設(shè)計團隊很好的融入到敏捷開發(fā)流程中，如下圖所示。

精益體驗設(shè)計與敏捷開發(fā)流程

似乎通過精益體驗設(shè)計流程，體驗設(shè)計現(xiàn)在能夠很好的與敏捷的節(jié)奏相協(xié)調(diào)，成為其流程的一部分，推動產(chǎn)品的快速開發(fā)迭代。

然而，在實際的項目推進中，體驗設(shè)計發(fā)現(xiàn)了新的問題。設(shè)計師發(fā)現(xiàn)在他們真正了解正在構(gòu)建的東西之前，自己要承受巨大的壓力去做一堆在沖刺中積壓的工作。因此，大量的開發(fā)周期都被這些根本無法成為最終產(chǎn)品一部分的功能所消耗。以至于在項目管理界，精益體驗設(shè)計或者敏捷開發(fā)在不理想的條件下的嘗試，是以大量浪費和返工而聞名的。

在一個成熟的產(chǎn)品中，可以搜集到大量的用戶反饋，這對推動精益用戶體驗的迭代周期起到了很好的作用。這就是為什么精益用戶體驗幾乎是所有已建立的產(chǎn)品團隊的行業(yè)標準。沒有人會去改變它。

但是，在大量的創(chuàng)業(yè)公司中，特別是從0到1設(shè)計開發(fā)一款全新產(chǎn)品的時候，但新產(chǎn)品的定義往往不是那么清晰，相對有點模糊，且無法得到大量有效的用戶反饋的時候，精益體驗設(shè)計流程就會崩潰。

所以，對于很多創(chuàng)意公司的體驗設(shè)計團隊來說，精益體驗設(shè)計流程并不是一個很好的選擇，我們需要對體驗設(shè)計流程繼續(xù)探索新的設(shè)計流程，以便更好適應(yīng)創(chuàng)業(yè)公司對于敏捷的產(chǎn)品研發(fā)模式的需要。

04 體驗設(shè)計沖刺

對于創(chuàng)業(yè)公司來說，因為規(guī)模和投資等因素，設(shè)計開發(fā)資源是寶貴的，我們必須要把“好鋼用在刀刃上”。建立一套新的敏捷的體驗設(shè)計流程，用于提高數(shù)字化產(chǎn)品的研發(fā)效率和響應(yīng)速度。設(shè)計師面臨一種窘境。谷歌風(fēng)投創(chuàng)建了設(shè)計沖刺流程（Design Sprint）一種在5天內(nèi)回答關(guān)鍵業(yè)務(wù)問題的過程。設(shè)計沖刺是一個高度結(jié)構(gòu)化的創(chuàng)新周期，在這個周期內(nèi)，團隊回答特定問題，確保始終以用戶為中心。在做出任何昂貴承諾之前，無需等待發(fā)布最小化產(chǎn)品，設(shè)計沖刺就可以幫助你了解一個想法是否是好的，如下圖所示。

體驗設(shè)計沖刺的敏捷性

設(shè)計沖刺為團隊提供了一條學(xué)習(xí)的捷徑，無需開發(fā)和發(fā)布。那么一個典型的體驗設(shè)計沖刺流程是以5天為一個項目節(jié)點，強調(diào)在跨團隊的五天封閉式共創(chuàng)工作中完成方案設(shè)計和驗證，用最少的資源，最快的速度提高產(chǎn)品在投入市場中的成功率，如下圖所示。

典型的設(shè)計沖刺流程及活動

看到這個設(shè)計流程圖，你也許會說“這個和我們傳統(tǒng)的設(shè)計流程一樣啊，只不過這個設(shè)計流程只給了五天的時長！”，那么你就差不多答對了。它的不同，或者說天才的部分就在于它就是一個低保真度的傳統(tǒng)用戶體驗流程，就像藝術(shù)杰作和簡單素描的區(qū)別，但它卻很有效。

設(shè)計沖刺的目標就是收集目前所有關(guān)于問題的調(diào)研，將它的核心分成多個群組，并瘋狂地進行頭腦風(fēng)暴。頭腦風(fēng)暴是透過以人為中心設(shè)計的透鏡進行篩選，而這些被團隊所投的想法將留存下來。設(shè)計師接著搭建低保真原型（往往就一天的時間），這原型也足夠能夠用去測試潛在的用戶。如果測試的結(jié)果不錯的話，它能幫助設(shè)計師搭建高保真的模型，因此來驅(qū)動精益設(shè)計/敏捷的循環(huán)流程。

設(shè)計沖刺側(cè)重于設(shè)計構(gòu)思和驗證，是日常例行工作之外的特殊工作狀態(tài)。設(shè)計沖刺的輸出將作為開發(fā)團隊的輸入，并不涉及開發(fā)流程的變化。

設(shè)計沖刺不主張傳統(tǒng)開放式的頭腦風(fēng)暴，認為集體討論的模式無法深入思考且效率低下，其更主張獨立思考繪制草圖后再混合修改調(diào)整。?

05 寫在最后

然而隨著互聯(lián)網(wǎng)時代敏捷模式在企業(yè)中的不斷發(fā)展，越來越多的開發(fā)人員、體驗設(shè)計師對當前敏捷模式的產(chǎn)品設(shè)計研發(fā)流程提出了質(zhì)疑，其中最大質(zhì)疑就是：

敏捷開發(fā)流程真的可以確保向客戶交付的產(chǎn)品具備卓越體驗嗎？

該系列文章的最后一篇，會給大家介紹當前敏捷開發(fā)面臨的挑戰(zhàn)，在后敏捷開發(fā)時代，體驗設(shè)計流程的應(yīng)對之策。