保存產品 X——設計思維案例研究

已發表: 2022-03-11

什麼是設計思維？

想像一下，你有一個想法。您想出了一個巧妙的應用程序，您認為它可以解決您的業務問題。目前市場上沒有相同的解決方案，最相似的解決方案並沒有真正按照客戶期望的方式工作。

當您的願景還很新鮮時，您開始考慮想到的第一個基本問題：“完成它需要多長時間？”

而且由於我們很少會發現自己的預算和時間是無限的，因此很快就會出現第二個問題：“我要花多少錢來做這件事？”

這兩個都是製造產品的基本和關鍵問題，但通常它們恰恰是錯誤的開始。

相反，首先要問的最重要的問題是： “我可以為我的用戶創造什麼價值？”

為了更好地理解項目的範圍、需求和時間安排，我們可以使用一種稱為“設計思維”的方法，它可以在產品的“發現階段”幫助我們。這正是我們不僅需要了解什麼可以製造出出色的產品，還需要了解我們應該如何以及是否應該這樣做的時候。這種創造性和實驗性的方法有助於我們更好地理解如何創造不僅有用，而且最重要的是有用的東西。

設計思維過程特別有用，因為它產生了獨特而具體的結果：知識。

這種方法的使用範圍更廣，但出於本設計思維案例研究的目的，我們將只關註一個特定領域——軟件產品開發。

設計思維理論

在深入研究設計思維的實際應用和我的應用經驗之前，讓我們更深入地了解一下設計思維的過程。

設計思維是一種提供基於解決方案的方法來解決問題的方法。它側重於理解用戶的觀點，以人為本。這種方法的強大之處在於可以快速測試一個想法、解決方案或增強功能是否可以為我們的客戶帶來真正的結果。整合來自不同領域（營銷、心理學、設計、商業）的不同方法、工具和技術，設計思維的目的是將用戶置於我們必須解決的問題的中心。

該方法的目標是“找到用戶本身並定義其需求”，並通過找到這些需求，創建真正有用的解決方案或產品。為了實現這一目標，整個概念分為六個設計思維階段。

移情：此階段的目標是通過搜索和收集有關他們業務的信息來了解您的客戶。在這個階段，我們可以使用幾種不同的工具，例如訪談、焦點小組、觀察和調查。
定義：在這個階段，我們從移情階段收集和分類信息。在這裡，我們定義了用戶角色和用戶旅程。
構思：使用上述信息，團隊在這裡構思解決方案。沒有愚蠢或錯誤的想法！一切都必須表達和記錄。
原型：在這個階段，創造了一些有形的東西，這將使您能夠在現實生活中驗證您的想法。不要過度複雜化並儘快創建此 MVP。
測試：在現實生活中與實際用戶驗證您的想法。得到反饋。就如何改進它提出問題。
實施：這是將所有收集到的知識轉化為最終產品的階段。

如果在閱讀完這篇文章後，您可能會想：“這很棒，但這將如何幫助我快速將我的應用程序變為現實。” 為了使這一點更加具體，我將根據我的個人經驗回顧一個案例研究，該案例受益於設計思維過程。

應用設計思維 - 真實案例研究

簡介：X計劃

前段時間，我發現自己在與一位企業家、幾位經理和許多想法在房間裡飛來飛去。他們的直接競爭對手最近發布了一個新的應用程序，壓力是顯而易見的。該公司希望在市場上推出一些新產品，以避免失去競爭對手。

他們準備了一份文件，其中包含一些要求，對產品應該是什麼樣子以及應該花費多少的模糊概念。

“我們必須以更低的價格效仿別人的做法，”營銷總監說。 “我們必須創建一個更實用的系統，以簡化用戶旅程，”另一位經理補充道。 “我們必須改變我們收集信息的方式，簡化它並將我們的流程與第三方整合，”另一位說。 “這將需要我們幾個月的時間，”技術經理搖了搖頭，他在腦海中將所有這些請求翻譯成數百小時的代碼來實現。

雖然我不能透露所有項目細節，但我可以透露該產品是集線器通信軟件。該軟件管理不同的渠道（電子郵件到 SMS、傳真到 VoIP），它是為 Web 和移動平台創建的。該產品最初是在幾年前創建的，但它的可用性很差。在發佈時，競爭對手在用戶體驗方面遙遙領先。此外，他們有一個出色的移動應用程序，在移動應用程序商店中佔有一席之地。

X 公司是一家傳統的流程驅動型公司，熟悉傳統項目。它過去曾運行過一些敏捷項目，但對於創建 MVP 並在市場上對其進行測試的想法是新的。更值得注意的是，他們害怕未知。如果新的 MVP 會對他們的客戶用戶群產生不良或不可預測的影響怎麼辦？這種缺乏控制並沒有激發信心。

上述會議和隨後的會議並沒有明確定義實際要實現的產品是什麼。我們只知道我們必須盡快擊中目標。

然而，隨著項目的進展和競爭對手開始獲得牽引力，公司的同意正在鞏固。大多數人都同意這樣的想法：“我們不能推出半成品，我們需要一個從一開始就可以工作的產品。”

儘管最初有些困惑和恐懼，但這是一個機會，可以了解什麼會給他們的用戶群帶來真正的價值，並可能通過製作精簡的輕量級產品來吸引更多用戶。

這促使該公司尋找他們以前從未嘗試過的方法，以便按時構建完整的產品，即使它在發佈時只有基本功能。我們決定使用設計思維過程並專注於真正為最終用戶帶來價值的事物，從而通過只為客戶帶來必要的東西來擊敗競爭對手。

階段 1 - 移情

移情階段：此階段的目標是通過搜索和收集有關其業務的信息來了解您的客戶。 在這個階段，我們可以使用幾種不同的工具，例如訪談、焦點小組、觀察和調查。

從最字面意義上說，同理心是理解和分享他人情緒的能力。在設計思維中，同理心是“對你為之設計的人的問題和現實的深刻理解”。

我們的第一步是確保最高薪人士的意見（也稱為 HiPPO）不會凌駕於其他人的意見之上。因此，我們與經理和創始人一起編制了一份可能參與決策過程的利益相關者名單。

在為期一天的會議中，我們編制了第一個可以直接聯繫的 30 個名稱（在員工、職能經理和客戶之間）的列表，然後我們還挑選了 4000 名客戶的目標受眾（約佔他們經常性客戶用戶的 10%）根據）。

我們試圖通過包括性別分佈、行業和其他數據點方面的多樣性來盡可能“規範化”我們的目標客戶群。為了增加額外的複雜性，要採訪的樣本的實際位置都被劃分到不同的城市，在某些情況下是國家。我們現在有了聯繫點來進行訪談和問卷調查。

該小組被組織成遠程進行採訪，遵循一套腳本化的問題和一些基本規則：

在面試過程中，嘗試使用“5 個為什麼”技巧。
嘗試理解每個行為背後的主要“什麼、如何、為什麼”。
確保受訪者使用網絡攝像頭，並且與攝像頭有足夠的距離，以便能夠至少部分包含肢體語言。
記錄所有採訪，以防將來需要看到。

我們準備面試問題的目的是了解應該增強或消除哪些主要功能，以便我們可以快速構建響應用戶需求的新版本。

對於第二組用戶，我們在 Google 表單中準備了一系列問題。我們選擇了多項選擇題，其中一些制定了開放式問題以促進用戶的更多互動，包括一個要求用戶試用剛剛在封閉測試中提供的新版本產品的問題。

為了組織整個信息收集過程，我們使用了使團隊能夠更輕鬆地收集信息的遠程工具，包括 Skype、Zoom、Google Forms 和一個數字看板，我們可以在其中放置我們所有的活動並跟踪它們的狀態。

訪談的第一個結果令人鼓舞，因為受訪者願意就係統的弱點和優勢提供反饋。

然而，第一批的問卷答案卻沒有那麼令人興奮：在所有發送的 300 封電子郵件中，只有 5 人完成了問卷。

對這個結果感到失望，我們準備嘗試新的方式讓用戶群參與進來，這時一位銷售經理向我們提出了一個想法：

“我認為他們不會回復任何電子郵件，他們不習慣與我們互動。但是，如果我們與所有續約到期的人溝通並給他們一點激勵，我相信他們會幫助我們。”

這個想法很簡單，但很特別。幾個小時後，我們有了一個新的用戶列表（3800），保持了主流和極端之間的相同劃分。然而，這些用戶將被“強制”與系統交互，因為他們更新的時間很近。

這一次，他們被要求回答一系列問題，參與測試並獲得續訂折扣。粘貼完成，新機型首次交付時，超過 70% 的用戶回复並完成了問卷。

在迭代和更改了一些問題之後，並且感謝一些願意多次採訪的用戶，我們準備更清楚地定義我們的用戶群。

第 2 階段 - 定義

定義階段：在這個階段，我們從移情階段收集和分類信息。 在這裡，我們定義了用戶角色和用戶旅程。

定義的字典含義是確定一個概念的同一性和本質性質。在我們的例子中，我們想要定義以下內容：

我們的理想客戶
他們的問題
他們的問題的解決方案
我們必須解決的客戶的需求和恐懼

在設計思維術語中，定義階段是您分析觀察結果並將其綜合成您已確定的核心問題的階段。

我們有足夠的數據庫來了解真正的問題是什麼。除了在移情階段收到的反饋外，它還包含 X 公司員工強調但從未向管理層指出的要點，以及從未考慮過的優勢、劣勢和其他問題。

下一步是創建我們的用戶角色。在這個頭腦風暴階段，我們參與了整個擴展團隊。頭腦風暴階段總是遠程進行，使用視頻會議系統和工具實時跟踪角色及其創作。

對於每個角色，我們確定了他們的傳記、他們的技術方法、他們對社交媒體的使用、首選品牌、他們的需求和想法，並推測了他們的客戶旅程。

在此之後，我們選擇了常見的客戶用戶角色，並從採訪和調查中獲得了一組完整的數據。這是弄髒我們的手的正確時機。

在定義階段，我們嘗試將諸如“我們需要一種能夠將我們的銷售額提高 10% 的產品”之類的問題的通用定義轉換為更具體的解決方案，例如：“35 至 45 歲之間的男性和成年女性在辦公室工作的人需要接收具有法律效力的通信，以確保發送者確實是他們所說的那個人。”

在項目過程的這一點上，我們已經完成了圍繞用戶的頭腦風暴會議、假設的解決方案，並對每一種可能的創新保持開放的態度。 “唯一愚蠢的想法是從未表達過的想法”是口頭禪。

在很短的時間內，牢記我們的主題是誰，我們清楚地了解了什麼對我們的用戶有用，以及我們應該在客戶旅程中解決哪些需求和恐懼。

然後，我們開始構建“用戶故事地圖”，這使我們能夠對用戶的流程進行分類，映射到主題。對於每個角色，我們定義了一組活動、故事和任務，我們假設他們必須在旅程中完成。這樣做，我們可以快速測試我們的想法並了解它是否滿足核心需求。如果是這樣，我們可以比其他人更快地將其推向市場，這對於我們的競爭對手每天都變得越來越成功至關重要。

第 3 階段 - 構思

構思階段：使用上述信息，團隊在這裡構思解決方案。 沒有愚蠢或錯誤的想法！ 一切都必須表達和記錄。

離定義更進一步的是構思階段，關鍵是形成真正的概念和解決方案，而不僅僅是抽象的定義。

在設計思維術語中，構思是“您通過草圖、原型製作、頭腦風暴、頭腦寫作、最壞可能的想法以及大量其他構思技術等會議產生想法和解決方案的過程。”

我們的團隊完全偏遠，所以我們決定在生產材料和審查材料時以精益的方式工作。例如，設計師和團隊的其他成員一致認為，為了盡可能快，最好的解決方案是從紙上的圖紙開始，並在小組中分享他們的照片。只有這樣我們才能在 Balsamiq 或 Axure 中製作出最有趣的設計。

對於製作的每個草圖，我們從用戶那裡收集信息，我們定義了一組解決方案，然後我們回到這些用戶（只要可能，盡可能頻繁地）與他們一起測試過程和結果。

第 4 階段 - 原型

原型設計階段： _ 在此階段，創建了一些有形的東西，這將使您能夠在現實生活中驗證您的想法。不要過度複雜化並儘快創建此 MVP。 _

在原型階段，終於到了讓我們的定義和想法變為現實的時候。原型是提議產品的第一個原始模型，而這正是我們打算構建的。根據設計思維標準，原型階段是您創建實際產品的廉價、按比例縮小的版本，以研究先前階段的解決方案。

從我們的旅程開始將近 10 天后，我們到達了關鍵時刻，與開發團隊開會，我們有機會檢查我們的假設和估計。在與開發團隊進行了一次諮詢和定義之後，我們權衡了這些故事，並了解到開發工作的主要工作將是後端系統的開發以及與現有遺留系統的接口。除此之外，我們還意識到創建前端系統將是一個更短的練習。因此，我們決定使用系統中已經存在的組件創建一個前端原型以節省時間。

我們有 3 天的時間來準備原型的第一個版本。這個原型必須盡可能地反映產品並保持必要的功能。

3 天后，我們準備好了原型的第一個版本。它有“假”數據，反映了我們打算創建的軟件的行為。缺少一些附屬元素，但該狀態下的軟件在視覺上代表了計劃總內容的很大一部分。

在兩週的工作結束時，我們有了可以與實際用戶一起嘗試和測試的軟件。當他們瀏覽我們的原型時，我們使用用戶體驗監控軟件來分析熱圖和用戶注意力。

第 5 階段 - 測試

測試階段-在現實生活中與實際用戶驗證您的想法。 得到反饋。 就如何改進它提出問題。

在定義、構思和原型階段之後，終於到了看看我們的產品在現實生活中是否真的有效的時候了。在設計思維方面，測試意味著使用在原型設計階段創建的最佳解決方案對完整的產品進行試驗。

在我們的案例中，測試階段不僅發生在最後，而且是一個不斷循環的反饋和迭代，只要有可能。在每個完成的步驟結束時，我們試圖從用戶或客戶那裡獲得反饋，然後說服自己進入下一階段。

一旦原型完成，就應該與盡可能廣泛的受眾一起測試它，並與他們一起檢查它如何有效地滿足他們的需求，了解他們的看法，並了解它是否實現了他們的目標。

測試階段特別包括一個演練原型，用戶可以在其中看到新的工作流程並執行操作，以及團隊直接觀察用戶的一些會話，同時跟踪他們的響應。一個簡單的問卷用於收集平台中特定功能的轉化率，要求用戶從 1 到 10 對該過程進行評分。

測試階段後來擴展到整個團隊，甚至擴展到組織外部的一些個人（客戶和用戶），他們在早期的會議期間願意同意就係統的實施提供反饋。

這項測試的結果令人鼓舞。 X 公司的利益相關者不僅能夠看到模型，還能夠第一次嘗試和“觸摸”產品。擴展團隊有機會在兩週內測試和驗證他們的假設並隨著時間的推移進行更正。

現在正在等待最後的測試：向用戶開放並了解接下來會發生什麼。

第 6 階段 - 實施

實施階段：這是將所有收集到的知識轉化為最終產品的階段。

我們有數據、想法、角色和我們的第一個有形原型。是時候捲起袖子開始開發了。我們有一個半月的時間來實施我們的新系統。

我們定義了一組規則來在短時間內實現我們的 MVP：

我們將只構建我們定義的內容，而不添加新功能。
我們將專注於主要業務目標。
我們將在團隊中使用敏捷方法來管理工作量。

為了及時完成該項目，我們引入了一些新的團隊成員，他們在發現階段的早期階段就沒有參與過該項目。

我們添加了前端開發人員、後端開發人員和設計師。團隊的新成員在遠程工作，在項目期間不可能把他們都帶到同一個房間裡，所以我們確保我們有合適的工具來保持溝通。

為管理工作而製定的流程是敏捷流程。我們把剩下的時間分成幾個短衝刺，每天遠程開會，白天通過 Slack 更新，交流想法，互相幫助解決問題。

我們沒有在某個地方存儲完整的文檔，但在精神上我們都有一套全面的行動、共同的願景和團隊之間的目標。我們都開始認為用戶角色是一個真正的用戶，有他自己的需求和問題。一旦我們的團隊開始有了一致的願景，我們就開始定義需要做什麼以及何時完成項目。

這些活動在用戶故事地圖中進行了概述，以維護角色的原始證據和我們想要提供給產品的流程。

用戶故事地圖是通過三個明確的步驟創建的：識別活動、識別完成活動所需的步驟以及與每個相關的故事/任務列表。我們根據優先級（必須、應該、可以）對故事進行排序，這決定了將哪些組件納入產品。

由於團隊共享清晰的願景，以及我們採用的方法使團隊能夠在沒有上級管理層直接指導的情況下保持正軌，團隊從實施一開始就能夠快速推進。在該項目中工作的每個人都想到了設計思維階段的問題：

我們平台內的每個用戶應該執行什麼操作，他們想要實現什麼？
這些用戶應該採取哪些步驟來達到最終目標？
他們以前有哪些痛點，我們應該如何避免它們？

這使我們的團隊能夠做出自己的微觀決策，並引導產品朝著最終目標前進。

在產品最終投入生產之前，我們在每個 sprint 結束時對正在進行的工作進行了兩次審查，並在路徑結束時對進行中的工作進行了一次最終發布審查。我們使用最後一個 sprint 來準備運行和啟動產品所需的基礎設施。

最後，再次邀請使用過我們舊產品的用戶試用新版本。我們的產品在表達了製作它的想法的會議後兩個月發布了生產。該產品有效，用戶開始使用它，我們逐步向該工具發送更多新用戶，而不是舊用戶。 A/B 測試向我們表明他們更喜歡新產品，並且該項目在公司中被接受為巨大的成功。

更重要的是，最終接受了一種設計思維方法。我們相信這將產生良好而持久的影響，並使他們能夠在未來製造出更好的產品。

結論

在整個案例研究中，我們展示瞭如何在時間和預算有限的情況下將設計思維方法應用於現實生活中的問題。

我們沒有使用更傳統的方法並按順序生產事物，而是選擇迭代六個設計思維階段。同情。定義。醞。原型。測試。實施。這成為我們的口頭禪，使我們能夠生產出非常受歡迎的產品。

使用設計思維可以節省時間，進而節省項目成本。我們並沒有致力於數百萬個不同的功能，而只是針對少數幾個經過深思熟慮的行動，這些行動對團隊中的每個人都很清楚。最重要的是，我們能夠提供用戶需要的產品和價值。

使用設計思維過程幫助我們在許多不同的領域：

從項目管理的角度來看，它使我們能夠清楚地定義項目的範圍並防止範圍蔓延。
從業務角度來看，它使我們能夠選擇能夠為業務帶來真正價值的功能。
從開發的角度來看，它幫助我們在開始構建之前就明確了我們必須構建的目標。
從團隊的角度來看，它涉及所有團隊成員，讓他們能夠有效地合作，並在流程的每個部分聽取他們的意見。

當我們開始設計思維過程時，客戶對此表示懷疑，但當我們完成並從客戶那裡得到反饋時，我們立即清楚地表明，我們制定的步驟已經幫助我們實現了一些本來非常困難或否則不可能。這受到了客戶的重視，並成為他們內部應對未來挑戰的旗艦項目。