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

0 評論 1925 瀏覽 0 收藏 12 分鐘

如作者所說,數字化產品已經逐漸成為企業與客戶交互的主戰場之一,其中,數字化產品體驗設計流程與產品開發流程可以說是一對“老冤家”。在接下來的文章里,作者就將介紹數字化產品場景下的體驗設計流程發展歷史,一起來看。

01 寫在前面

大家知道我一直專注于企業級體驗領域,關注企業如何向目標人群交付卓越的整體體驗,其中的核心人群體驗就是客戶體驗。在客戶體驗中很重要的組成部分就是產品體驗,特別是我們已經進入數字化時代,會產生了越來越多的數字化產品,所以數字化產品也逐漸成為企業與客戶交互的主戰場之一

最近因為培訓的關系,關注到數字化產品體驗設計流程與產品開發流程這對“老冤家”,所以后面會通過三篇短文介紹一下在數字化產品場景下,體驗設計流程的發展歷史。

在數字化產品語境里,體驗設計是依托于技術的進步和發展的,體驗設計是技術的“表”,是技術與人交互的界面。流程是項目管理的一種工具,他的核心作用之一就是通過流程讓各個崗位達成一致,使得大家的工作規范化、標準化和可追溯。

所以,體驗設計流程的演進史其實是跟隨著技術開發流程的發展而不斷演進,如下圖所示。

體驗設計流程的演進

02 軟件時代的產品研發流程

在這個時代數字化產品的主流是軟件產品,相對于傳統的工業產品,軟件的生產是一種全新的生產方式,當然需要一種全新的流程管理。那軟件產品如何進行流程管理必然是需要解決的問題,之前我也講過,任何的創新都不是憑空想象出來的,都是有參照物。所以軟件開發流程必然會參照當時工業品的生產流程,提取出其核心的流程—按照工序的流水線工序流程。最終推出了軟件開發的典型流程—瀑布流開發流程。

瀑布流開發流程把項目分解為有限的定義、開發三個階段。每一個階段都有序執行,并且依賴于前一個階段的輸入,像瀑布一樣漸進往下,如下圖所示。

瀑布流模式

瀑布流開發流程有其優點:步驟清晰明確,文檔完整,目標明確。

例如,我們看蘋果公司的macOS軟件系統,就是典型的瀑布流開發流程,每年都會有固定的新版本上線,如下圖所示。

典型瀑布流模式-macOS

03 軟件時代的體驗設計流程

最初,軟件開發過程是沒有用戶體驗設計這一概念的。后來研發極客們發現他們在電腦前噼里啪啦敲完代碼發布的產品,用戶并不買賬,抱怨難用。其中最出名的“抱怨”是唐.諾曼的《設計心理學》系列叢書,他在書中列舉了一系列不好用的案例,分析了背后的原因,并提出了“用戶體驗”這個詞。他也是蘋果公司的首位體驗官。

在早期競爭不激烈的階段,開發者似乎還可以無視用戶需求我行我素。但隨著技術的進步,同類產品越來越多時,簡單易懂體驗好就顯得尤為重要了。于是開發者們開始重視用戶體驗,并從傳統工業/藝術設計、心理學、統計學等專業招聘人才,研究如何做出好用的產品。

隨著體驗設計的發展,出現了越來越多的設計流程模型,目前行業逐漸實踐并固化了UCD(以用戶為中心的設計)的設計方法和流程。UCD是一種設計思想,強調在進行產品設計、開發、維護時從用戶的需求和用戶的感受出發,圍繞用戶為中心進行產品設計、開發及維護,而不是開發完成后一股腦地丟給用戶,讓用戶去理解、適應產品,如下圖所示。

傳統的各類體驗設計流程

在各種以“UCD”思想為指導的體驗設計流程中,其本質上都是一種瀑布流模式。在該模式中,一個產品團隊提前做好所有的學習和準備,然后再進入到即使是最簡單的原型階段。

他們會花幾個月,甚至幾年來做調研,然后研究結果會指導設計團隊的執行。產品需求會在設計開始前進行“封鎖”,而同樣的,設計也會在開發前進行封鎖。這個過程是不可逆的,一直到2.0版本后才會進行修改。這就是瀑布流的工作方式,如下圖所示。

體驗設計流程關鍵節點

而各類基于UCD思想的體驗設計流程,大致借鑒了瀑布流式開發的階段劃分,將用戶納入整個產品的規劃、研究、設計、開發、測試驗證的過程。

傳統的體驗設計流程往往會告訴設計師們,大家的體驗設計工作肯定要包含以下八個關鍵步驟。

  1. 進行研究,并定義問題
  2. 對發現的問題進行分類
  3. 創建用戶畫像和用戶旅程圖
  4. 運用構思練習來產生想法
  5. 建立原型并進行測試
  6. 將最終的原型拿到真實環境中迭代
  7. 發布產品
  8. 基于用戶的反饋回到步驟

就連UX領域的經典著作《用戶體驗的要素》也遵循瀑布模式,根據明確的需求自下而上地構建執行。分為了——戰略、功能、結構、框架、表現層,并就每個層級如何進行以用戶為中心進行設計提供詳細的說明,如下圖所示。

Jesse James Garrett《用戶體驗的要素》

在軟件時代,體驗設計在瀑布流模式下中運行的很好,體驗設計與產品開發都基于一套瀑布流模式進行流程管理,雖偶有摩擦但也是“歲月靜好”。

04 敏捷時代體驗設計遇到的挑戰

其實在軟件時代的瀑布流模型也非一種完美的產品設計研發流程,其存在三個大的問題:

(1)產品驗證滯后

產品驗證滯后是瀑布式開發過程中最讓產品頭疼的部分,產品人員必須等到項目進程尾聲的時候才可以對產品進行驗證,也就是說在投入大量的人力物力之前所有的產品概念都是無法得到充分的驗證的,驗證滯后也意味著所有階段不能出現任何紕漏否則將導致整體項目變得失控。

(2)需求變更困難

在瀑布式開發過程中,任何對之前決策的修改與調整都將打亂原本的開發流程,大量已完成工作需要重新評估與推進嚴重耗費整個團隊的精力,產品經理在跟蹤用戶需求的過程中,難免會產生需求的變更,如果發生需求變更那修改需求必定在所難免,只是早晚的問題,而且延遲到下一個版本開發也只是一個權宜之計,無論從成本或是用戶體驗上考慮肯定都是越早改動越好;

(3)難以適應變幻的市場

瀑布式開發過程中的所有工作都嚴重依賴于流程與文檔,任何一點改動都會牽一發而動全身,也使得產品經理壓力倍增,產品經理在這一流程下提交給開發的所有產品必須確保通過嚴格的驗證且沒有缺陷,另一方面發布過后產品也會提心吊膽,隨時做好快速線上修復的準備。

在互聯網發展前期,市面上的數字化產品還是主要以軟件類產品為主,用戶對其需求也沒有那么的變化莫測,所以以上三個問題在當時并不算致命問題。

然而,隨著互聯網的高速發展下,使得用戶對于數字化產品的迭代更新速度的預期越來越高,加之軟件SaaS化的浪潮席卷而來。數字化產品的速度和靈活性取代精度和可預測性成為極具競爭力的優勢,瀑布流的設計研發模型的三個問題就變成影響企業生死攸關的大問題。這就迫使企業不斷尋找可以替代瀑布流模式的數字化產品設計研發新流程管理模式,由此誕生了新的研發模式——敏捷開發。

05 寫在最后

但是在企業的數字化產品研發流程進入敏捷模式的時候,體驗設計團隊之前以瀑布流模式為基礎的各類體驗設計流程就開始變得“水土不服”,設計師面臨一種窘境。

而對于兩周一迭代的產品功能發布的開發周期,體驗設計團隊幾乎沒有時間去執行他們傳統的基于UCD理念的體驗設計流程。在敏捷里,體驗設計變成了一個絆腳石。

在后面的文章我會繼續詳細介紹在敏捷時代、后敏捷時代,體驗設計如何通過對工作流程的創新來不斷適應數字化產品研發的需要。

以上。

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

題圖來自 Unsplash,基于 CC0 協議

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

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