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

01 寫在前面

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

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

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

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

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

從瀑布流到敏捷

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

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

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

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

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

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

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

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

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

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

B端究竟需要什么样的产品经理？

B端产品经理都是以提升供应侧的工作效率为目的，所以B端需求主要是以业务问题为导向。 这个是B端产品比较重要的一点，B端产品是服务于一个主体 ...

查看详情 >

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

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

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

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

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

03 精益體驗設計（Lean UX）

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

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

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

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

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

精益體驗設計流程

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

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

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

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

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

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

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

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

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

04 體驗設計沖刺

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

體驗設計沖刺的敏捷性

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

典型的設計沖刺流程及活動

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

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

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

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

05 寫在最后

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

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

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