數字化產品體驗設計流程簡史(2/3)

0 評論 936 瀏覽 1 收藏 15 分鐘

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

01 寫在前面

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

傳統企業我們需要非常詳盡的設計,因為我們是有生產環節的,需要實體的銷售模式投放市場,這要求設計不能產生半點差錯,不然成本會很高。

隨著互聯網的高速發展,使得用戶對于數字化產品的迭代更新速度的預期越來越高,加之軟件SaaS化的浪潮席卷而來。數字化產品的速度和靈活性取代精度和可預測性成為極具競爭力的優勢。

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

數字化產品研發流程的主流模式也至此從瀑布流模式進入到敏捷模式,如下圖所示。

從瀑布流到敏捷

以快速迭代為核心產品開發思維的——敏捷開發模式,成為互聯網時代數字化產品設計研發流程的新寵。

02 互聯網時代的產品研發流程

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

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

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

一個典型的數字化產品的敏捷開發流程如下圖所示,如下圖所示。

典型的敏捷開發流程

在敏捷開發大行其道的今天,我這里就不詳細介紹這樣產品研發流程細節。只是在這樣一種主流的產品開發流程中,發現了一個小問題:

“對于2周一迭代的產品發布周期,體驗設計團隊幾乎沒有時間去執行他們傳統的設計流程。在敏捷研發流程中,體驗設計變成了一個絆腳石。”

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

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

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

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

在敏捷開發中被忽略的部分

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

03 精益體驗設計(Lean UX)

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

精益創業方法論產生的背景是根據統計,在全球范圍內創業公司失敗率高達90%,其中排在第一位的原因是找不到市場:“沒有人需要他們做出來的產品”。

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

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

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

精益體驗設計流程

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

傳統的設計是基于需求的,而精益體驗設計是基于成果的。

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

精益體驗設計與敏捷開發流程

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

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

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

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

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

04 體驗設計沖刺

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

體驗設計沖刺的敏捷性

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

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

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

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

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

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

05 寫在最后

然而隨著互聯網時代敏捷模式在企業中的不斷發展,越來越多的開發人員、體驗設計師對當前敏捷模式的產品設計研發流程提出了質疑,其中最大質疑就是:

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

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

作者:井然,公眾號:井然聊體驗

本文由 @井然 原創發布于人人都是產品經理。未經作者許可,禁止轉載。

題圖來自 Unsplash,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!