敏捷用戶體驗：如何將用戶體驗和產品設計融入敏捷

DevOps 通常被定義為圍繞公司軟件和系統開發的流程、操作、方法、工具和文化。

但是工程並不是在真空中運作的。 藍圖、想法、設計和概念來自決定佈局、流程和交互性的產品設計專家。 這些是共享 DevOps 目標和期望結果的非工程個人和團隊。

DevOps 不僅僅是開發人員如何與 IT 連接、如何管理基礎設施以及如何改進框架。 這是關於認識到有多少團隊真正參與了軟件開發過程，他們的角色和工作是如何交織在一起的，並找到更好的方法來確保每個人都參與進來。

當產品和創意團隊設計軟件或系統時，開發人員和工程架構師希望參與其中。 但在當前 DevOps 的定義中，這在哪裡？ 產品、用戶體驗和創意團隊希望在工程過程中保持參與，但許多方法將它們排除在外。 這些是我們需要打破的舊筒倉。

您的客戶只會看到您的用戶體驗 (UX)。 他們看不到你有多少開發人員，或者你是敏捷還是精益。 他們不知道正在使用哪些 DevOps 工具。 貴公司的用戶體驗就是產品，它可以成就或毀掉你。 他們想知道是誰建造了這塊垃圾。 在如此激烈的競爭和人們樂於卸載應用程序或離開網站的情況下，您會與拋棄您的客戶再次獲得機會嗎？

敏捷很少培訓用戶體驗或與用戶體驗專家合作

許多工程團隊經常發現用戶體驗是孤立的並且難以協作。 UX 似乎並不精益，許多敏捷風格都排除瞭如何使用 UX 的細節。 一些敏捷方法特別建議描述功能的產品所有者“足夠好”。

SAFe Agile 錯誤地認為解決 UX 孤島的最佳方法是完全排除它們。 SAFe“授權敏捷團隊”做他們自己的“精益用戶體驗”。 隨著越來越多的公司了解整合 UX 專家和完整 UX 流程的價值，SAFe 正朝著錯誤的方向前進。

敏捷培訓和書籍中缺乏解釋 UX 及其流程的情況導致世界各地的團隊排除或盡量減少專業產品設計師的參與。

• 當您錯誤地認為 UX 只是在頁面上繪製框時，很容易假設“我可以完成這項工作”。 就像許多美國偶像的試鏡者確信他們是這個星球上最好的歌手一樣，大多數產品經理和工程師都自認為在 UX 方面表現出色。 這通常意味著他們相信自己擅長佈置屏幕。 但是，當本文解釋了真正進入 UX 工作的內容時，您將看到 UX 專家不會將製作線框圖的開發人員視為應該被賦予 UX 任務的人。
• Scrum 上的書籍建議，如果 UX 專家成為瓶頸，她應該培訓非 UX 角色來完成她的工作。 這種類型的決策很少被建議用於軟件開發中的其他角色。 沒有人會希望未經培訓或缺乏經驗的開發人員進行編碼，即使在訓練營或閱讀有關編程的書籍之後也是如此。 我們絕不會建議如果開發人員成為瓶頸，她應該培訓項目經理進行一些編碼。
• 錯誤地認為 UX 是一項藝術 (UI) 工作的招聘經理會聘請藝術家來從事 UX 工作。 UX 學位和 UI 學位之間沒有教育重疊。 天賦往往不會重疊； 擅長 UX 的人可能是一個糟糕的藝術家，反之亦然。 為“UX/UI”招聘通常會為您提供一位出色的藝術家，而他的 UX 經驗、專業知識、流程或教育程度最低。

那些只關注底線的人會喜歡通過將 UX 任務分配給可能缺乏 UX 教育、經驗、專業知識、技能或天賦的個人來削減預算。 但這是短視的，可能導致生產力、效率、文化、產品和客戶滿意度低下。

將專家 UX 專家納入敏捷的重要性

2018 年底，管理諮詢公司麥肯錫公司發布了“設計的商業價值”，這是一份他們對 300 多家公司進行的研究的報告。

他們發現，“設計是公司脫穎而出的唯一途徑。” 當競爭對手擁有接近的功能集時，是什麼讓他們脫穎而出？ 設計有時被認為只是美學或使它看起來像我們品牌的原因。 但是當與“UX”一起使用時，設計意味著功能的架構以及關於屏幕、步驟、流程、佈局、流程、組織和菜單的決策。

UX 是持續改進過程的一部分，始終尋求更好地了解用戶，選擇和設計最符合他們需求的功能和產品，解決他們的痛點，並為他們帶來有意義的創新。

麥肯錫還報告說，“公司必須在整個過程的早期就全面接受設計，而不是將其視為以後適應的小工具。” 假設對用戶體驗的關注是可以在發布產品後最小化、排除或完成的事情的團隊採取了錯誤的方法。

麥肯錫收集了定量數據，發現採用 UX 設計的公司在 5 年內創造了 32% 的收入和 56% 的股東回報。 宣布您的公司“以用戶為中心”是不夠的。 您必須通過集成 UX 從業者和流程，從規劃和產品組合向下到開發和 QA 來走這條路。

有和沒有 UX 的軟件開發過程

如果您的公司在軟件設計和開發過程中不包括 UX 專家，那麼您的過程很可能如下圖所示。

客戶、產品經理、首席執行官或有遠見的人會告訴工程師他們想要什麼。 工程構建它，測試它，並在登台或生產服務器上獲取它。 有遠見的人看到它，你不知道，他們不快樂。 他們想要不同的東西或改變了主意。

然後，工程必須循環回到起點，找出這個人現在想要什麼，構建、測試並交叉手指，這就是魅力。

如果您的團隊中有 UX 專家，那麼這個過程就完全不同了。 有遠見的人帶著想法、數據和客戶痛點來到 UX。 UX 在其以用戶為中心的設計過程中循環執行任務，然後在工程編寫一行代碼之前測試這些概念。 這可以確保我們正在考慮構建的產品或功能是為我們的目標客戶正確執行正確的想法。

測試可能會暴露一些缺陷，這使得 UX 可以迭代並經常再次測試。 在完成 UX 流程後，您就可以將經過全面審查的設計交付給工程部門。

如果有人在此過程中改變了主意，則該人會與 UX 交談，而不是將其作為對開發人員的更改請求。 UX 在他們的過程中會產生干擾，如果沒有 UX 參與設計、決策和對真實或原型客戶的測試，則不會將任何內容髮送到工程部門。

在這一點上改變主意並不是災難，因為在這一點上改變主意的成本是微乎其微的。 工程還沒有交付藍圖，他們還沒有開始，也沒有什麼可重建的。 UX 會迭代他們的設計，並且可以進行用戶測試，以確保這些想法與客戶群良好、緊密地匹配。 改變主意會消耗時間，但對預算的總體影響很小。

用戶體驗有一個正式的過程

以用戶為中心的設計 (UCD) 是一個形式化的過程，包括指導 UX 專家研究、設計、原型、測試真實或原型用戶的任務，然後根據測試中的學習進行迭代。

專注於其中一些領域，我們從需求和關於功能和項目的早期討論開始。 當 UX 首次獲得需求和其他項目信息時，立即開始協作非常重要。 UX 以後不應該發現他們設計了無法構建的東西。

當產品或項目經理決定功能和優先級時，首先引入 UX 員工或經理。 可以刪除對用戶沒有價值的項目，從而節省大量時間和金錢。 這就是最大化未完成的工作量發揮作用的地方。 當產品和工程通過減少或刪除功能或整個項目來減少工程的工作量時，他們應該支持 UX。 然而，很多時候，項目都有自負，團隊成員經常將​​用戶體驗排除在這些早期對話之外，以便項目獲得資金。

研究是用戶體驗工作的重要組成部分。 它不是以用戶為中心而不涉及用戶。 統計和定量數據很棒，但無法替代採訪用戶、深入了解他們並獲得定性數據。 UX 想知道為什麼而不僅僅是什麼。

用戶體驗研究還通過將每個人圍繞角色、目標客戶的原型統一起來，讓團隊成員達成共識。 根據對用戶的採訪，我們匯總了我們學到的知識，並將每個人歸結為 6 個或更少的角色。 是什麼激勵了他們？ 他們需要什麼？ 我們公司、產品或服務的機會在哪裡？

人物角色的最佳用途是將它們包括在任何地方。 產品基於角色（和良好的數據）想像功能。 基於角色的用戶體驗設計。 QA 測試同時想像他們是這些角色。 營銷可以添加他們的人口統計和其他細節，但他們也應該考慮品牌聲音、社交媒體和廣告如何與角色對話。

人物角色幫助非 UX 工作人員擺脫“嗯，我喜歡這種方式”或“CEO 喜歡這種方式”。 我們正在為這些目標客戶進行設計，如果您或 CEO 不適合這些角色，那麼 UX 不會受到自我或個人偏好的影響。 UX 必須以客戶為中心。

信息架構與層次結構、結構和分類法有關。 這可能是網站導航，也可能是產品在電子商務數據庫中的分類方式。 我們希望確保客戶能夠通過類別、元數據和過濾器輕鬆找到產品。

交互設計，有時也稱為體驗設計，是大多數人在想像 UX 時想到的。 這些是線框和原型，是設計和概念的藍圖。 這些將顯示流程、佈局、菜單、交互、路徑、選擇等等。

UX 原型就像被賦予生命的線框。 它們是可點擊的交互式數字模型。 我們不必編寫代碼； 我們有軟件可以幫助我們快速創建這些。 尋找更逼真原型的公司使用 Axure，因為它具有條件邏輯、變量、移動滑動手勢、拖放和各種事件觸發器。 您可以為幾乎任何類型的設備製作原型。

UX原型設計用於：

• 頭腦風暴
• 合作
• 迭代
• 探索解決方案
• 向投資者推銷（針對初創公司）
• 測試原型以查看解決方案是否與目標受眾良好連接。
• 向開發人員或其他隊友提供交互式模型，這通常比文檔頁面更受歡迎（並且沒有可點擊的模型）。

現在它進入用戶測試，也稱為可用性測試，它發生在 UX 過程中和工程編寫一行代碼之前。 您必須測試概念和設計，以確保想法和執行對目標客戶來說非常棒。

用戶測試將揭示任何缺陷，讓 UX 有機會迭代想法，這在這一點上並不昂貴，因為沒有任何東西可供工程構建或重建。

UX 在交付給工程部門之前運行測試有 5 個關鍵原因：

1. 最好地利用工程的時間和資源。 如果您希望測試參與者看到工程師創建的成品，您必須構建並測試它的錯誤。 如果用戶體驗測試帶來了所需的更改，開發人員將不得不重新構建，QA 將不得不重新測試。 如果 UX 測試顯示該概念的更大失敗，這可能意味著工程的時間完全被浪費了，因為這不是最終會在任何地方結束的代碼。 這個概念必須重新思考、重新設計和重新測試。
2. 在幕後迭代。 當公司只是構建它、交付它、對其進行迭代、構建並再次交付時，這意味著客戶會看到各種版本。 他們正在看到正在進行的工作並觀看正在製作的香腸。 這通常是一種令人沮喪和困惑的體驗，需要客戶不斷重新學習不斷發展的系統。 最好在 UX 流程的幕後進行迭代，並讓測試人員清楚這是一個原型或演示版本。
3. 監測和測量。 如果一個新概念被實時發布，用戶體驗研究人員沒有很好的方法來觀察人們使用它、向他們提問並獲得用戶體驗所需的反饋類型，以確定某件事是否已經準備好或是否需要再次迭代。 UX 總是想知道為什麼，質量，而不僅僅是什麼或多少。 用戶如何消費、轉化、參與等？ 避免正確的用戶體驗測試會使診斷和修復問題或客戶痛點變得更加困難。
4. UX 測試是物有所值的。 用戶體驗測試並不是一筆巨大的開支。 一些第三方測試工具要求每位測試參與者的費用低於 100 美元，有些則要求每年至少投入數千美元。 考慮到公司對軟件開發過程的總體預算以及早期測試反饋的重要性，這些費用並不大。 與讓程序員構建我們可能不得不撤消或再次構建的東西相比，幾輪用戶測試的成本幾乎總是更低，速度更快。
5. 用戶測試解決了爭論。 如果您的公司不允許用戶體驗專家對產品的設計方式做出最終決定，那麼當對應該構建和發布的內容有不同的想法時，您可能會發現用戶體驗與產品、工程或利益相關者發生衝突。顧客。 或者，如果 UX 有兩個強有力的想法，他們想知道哪個更好地與客戶聯繫呢？ 這裡的解決方案是用戶測試。

UX 可以對概念進行原型設計。 最好將競爭歸結為最好的兩個設計，特別是如果您已經可以在想法和團隊成員之間找到折衷方案。 這意味著我們不是在測試 UX 想要什麼、產品喜歡什麼、工程主管喜歡什麼、scrum master 認為聽起來是個好主意還是 CEO 的生活伴侶喜歡什麼。

用戶測試讓客戶暢所欲言，並幫助您找到功能或產品的正確方向。 它通過為團隊提供可靠的定量和定性數據來解決爭論，這些數據告訴每個人哪個想法可能帶來最大的客戶滿意度。

不涉及用戶，就不是以用戶為中心的設計。 這意味著我們與真實或原型客戶進行研究和測試，而不是猜測、假設或“只是運送它”。 我們必須確保我們“剛剛發布”的內容已經通過用戶測試進行了審查，並且是對一個好主意的出色執行。

當 UX 被規避或減少時會發生什麼？

Skype 最近宣布，旨在使其更像 Snapchat 的 2017 年重新設計失敗了。 用戶不想要、不需要或不喜歡這些新功能。 強烈的反對聲音足以讓 Skype 在 2018 年宣布他們將再次重新設計 Skype。 （https://devops.icu/skypes-coming-redesign-of-their-last-redesign/）

用戶體驗專家會在他們流程的許多步驟中知道這些功能可能是不需要的或失敗的。 對目標用戶的研究可能很快表明他們不希望 Skype 成為 Snapchat。 在這個早期終止項目或轉向可能會為 Skype 節省數百萬美元以及負面新聞和客戶疏遠。

即使用戶體驗研究被繞過，在用戶身上測試用戶體驗原型也會清楚地表明，客戶不希望 Skype 朝這個方向發展。 由於 UX 仍在進行中，工程人員還沒有編寫任何代碼。 這可以節省大量時間、金錢和人力資源，慶祝簡單性和工程不需要做的工作。

敏捷用戶體驗過程

記住敏捷宣言原則。 您的首要任務是通過構建有價值的軟件來讓客戶滿意。 為（UX）員工提供他們需要的環境和支持，相信他們能夠完成工作。 最大化未完成的工作量。 對良好設計的持續關注可以提高敏捷性。

正在向前發展的項目需要為用戶體驗提供一個巨大的跑道，以便可以開始適當的研究、設計和測試。 不要邀請 UX 參加您的啟動會議，並要求他們必須在幾天內交付最終線框，這讓他們感到驚訝。 那不是用戶體驗。

不要將其視為大設計前期（BDUF），這是一個旨在讓人們畏縮並宣稱這是我們必須擺脫的東西的術語。 當一個項目或功能很大或很新時，UX 有必要循環通過大部分（如果不是全部）以用戶為中心的設計過程。 對於 UX，更大功能的最小可能部分是用戶的工作流程或過程。 如果我們設計和測試更小的東西，我們就會冒著無法全面了解真實用戶體驗的風險。

例如，如果我們正在設計用戶註冊和購買的流程，我們不能只設計密碼選擇字段並將其提交給工程。 如果用戶體驗是小塊的，那麼什麼時候會測試整個過程？ 如果不測試整個流程，我們就無法知道用戶對整個流程的反應……這意味著必須在進行可用性測試之前設計整個流程。

在功能、故事或修復很小的地方，UX 從業者可以完成以用戶為中心的設計過程的子集並更快地工作。 UX 總是會盡可能快地進行，但優秀的 UX 專家會盡其所能避免犧牲正在完成的工作的質量。 在快與好的戰鬥中，用戶體驗總是會選擇好而不是快……你也應該這樣做。

預算和時間表阻礙了 UX 獲得快速反饋和迭代。 用戶體驗從業者總是想要反饋和改進產品的機會，旨在設計真正適合客戶的產品。 儘早將 UX 從業者引入投資組合管理和規劃，使 UX 能夠估計他們需要的時間和預算； 這些不應該是後來的意外或衝突的原因。

UX 從業者是敏捷團隊的一員

將您的 UX 設計師嵌入敏捷團隊。 邀請他們發布計劃、站立會議、回顧會議以及可能討論 UX 的每次會議。 允許 UX 在發布計劃期間估計他們的時間，這樣就不會對 UX 任務所需的時間感到意外。 不要在沒有他們的情況下做出決定。 如果您的 UX 團隊成員錯過了會議，請等到您可以親自、通過聊天、電子郵件或您公司使用的任何方法找到他們。

將問題、歧義或錯誤分配給 JIRA 中的 UX 隊友或您使用的任何錯誤跟踪系統。 確保用戶體驗問題與其他問題在同一個系統中； 如果您將 VersionOne 用於其他所有內容，請不要在 Trello 板上丟棄 UX 問題。

在 UX 有長長的跑道之後，如果此功能或產品需要它，最佳實踐是讓 UX 比工程提前 2 個或更多 Sprint。 UX 可以和你一起衝刺。 將大量技術故事或技術債務修復到積壓中。 這樣一來，如果 UX 的創意和循環流程運行較晚或需要更多衝刺，開發人員就可以真正變得敏捷。 他們可以切換到產品或工程優先考慮的一些容易實現的目標，而不是等待用戶體驗。

還要考慮資源、分配和人員配備。 根據項目的大小，分配給一位用戶體驗設計師的項目不超過 3 個。 如果您有獨立的、專業的 UX 研究人員，他們也進行測試和分析，請分配一名研究人員到不超過 3 名 UX 設計師。 如果你的 UX 從業者是所謂的 T 型，這意味著她在研究、測試和其他 UX 子專業方面也有資格和優秀，那麼請確保她不會因為被分配到太多項目而意外成為瓶頸。

測量結果

沒有客戶滿意度，您可能就沒有客戶。 您可以使用客戶滿意度指標來確定通過集成 UX 來改進您的流程是如何產生積極變化的。

• 更少的投訴
• 更好的應用評論
• 更高的應用評分
• 更少的支持票
• 更少的呼叫中心呼叫
• 社交帖子的更積極語義
• 更多應用安裝，更少卸載
• AOV（平均訂單價值）增加
• 更高的轉化率

您還可以衡量所需的 DevOps 目標，例如上市時間和修復之間的時間。 在您的 UX 革命前後，故事、項目和史詩需要多長時間才能進入市場？ 當開發人員最終確定 UX 設計作為他們估計的基礎時，開發人員的時間估計可能會更準確，而不是根據故事或您現在正在做的任何事情進行工作。

如果 UX 提供藍圖並且正在遵循這些藍圖，我們希望通過減少意外更改和重建來減少工程工作量。 早期更好的 UX 設計，以後更少的修復。

敏捷 UX 是一項不僅物有所值的投資

許多項目經理將用戶體驗視為可以刪除或減少的預算線，而招聘經理對將用戶體驗任務與另一個角色結合起來的想法感到興奮。 然而，越來越多的公司了解到，沒有什麼可以替代由訓練有素且經驗豐富的 UX 專家進行的適當 UX 流程的投資。

The Lean Startup 的作者 Eric Ries 問道：“如果我們發現自己在構建沒人想要的東西怎麼辦？ 在那種情況下，如果我們按時按預算完成有什麼關係？” 即使您的組織沒有使用精益方法，警告仍然適用。 當我們的目標是為客戶構建正確的東西、提高客戶滿意度並開發具有高客戶價值的功能時，DevOps 的預期結果與此相呼應。

了解您的客戶，讓您的客戶參與到流程中，並針對他們的真實需求和偏好進行構建，最終比時間表、預算、框架和工具更重要。 相信如果你正確地執行正確的想法，就會有收入。