為您的組織帶來更好的設計流程

作為用戶體驗 (UX) 設計師和研究人員，我們從用戶那裡聽到的最常見的抱怨是：

“他們為什麼不考慮我需要什麼？”

事實上，許多組織都有團隊致力於提供用戶和客戶需要的東西。 越來越多的軟件開發人員渴望與 UX 設計師合作，以便編寫客戶將使用和理解的界面。 問題在於，複雜的軟件項目很容易陷入相互競爭的優先事項和對下一步做什麼的困惑中。

結果是糟糕的設計阻礙了生產力。 例如，電子病歷 (EMR) 阻礙了醫療保健的效率。 對這些軟件系統的投訴數不勝數。 波士頓皮膚科醫生、耶魯醫學院校友 Steven Ugent 博士也不例外。

自 2010 年起，Ugent 博士使用了兩套 EMR 系統： 2010 年之前，他每天 5 點 15 分準時完成工作。 自從他和他的同事開始使用 EMR 後，他通常會在晚上多工作半小時到 1.5 小時。 “我不知道有哪個醫生對他們的病歷系統感到滿意。 瘋狂的是，當我使用筆和紙時，我的效率要高得多。”

EMR 系統笨重、不靈活且難以定制。 例如，Ugent 無法將照片直接嵌入到他的圖表筆記中。 相反，他必須打開帶有痣照片的文件夾，然後打開另一個文件夾才能看到文字。 對於在治療患者時嚴重依賴照片的皮膚科醫生來說，這種設置特別麻煩。

Ugent 簡潔地總結了 EMR 的問題：

“設計它 [EMR 系統] 的人不了解我的工作流程。 如果他們這樣做了，他們會設計一個不同的系統。”

對笨重的軟件感到沮喪的不僅僅是醫生。 世界各地的消費者和專業人士都有類似的抱怨：

“為什麼我找不到我需要的東西？”

“他們為什麼這麼難？”

“當我只是想購買這個產品時，為什麼我必須創建一個登錄名。 我給他們錢。 這還不夠嗎？”

笨拙軟件的主要貢獻者是有缺陷的設計過程。 在本文中，我們將概述四個設計過程問題並解釋如何解決它們。

1. 複雜
2. 下一次釋放綜合徵
3. 設計迭代時間不足
4. 將控制權交給外部供應商

1. 複雜性

規模、多個利益相關者以及對複雜代碼的需求是導致大型軟件項目複雜性的眾多因素之一。

然而，有時會忽略複雜的法律和法規。 例如，保險在州一級受到嚴格監管，給在多個州經營的保險公司增加了一層複雜性。 銀行和信用合作社受監管，而公用事業必須遵守州和聯邦環境法。

受 FDA 法規約束的醫療保健產品和軟件帶來了更大的挑戰。 問題不在於規定不合理。 安全至上。 問題是時間、預算和滿足 FDA 要求所需的計劃。

正如在醫療保健領域擁有豐富經驗的 UX 顧問 Jeff Horvath 博士解釋說：“這些要求使編寫測試協議、測試設置、數據收集、分析、質量控制和首先獲得批准進行研究。” 例如，單輪可用性測試從六週（標準可用性測試的合理時間範圍）跳到六個月。 這就是單輪可用性測試。 通常，需要兩輪或多輪測試。

這種嚴格程度對於剛開始與 FDA 合作的公司來說是一個警鐘。 Horvath 不止一次面臨與客戶的艱難對話，他們沒有為滿足 FDA 要求所需的延長時間表和額外預算做好準備。 這很難，但很有必要。 “徹底是值得的，”霍瓦斯說。 2018 年，FDA 僅批准了 11% 的上市前申請。

與傳統軟件產品相比，需要 FDA 合規性的醫療保健軟件對研究人員、設計師和開發人員的要求更高。 例如：

• 用戶體驗研究人員每天只能進行一到兩次可用性測試，而標準軟件每天只能進行五到六次。
• UX 設計師必須高度關注用戶與軟件交互的各個方面。 即使是一次令人困惑的互動也可能導致臨床醫生犯下可能危及患者健康的錯誤。 出於同樣的原因，UI 設計師必須繪製忠實於每次交互的界面。
• 更長的設計和可用性測試時間意味著必須仔細計劃開發人員的編碼工作。 熟練且善意的開發人員通常渴望在新信息可用時立即修改代碼。 雖然這種方法可以在快速迭代中得到良好實踐的組織中工作，但在設計和編碼複雜系統時會帶來風險。

未能管理複雜性可能會產生致命的後果，正如丹妮爾·麥克雷在即將分娩時被送入塔拉哈西紀念醫院時所發生的那樣。 為了緩解她的不適，醫護人員將她連接到一個病人控制的鎮痛機，一個可編程的輸液泵。

八小時後，麥克雷因過量服用嗎啡而被宣布死亡。 這場悲劇的一個主要因素是用於給藥的輸液泵設計有缺陷。 該泵需要 27 個編程步驟。 未能通過設計更直觀的用戶界面來解決這種複雜性導致了不必要的死亡。

解決方案

解決方案是承認並解決複雜性 這點聽起來合乎邏輯。 然而，如上所述，複雜的 FDA 法規常常讓公司領導感到驚訝。 否認是不行的。 未能計劃意味著您的組織可能會落入 2018 年 FDA 拒絕的 89% 的上市前提交。

在進行可用性測試時，用戶體驗研究人員必須採取三個步驟來管理與 FDA 法規相關的複雜性：

1. 主持人（運行可用性測試的人）必須非常專心。 例如，如果 MRI 掃描要求技術人員在使用相關軟件時遵循嚴格的步驟順序，則主持人必須仔細觀察以確定參與者是否完全按照說明進行操作。 如果不是，則該任務被評為失敗，這意味著界面設計和相關文檔都需要修改；
2. 主持人還必須跟踪近距離通話。 例如，參與者最初可能會亂序執行步驟，發現錯誤，然後按照正確的順序恢復。 FDA 認為這是一個近乎未遂的事件，版主必須如此報告；
3. 主持人還必須評估參與者的知識。 她相信她遵循了正確的順序嗎？ 這種信念準確嗎？

2. 下一次釋放綜合症

未能承認複雜性的一個因素是我們稱之為“下一個版本綜合症”的稍後修復的心態。 軟件錯誤不是問題，因為“我們將在下一個版本中修復它。” 強調速度而不是質量和安全，很容易推遲解決難題。

任何參與產品設計和開發的人都必須解決下一次發布綜合症。 兩個例子說明了這一點：

• 我們發現客戶的醫療保健跟踪軟件存在嚴重的設計缺陷。 該公司選擇在不解決這些問題的情況下發布該軟件。 毫不奇怪，客戶不滿意。
• 我們為一家位於美國的大型信用合作社進行了可用性測試。參與者是經驗豐富的財務顧問。 測試揭示了嚴重的設計缺陷，包括混亂的狀態圖標、用途不明確的按鈕以及阻止參與者顯示重要數據的幾乎隱藏的鏈接。 請記住，如果用戶沒有看到它，它就不存在。 當我們報告調查結果時，得到的回應是：“我們將在下一個版本中解決這個問題。” 正如預期的那樣，Web 應用程序並沒有受到好評。 用戶的回應包括：“如果您無意進行更改，為什麼要讓我們審查該應用程序？”

解決方案：拒絕“Fix-It-Next-Time”的心態

解決方案是現在解決嚴重的設計問題。 聽起來很簡單。 但是，您如何說服決策者改變根深蒂固的“以後再修復”的心態？

關鍵是將關於成就的討論從產品交付轉向創造的價值。 例如，花時間根據用戶研究修改設計的團隊可能會看到更好的客戶反應，並隨著時間的推移提高客戶忠誠度。

通過使用定量數據向決策者展示用戶研究與增加收入和積極的客戶體驗之間的直接聯繫來加強案例。

重新定義價值實際上是一種流程改進，因為它建立了一組新的優先事項，可以更好地服務於客戶和貴公司的長期利益。 正如麥肯錫在《設計的商業價值》中報告的那樣：“前四分之一的公司擁抱完整的用戶體驗； 它們打破了物理、數字和服務設計之間的內部障礙。”

3. 設計迭代時間不足

與下一個版本綜合症相關的是，沒有足夠的時間根據研究結果或不斷變化的業務需求來迭代設計。 “我們沒有時間做那個”，這是開發人員和產品所有者的常見說法。 在敏捷環境中工作的設計師經常面臨避免“阻礙”開發團隊的壓力。

開發速度加快，軟件發布。 我們都看到了從令人困惑的電話應用程序到笨重的醫療記錄軟件，再到上面提到的財務顧問繁瑣的用戶界面的結果。

解決方案：設計尖峰

一種解決方案來自編碼世界。 在他的文章“將大圖 UX 融入敏捷開發”中，Damon Dimmick 提出了設計峰值的想法，“讓設計師專注於復雜的 UX 問題的時間泡沫”。 它們通過臨時代替常規衝刺來適應 Scrum 框架。

設計尖峰具有幾個優點：

• 它們允許用戶體驗團隊專注於整體問題，避免陷入有時在單個 sprint 中強調的細化設計問題；
• 它們提供了從高層次探索複雜用戶體驗問題的機會。 如果需要，用戶體驗設計團隊還可以隨時進行以設計為中心的思考，以解決更大的用戶體驗挑戰；
• 通過採用設計尖峰，用戶體驗團隊可以利用開發團隊在敏捷過程中使用的相同靈活性，並將所需的時間用於專注於並不總是適合標準 Scrum 衝刺的設計問題；
• 開發不太可能受到設計決策的影響，可以繼續進行。

自然，設計迭代通常會影響網站、應用程序或軟件產品的某些代碼部分。 出於這個原因，在設計尖峰期間，任何可能受設計尖峰影響的代碼都無法繼續前進。 但是，正如 Dimmick 明確指出的那樣，這種“延遲”可能會通過避免返工來節省時間。 現在編寫代碼然後在團隊同意修改後的設計幾週後重新編寫它根本沒有意義。 簡而言之，推遲一些編碼實際上可以節省時間和預算。

4.過於依賴供應商

解決複雜性、抵制下一個版本綜合症並為迭代留出時間對於有效的設計過程至關重要。 對於許多公司來說，另一個考慮因素是他們與軟件供應商的關係。 這些供應商在開發過程中發揮著重要甚至至關重要的作用。 然而，給予他們過多的影響力會使您難以控制自己的產品。

當然，我們應該尊重同事和供應商，並提出合理的要求。 然而，這並不意味著有必要像我在一家大型金融公司任職期間那樣放棄所有槓桿。

在這家公司擔任 UX 設計師時，我經常遇到這種動態：

經理：“嘿，Eric，你能評估一下我們打算購買的這個索賠軟件嗎？ 我們只是想確保它按預期工作。”

我：“當然，我會在本週末之前將我的初步調查結果發送給您。”

經理：“太好了”

下個星期：

經理：“感謝您的評論。 我看到您發現了三個嚴重的問題：難以找到現有索賠的編號、屏幕上有太多難以閱讀的文本、以及在處理新索賠時難以返回上一屏幕。 這是令人擔憂的。 你認為這些問題會阻礙生產力嗎？”

我：“是的，我認為這些問題會增加理賠中心的壓力和處理時間。 我非常擔心，因為我之前與珍妮特團隊的合作表明，理賠中心的代表已經壓力很大。”

經理：“真的很高興知道。 我剛寄了支票。 我會要求供應商在發貨前解決問題。”

我（在裡面尖叫）：“Nooooooooooooooo！”

這位好心的經理做錯了事。 他在寄出支票後要求更改。 供應商從未做出要求的更改也就不足為奇了。 他們為什麼會？ 他們有他們的錢。

這種情況不僅在那家公司反复上演，而且我在我的 UX 職業生涯中見證了它。

解決方案

解決方案很清楚。 如果供應商產品不能滿足客戶和業務需求，並且您請求的更改在範圍內，請在供應商進行更改之前不要付款。 真的就是這麼簡單。

結論

在這篇文章中，我們確定了質量設計和相應解決方案的四個常見障礙：

1. 複雜的法規和標準
   解決方案是通過為研究和迭代設計設計現實的時間表和足夠的預算來承認和解決複雜性。
2. 發布帶有錯誤的軟件，並承諾稍後修復它們
   解決方案是避免下一次發布綜合症並立即解決嚴重問題。 通過重新定義組織內價值的含義來說服決策者。
3. 設計迭代時間不足
   解決方案是在敏捷開發過程中包含設計峰值。 這些時間泡沫暫時取代了衝刺，讓設計師能夠專注於復雜的用戶體驗問題。
4. 過度依賴供應商
   解決方案是通過扣留最終付款來保留槓桿，直到供應商做出請求的更改，只要這些更改在原始項目範圍內。

第四種解決方案很簡單。 雖然前三個並不容易，但它們是具體的，因為它們可以直接應用於現有的設計過程。 它們的實施不需要大規模重組或數百萬美元。 它只需要致力於提供更好的體驗。