如作者所說，數字化産品已經逐漸成為企業與客戶互動的主戰場之一，其中，數字化産品體驗設計流程與産品開發流程可以說是一對“老冤家”。在接下來的文章裡，作者就将介紹數字化産品場景下的體驗設計流程發展曆史，一起來看。
01 寫在前面
大家知道我一直專注于企業級體驗領域，關注企業如何向目标人群傳遞卓越的整體體驗，其中的核心人群體驗就是客戶體驗。在客戶體驗中很重要的組成部分就是産品體驗，特别是我們已經進入數字化時代，會産生了越來越多的數字化産品，是以數字化産品也逐漸成為企業與客戶互動的主戰場之一。
最近因為教育訓練的關系，關注到數字化産品體驗設計流程與産品開發流程這對“老冤家”，是以後面會通過三篇短文介紹一下在數字化産品場景下，體驗設計流程的發展曆史。
在數字化産品語境裡，體驗設計是依托于技術的進步和發展的，體驗設計是技術的“表”，是技術與人互動的界面。流程是項目管理的一種工具，他的核心作用之一就是通過流程讓各個崗位達成一緻，使得大家的工作規範化、标準化和可追溯。
是以，體驗設計流程的演進史其實是跟随着技術開發流程的發展而不斷演進，如下圖所示。
體驗設計流程的演進
02 軟體時代的産品研發流程
在這個時代數字化産品的主流是軟體産品，相對于傳統的工業産品，軟體的生産是一種全新的生産方式，當然需要一種全新的流程管理。那軟體産品如何進行流程管理必然是需要解決的問題，之前我也講過，任何的創新都不是憑空想象出來的，都是有參照物。是以軟體開發流程必然會參照當時工業品的生産流程，提取出其核心的流程—按照工序的流水線工序流程。最終推出了軟體開發的典型流程—瀑布流開發流程。
瀑布流開發流程把項目分解為有限的定義、開發三個階段。每一個階段都有序執行，并且依賴于前一個階段的輸入，像瀑布一樣漸進往下，如下圖所示。
瀑布流模式
瀑布流開發流程有其優點：步驟清晰明确，文檔完整，目标明确。
例如，我們看蘋果公司的macOS軟體系統，就是典型的瀑布流開發流程，每年都會有固定的新版本上線，如下圖所示。
典型瀑布流模式-macOS
03 軟體時代的體驗設計流程
最初，軟體開發過程是沒有使用者體驗設計這一概念的。後來研發極客們發現他們在電腦前噼裡啪啦敲完代碼釋出的産品，使用者并不買賬，抱怨難用。其中最出名的“抱怨”是唐.諾曼的《設計心理學》系列叢書，他在書中列舉了一系列不好用的案例，分析了背後的原因，并提出了“使用者體驗”這個詞。他也是蘋果公司的首位體驗官。
在早期競争不激烈的階段，開發者似乎還可以無視使用者需求我行我素。但随着技術的進步，同類産品越來越多時，簡單易懂體驗好就顯得尤為重要了。于是開發者們開始重視使用者體驗，并從傳統工業/藝術設計、心理學、統計學等專業招聘人才，研究如何做出好用的産品。
随着體驗設計的發展，出現了越來越多的設計流程模型，目前行業逐漸實踐并固化了UCD（以使用者為中心的設計）的設計方法和流程。UCD是一種設計思想，強調在進行産品設計、開發、維護時從使用者的需求和使用者的感受出發，圍繞使用者為中心進行産品設計、開發及維護，而不是開發完成後一股腦地丢給使用者，讓使用者去了解、适應産品，如下圖所示。
傳統的各類體驗設計流程
在各種以“UCD”思想為指導的體驗設計流程中，其本質上都是一種瀑布流模式。在該模式中，一個産品團隊提前做好所有的學習和準備，然後再進入到即使是最簡單的原型階段。
他們會花幾個月，甚至幾年來做調研，然後研究結果會指導設計團隊的執行。産品需求會在設計開始前進行“封鎖”，而同樣的，設計也會在開發前進行封鎖。這個過程是不可逆的，一直到2.0版本後才會進行修改。這就是瀑布流的工作方式，如下圖所示。
體驗設計流程關鍵節點
而各類基于UCD思想的體驗設計流程，大緻借鑒了瀑布流式開發的階段劃分，将使用者納入整個産品的規劃、研究、設計、開發、測試驗證的過程。
傳統的體驗設計流程往往會告訴設計師們，大家的體驗設計工作肯定要包含以下八個關鍵步驟。
- 進行研究，并定義問題
- 對發現的問題進行分類
- 建立使用者畫像和使用者旅程圖
- 運用構思練習來産生想法
- 建立原型并進行測試
- 将最終的原型拿到真實環境中疊代
- 釋出産品
- 基于使用者的回報回到步驟
就連UX領域的經典著作《使用者體驗的要素》也遵循瀑布模式，根據明确的需求自下而上地建構執行。分為了——戰略、功能、結構、架構、表現層，并就每個層級如何進行以使用者為中心進行設計提供詳細的說明，如下圖所示。
Jesse James Garrett《使用者體驗的要素》
在軟體時代，體驗設計在瀑布流模式下中運作的很好，體驗設計與産品開發都基于一套瀑布流模式進行流程管理，雖偶有摩擦但也是“歲月靜好”。
04 靈活時代體驗設計遇到的挑戰
其實在軟體時代的瀑布流模型也非一種完美的産品設計研發流程，其存在三個大的問題：
（1）産品驗證滞後
産品驗證滞後是瀑布式開發過程中最讓産品頭疼的部分，産品人員必須等到項目程序尾聲的時候才可以對産品進行驗證，也就是說在投入大量的人力物力之前所有的産品概念都是無法得到充分的驗證的，驗證滞後也意味着所有階段不能出現任何纰漏否則将導緻整體項目變得失控。
（2）需求變更困難
在瀑布式開發過程中，任何對之前決策的修改與調整都将打亂原本的開發流程，大量已完成工作需要重新評估與推進嚴重耗費整個團隊的精力，産品經理在跟蹤使用者需求的過程中，難免會産生需求的變更，如果發生需求變更那修改需求必定在所難免，隻是早晚的問題，而且延遲到下一個版本開發也隻是一個權宜之計，無論從成本或是使用者體驗上考慮肯定都是越早改動越好；
（3）難以适應變幻的市場
瀑布式開發過程中的所有工作都嚴重依賴于流程與文檔，任何一點改動都會牽一發而動全身，也使得産品經理壓力倍增，産品經理在這一流程下送出給開發的所有産品必須確定通過嚴格的驗證且沒有缺陷，另一方面釋出過後産品也會提心吊膽，随時做好快速線上修複的準備。
在網際網路發展前期，市面上的數字化産品還是主要以軟體類産品為主，使用者對其需求也沒有那麼的變化莫測，是以以上三個問題在當時并不算緻命問題。
然而，随着網際網路的高速發展下，使得使用者對于數字化産品的疊代更新速度的預期越來越高，加之軟體SaaS化的浪潮席卷而來。數字化産品的速度和靈活性取代精度和可預測性成為極具競争力的優勢，瀑布流的設計研發模型的三個問題就變成影響企業生死攸關的大問題。這就迫使企業不斷尋找可以替代瀑布流模式的數字化産品設計研發新流程管理模式，由此誕生了新的研發模式——靈活開發。
05 寫在最後
但是在企業的數字化産品研發流程進入靈活模式的時候，體驗設計團隊之前以瀑布流模式為基礎的各類體驗設計流程就開始變得“水土不服”，設計師面臨一種窘境。
而對于兩周一疊代的産品功能釋出的開發周期，體驗設計團隊幾乎沒有時間去執行他們傳統的基于UCD理念的體驗設計流程。在靈活裡，體驗設計變成了一個絆腳石。
在後面的文章我會繼續詳細介紹在靈活時代、後靈活時代，體驗設計如何通過對工作流程的創新來不斷适應數字化産品研發的需要。
以上。
本文由 @井然 原創釋出于人人都是産品經理。未經作者許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協定
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。