如何使用 HEART 框架改善軟件用戶體驗

隨著客戶對軟件的期望變得更加精細，用戶體驗投資對於產品成功和業務成功至關重要。 然而，提倡用戶體驗改進有時會非常困難，尤其是在沒有明確的指標來幫助激勵組織採取行動的情況下。 為了幫助更好地證明這些投資，我們針對 UX 指標的 HEART 框架創建了本指南，谷歌的研究人員推廣該框架以同時推動用戶成功、產品成功和業務成功。 使用 HEART 幫助明確優先考慮哪些 UX 指標，並建立合理的業務案例以對用戶體驗進行再投資。

HEART框架是什麼？

HEART 框架是一種可操作的結構，用於識別軟件產品中用戶體驗 (UX) 改進的潛在領域。 首字母縮寫詞“HEART”代表五類用戶體驗：Happiness、Engagement、 A doption 、 Retention和T ask success。 在本綜合指南的後面，我們將更深入地定義每個類別。

每個 HEART 類別都包含三個不同的組成部分，以幫助推動行動和衡量進展：目標、信號和指標。

• 目標是定性的業務目標
• 信號是與目標相關的定性最終用戶行為
• 指標是信號的定量測量

在後面的部分中，我們提供了目標、信號和指標的定義和示例。

我們可以將此框架可視化為 HEART 圖表，類似於我們稍後將分解的真實產品示例：

為什麼 HEART 框架首先存在？

HEART 框架由 Google 的 Kerry Rodden 、 Hilary Hutchinson 和 Xin Fu 於 2010 年發布，作為對稱為 PULSE 的舊產品健康框架的回應（“Page views, Uptime, Latency, S even - day active users,和收益”）。

羅登等。 發現 PULSE 框架無法成功衡量用戶體驗變化的真正影響，並尋求建立一種更準確地“衡量用戶體驗質量並提供可操作數據”的替代方案。 考慮到這些目標，Rodden 等人。 精心製作了 HEART 框架，該框架在 UX 設計團隊和產品管理團隊中得到了廣泛的關注。

現在我們知道了 HEART 框架是什麼，讓我們討論一下使用這個框架來推動 UX 改進的好處。

使用 HEART 框架進行 UX 的好處

使用 HEART 框架提供了三個核心優勢：

1. HEART 將用戶體驗結果與業務目標聯繫起來
2. HEART 幫助您清晰、細緻地決定“要改進什麼”
3. HEART 旨在採取行動而不是簡單的報告

首先，我們需要記住，用戶體驗增強是企業為客戶提供價值的一項投資，因此必須在某個時候為企業帶來價值回報。 通過確保我們專注於實際推動業務目標的用戶體驗結果，我們更有可能獲得進行增量改進所需的資源和優先級。

多年來，我與數十家組織的 UX 設計師進行了一對一的接觸。 對於設計師來說，一個反復出現的首要痛點是他們已經確定了他們熱切相信的廣泛的潛在改進，但卻無法確保將這些設計改進投入生產所需的工程帶寬； 一些想法連續幾個月擱淺。

這個問題最常見的根本原因是他們沒有將他們期望的用戶體驗結果與業務目標聯繫起來。 當我幫助他們將 UX 目標納入業務優先級時，他們更有可能將他們的提案推進到終點線。

其次，HEART 使用目標、信號和指標來明確打破潛在的瓶頸，並確定下一步要解決的最高價值的用戶體驗元素。

很多時候，用戶訪談或未經審核的用戶測試可以產生寶貴的定性見解，但不應根據其中一些見解採取行動。 例如，用戶可能會表達對顏色、動畫或文字等視覺細節的強烈偏好； 但是，這些視覺細節通常會受到個人解釋的影響，不能推廣到您的整個用戶群。

通過特別關注快樂、參與、採用、保留和任務成功的類別，我們可以磨練對我們通過我們的設計和產品服務的用戶群最重要的模式。

第三，心自然地驅動行動。 有了 HEART 框架，我們立即知道我們尋求通過任何 UX 改進建議移動哪些指標，我們知道它究竟會給最終用戶帶來多大好處，我們也知道它會如何準確地反饋到更廣泛的業務中。

我們可以優先考慮首先關注哪些用戶體驗結果，而不是提倡大量非結構化的用戶體驗指標集合。 而且，我們可以在交付每個迭代設計改進時清楚地衡量我們的進度，而不是僅僅依靠定性用戶訪談。

那麼，我們要解決的下一個問題是：誰應該帶頭實施 HEART？

誰應該使用 HEART 框架？

UX 設計師應該率先使用 HEART 框架來為他們的設計建立用戶目標，並創建以用戶為中心的指標來基準測試和改善最終用戶體驗。

設計師最適合：

• 確定哪些用戶目標與業務相關
• 確定哪些特徵指標準確地有助於用戶目標
• 使用指標來決定接下來要進行哪些改進
• 確定改進是否達到預期效果

對於還沒有 HEART 框架的產品，產品經理應該努力縮小差距。

產品經理最適合：

• 向業務利益相關者倡導用戶體驗投資
• 清楚地識別關鍵的產品交互，以便隨著時間的推移進行監控和改進
• 主動充實未來的產品功能以瞄準所需的用戶最終狀態

何時使用 HEART 框架

HEART 框架在產品功能級別上效果最好。 通常，我們希望避免在非常低的級別（例如微交互或設計副本）或非常高的級別（例如產品系列）使用此框架。

為了幫助我們為 HEART 選擇正確的粒度，我們以 Google Maps 產品為例。 Google Places 產品功能顯示特定位置的詳細信息，包括地址、評級、評論、方向、網絡鏈接和其他關鍵信息。

如果您只針對特定的微交互，那麼您可能無法獲得足夠的投資回報 (ROI) 來讓您花時間進行練習。 例如，當點擊一個興趣點時，Google Places 有一個微交互，左側欄會滑出。 衡量“滑動條交互”的參與度不太可能對用戶、產品或業務產生積極影響。

另一方面，如果您嘗試使用 HEART 來改進包含許多功能的產品，那麼您的結果充其量是不明確的，最壞的情況是自相矛盾的。 嘗試在整個 Google 地圖產品上使用 HEART 會將我們的注意力分散到各種功能上，從 Google Places 到 Directions 到 Satellite View 到 Street View。

使用類似的邏輯，我們應該避免在產品組合級別使用 HEART。 也就是說，如果我們嘗試使用 HEART 來決定是否專注於改進 Google Maps、Gmail 或 Google Calendar，我們將無法得出明確的結論。

深入 HEART 類別

現在讓我們清楚地定義每個 HEART 類別：幸福、參與、採用、保留和任務成功。

幸福

首先，幸福感關注的是用戶在使用你的產品和功能時的情緒狀態。 作為羅登等人。 分享，快樂與“用戶體驗的主觀方面，如滿意度、視覺吸引力、推薦的可能性和感知的易用性”有關。

幸福很重要，因為人們將他們使用的產品與自己的身份聯繫起來。 在使用時產生積極感覺的產品被視為解決方案，而在使用時產生負面感覺的產品被視為痛點。

鑑於幸福是態度和主觀的，幸福通常是通過調查而不是使用指標來衡量的。 儘管如此，幸福還是可以通過使用標準化問題來量化。

衡量幸福感的一種方法是詢問淨推薦值 (NPS) 問題，“您將此產品推薦給朋友或同事的可能性有多大？”

另一種衡量幸福感的方法是問 Sean Ellis 產品/市場契合度問題，“如果你不能再使用我們的產品，你會有多失望？”

訂婚

其次，參與側重於每個用戶的實際功能使用情況。 參與度包括功能使用頻率和工作流程深度。

請記住，參與要求我們定義“合格活動”——也就是說，並非所有功能對最終用戶都具有同等價值。 一次簡單的登錄或一次簡單的頁面瀏覽不應算作參與度，因為很難證明這種膚淺的活動在用戶的生活中創造了真正的價值。 相反，我們應該使用類似於“待完成的工作”(JTBD) 的框架來衡量為最終用戶創造價值的行為。

參與度可以進一步分為接下來的兩個 HEART 類別：採用（捕獲新用戶）和保留（保留現有用戶）。

採用

採用的重點是用戶獲取。 也就是說，它試圖衡量該功能用戶群的持續增長。

請記住，用戶體驗設計只有在用戶接觸到它時才能為用戶提供價值。 換句話說，即使是一個“完美”的設計，如果它不包含告知用戶其存在的能力，並且如果它沒有說服用戶利用它的機制，那麼它也不會為用戶釋放任何價值。

雖然一些設計師可能反對向給定功能添加“銷售”或“營銷”功能，但請記住，不能吸引新用戶的功能不會具有長期的持久力。

為了更深入地討論以客戶為中心的產品採用，我們的 Product Teacher 團隊制定了功能採用指南。

保留

保留集中在粘性或重複行為上。 也就是說，它試圖衡量用戶是否繼續從該功能中獲得價值。 我們想特別關注以前使用過該功能的用戶，並確定他們是否會回來使用該功能。

如果他們只使用一次該功能，那麼我們可以假設他們是出於好奇而使用該功能，從長遠來看並沒有發現它的價值。 如果用戶始終如一地使用該功能，即他們定期“僱用”該功能來解決他們生活中的特定痛苦，那麼該功能就成功地推動了用戶保留。

如需更深入地了解客戶保留和客戶流失，請查看產品教師的客戶流失分析綜合指南。

任務成功

最後，任務成功取決於用戶在工作流中導航的能力。 從本質上講，任務成功是設計清晰度的衡量標準。 任務成功作為一個類別包括常用的用戶體驗指標，例如任務完成時間和錯誤率。

如果您的產品工作流程恰好是線性的，例如貸款申請工作流程或結帳工作流程，那麼您可以使用產品使用指標（例如“工作流程漏斗轉化率”）作為衡量任務成功的方式。

然而，對於非線性產品工作流程，可能很難知道用戶是否成功實現了他們期望的目標，以及他們取得的結果是否是錯誤的。 對於這些類型的非線性產品工作流程，利用可用性測試來評估任務成功，而不是產品使用指標。

優先考慮 HEART 類別

我們現在已經牢牢掌握了五個 HEART 類別：幸福、參與、採用、保留和任務成功。 在我們進一步討論之前，請注意 HEART 類別之間自然存在緊張關係。

例如，針對任務成功進行優化可能意味著關注效率而非愉悅，而針對幸福進行優化可能意味著關注愉悅而非效率。 而且，採用側重於新用戶獲取，而留存側重於重複使用，這意味著這兩個目標用戶群是完全不同的。

因此，請確保優先考慮五個 HEART 類別中的哪一個是最重要的，以便使您的功能達到下一階段的成功。

快樂是瓶頸，還是任務成功是瓶頸？ 採用比保留更重要，還是保留比參與更重要？ 產品經理負責在這裡設定團隊的方向。

現在讓我們深入研究如何使用這些類別來確定給定用戶體驗的改進領域。

分解 HEART 組件

為了在每個 HEART 類別中取得成功，我們可以使用三個組件來分解用戶體驗的有效性：目標、信號和指標。

目標

每個HEART 目標都應側重於期望的業務目標。 這些目標通常是定性的。 我們需要預先為每個 HEART 類別建立一個目標，因為我們需要記住每個功能和 UX 流程都是一項業務投資。

任何軟件功能的核心假設都是：“我們將通過為最終用戶創造價值來獲取業務價值。” 避免陷入只為最終用戶創造價值的陷阱，而沒有確定如何為企業獲取價值。 如果不考慮業務，用戶體驗項目通常不會脫離提案階段，因為業務利益相關者無法確定用戶體驗計劃將如何推動業務向前發展。

將業務目標視為激發額外創造力的創造性約束。 記住，有限制時想出好點子比完全沒有限制​​時要容易得多。

如果您不相信我，請嘗試我們定期與研討會參與者分享的這個練習：不受限制地創作一首詩——這非常困難。 相比之下，創作一首必須包括會說話的狗、去海灘散步和掉在地上的冰淇淋甜筒的詩。 您會發現受限版本的創建速度更快，而且比不受限版本更能吸引觀眾。

因此，HEART 目標是以推動業務向前發展的方式構建我們的用戶體驗計劃的關鍵。 如果您的組織已經在使用目標和關鍵結果 (OKR)，請注意 HEART 目標與 OKR 目標相得益彰。

信號

一旦我們確定了每個 HEART 類別的目標，我們現在需要確定我們要尋找的信號。 信號是一種定性的最終用戶行為，它與我們為該功能設定的目標相關聯。

信號包括行動和感受。 依靠產品使用指標來確定“行動”信號，並依靠調查來確定“感覺”信號。 並且請記住，信號可以是積極的也可以是消極的。

請記住將您的信號根植於您選擇的目標內。 我們的目標是在解決用戶需求的同時加強我們的業務地位，因此信號需要與我們設定的業務目標相關聯。

作為一個例子，讓我們考慮這樣一個候選信號：“用戶在社交媒體上分享你的功能中的微動畫是多麼令人愉快。”

如果目標是“提高口碑意識”，那麼包含這個信號是有意義的。

但是，如果 HEART 目標是“減少工作流程完成時間以節省銷售前景的成本”，那麼這個信號就不是一個好信號。 微動畫需要時間，雖然它們可以增加用戶的幸福感，但它們可能不會增加用戶快速完成任務的能力。

此外，只有當用戶體驗是變化的唯一解釋時，信號才應該移動。 例如，您不希望跟踪基於營銷努力而不是用戶體驗變化而上下移動的信號。 注意混淆因素，例如營銷努力、客戶成功努力和銷售努力。

指標

最後，我們可以得出 HEART 類別的指標。 具體來說，我們的指標應該衡量我們之前確定的信號，並且我們的指標應該使我們能夠在報告和儀表板上可視化隨時間推移的進展。

一般來說，您應該將您的指標與客戶群的規模進行標準化。 也就是說，“總使用量”不如“每個用戶的平均使用量”那麼有助於跟踪。

並且請記住，同一個信號可以以多種方式拆分。 例如，假設我們對“Amplitude Analytics 中的儀表板創建”感興趣，將其作為 HEART 參與類別下的信號。

對於這個信號，我們有多個指標可供使用：

• 每個用戶每月創建的平均儀表板
• 上個月至少創建了一個儀表板的用戶百分比
• 儀表板創建之間的平均時間長度

而且，我們甚至可以進一步細分每個指標，例如通過使用行為細分或使用用戶屬性。

歸根結底，沒有一個指標是普遍正確或錯誤的。 這項工作的最佳指標是能夠幫助您做出明智決策並讓您的利益相關者與您一起參與決策過程的指標。 隨意選擇對您的決策過程最直觀的指標。

要總結 HEART 組件，我們應該首先提出 HEART 目標，然後確定 HEART 信號，最後提出 HEART 指標。

警惕那些告訴您預先選擇 HEART 指標，然後反向選擇信號和目標的指南。 使用最容易獲得的指標往往不是一個好主意，因為指標檢測比實現正確的目標要容易得多。

現在，讓我們深入研究一個真實世界的示例，讓 HEART 框架栩栩如生。

HEART 框架的一個例子

想像一下，我們正在為房地產經紀人構建一個客戶關係管理系統 (CRM)，我們提供的其中一個關鍵功能是經紀人能夠將客戶“重新分配”給彼此。

我們決定在“重新分配客戶”方面投資於額外的用戶體驗改進，因為我們相信此功能可使我們的產品與競爭對手區分開來。 例如，也許我們有興趣顯示“代理工作量”，這樣分配者就不會給受讓人增加負擔。 或者，也許我們有興趣為初次使用的用戶添加工具提示或演練。

這是一個假設的 HEART 圖表，您可以旋轉它來探索如何進一步改進“重新分配客戶”的 UX 工作流程。 這與我之前分享的示例相同。

使用此 HEART 圖表，我們現在擁有廣泛的相關 UX 指標，可用於評估功能健康狀況。 我們應該與工程團隊和分析團隊合作，對確定的指標進行檢測以建立基線。

一旦我們有了基線讀數，我們就會決定這些指標中的哪一個是接下來要改進的最關鍵的指標。 而且，隨著每個指標的改進，我們可以迭代地解決其他瓶頸，以隨著時間的推移增強功能 UX 健康狀況。

現在我們有了一個完整的 HEART 圖表的示例，讓我們討論如何使用 HEART 框架來推動行動。

使用 HEART 框架推動行動的 7 個步驟

這是使用 HEART 框架推動行動的七步行動手冊。 我們已經確定了產品三重奏（PM、設計和工程）中的誰應該參與每個步驟。

首先，產品管理、產品設計和產品工程這三者必須選擇一個特性來重點使用 HEART 框架進行分析。

其次，產品管理和設計應該評估優先考慮哪些 HEART 類別是有意義的。

第三，產品管理和設計應該選擇哪些業務目標與優先的 HEART 類別相一致。 產品管理應該在這一步中起帶頭作用。

這第三步應該會引起重大爭論，這不是壞事。 產品經理自然會提倡業務成果，而設計師自然會提倡用戶成果。 關鍵是要找到能夠推進業務目標的用戶成果。

第四，設計應該選擇哪些用戶信號與選定的目標相關。 在這裡，設計應該處於主導地位，因為設計師對要鼓勵的不同用戶成功狀態以及要避免和減輕的用戶失敗模式有更深入的了解。

第五，設計、PM 和工程部門應該討論哪些指標可以在合理的時間內使用，以測量選定的信號。 工程師應該在這一步中起帶頭作用，因為工程洞察力可以使一個月的努力與一年的努力有所不同。

第六，產品管理應將儀表化的 HEART 指標納入其產品的 OKR，以及利益相關者可以訪問的任何類型的報告和儀表板。

最後，隨著指標結果的出現，產品三人組應該一起優先採取行動。 他們將決定哪項 HEART 指標改進將產生最高的投資回報，以及何時繼續迭代此功能的用戶體驗，何時轉向下一個功能。

使用 HEART 啟用長期監控和警報

隨著每個 UX 分析的結束，產品開發團隊應該尋求建立長期監控和警報，以建立他們過去的工作。

每個跟踪的 HEART 指標都應該集中在報告、儀表板或存儲庫中。 然後，團隊應選擇一個指標閾值以確保該指標不會低於健康基線。 這個存儲庫現在提供對各種功能和產品的 UX 健康狀況的長期監控。

但是，監控器會產生巨大的精神開銷，尤其是當您實施了數十個或數百個 HEART 指標時。 因此，與工程師一起設置警報（例如 Amplitude 的 Anomoly + Forecast 功能），當跟踪的指標低於確定的閾值時，該警報將自動觸發。 使用這些警報來引導團隊的注意力和行動。

實施 HEART 框架時要避免的關鍵注意事項

每個框架都有缺點和注意事項。 Amplitude 的產品佈道師 John Cutler 對框架的評價如下：“很多框架設計得很糟糕。 他們不安全。 它們沒有先決條件、警告標籤和/或有效期。 它們與上下文無關，並且缺乏使它們具有上下文感知能力的機制。”

因此，在為您自己的 UX 設計和產品實施 HEART 時，請牢記以下四個警告標籤：

• 確保選擇的範圍不要太寬泛
• 不要為所有功能強加“不自然”的 HEART 類別
• 請記住優先考慮 HEART 目標、HEART 信號和 HEART 指標
• 不要忘記確保業務一致性並提供令人信服的業務案例

首先，確保選擇的範圍不要太寬泛。 如前所述，當 HEART 專注於產品中的某個功能而不是整個產品本身時，它的效果最好。 然而，這裡的挑戰是“功能”和“產品”位於一個範圍內，不能總是整齊地分類。 一些產品組織可能將功能視為產品，而一些產品組織可能將產品視為功能。

一個很好的試金石測試您是否選擇了正確的粒度是針對目標（業務目標）和信號（最終用戶狀態）的重疊，但在指標上有足夠的差異。 如果你的每一個 HEART 目標都彼此截然不同，或者你的每一個 HEART 信號代表一個截然不同的用戶最終狀態，那麼你可能需要縮小關注範圍。 另一方面，如果您的 HEART 指標顯示出明顯的重疊，那麼您可能關注的範圍太窄，需要將對話提升一個層次。

其次，不要強制使用每個 HEART 類別。 有些功能根本沒有採用或保留的獨立途徑。 例如，考慮用戶註冊流程。 試圖為這個激活工作流程硬塞一個“保留”指標是沒有意義的，因為每個用戶通常只註冊一次。

第三，使用 HEART 時要注意不要把自己攤得太薄。 就其本質而言，HEART 使您能夠擁有多個目標、多個信號和多個指標。 不要一次追求所有這些。

根據帕累托原則，最有價值的 20% 的努力會為您的最終用戶帶來 80% 的價值，而其餘 80% 的努力應該投入到其他地方。

最後，如果 HEART 無法與業務優先級保持一致，或者如果 ROI 業務案例沒有意義，那麼 HEART 根本不起作用。 例如，某些功能可能已經達到“生命週期結束”的成熟度，不再對持續的業務成功至關重要。

雖然此功能中的某些用戶體驗可能確實難以使用，但投資它們沒有意義，因為它們不會為業務帶來價值。 如果您的企業已經決定停用某個特定功能，那麼改進該功能的用戶體驗不會帶來長期的用戶價值。

結語

HEART 框架是一種靈活的結構，用於分解 UX 目標並將它們與業務目標聯繫起來。 UX 從業者和產品經理都應該考慮將 HEART 框架添加到他們的技術庫中。

第一次實施 HEART 需要一些時間來適應。 但是，當您重複該過程時，該框架將開始成為第二天性。 隨著時間的推移，您的團隊將能夠快速確定最高價值的 UX 改進的優先級，從而為您的用戶和您的業務帶來積極成果。