HEART フレームワークを使用してソフトウェア UX を改善する方法

ソフトウェアに対する顧客の期待がより洗練されるにつれて、UX への投資は、製品の成功とビジネスの成功を左右します。 しかし、UX の改善を提唱することは、特に組織を行動に駆り立てるのに役立つ明確な指標がなければ、非常に難しい場合があります。 これらの投資をより適切に説明するために、ユーザーの成功、製品の成功、およびビジネスの成功を同時に促進するために、Google の研究者によって一般化された UX 指標の HEART フレームワークに関するこのガイドを作成しました。 HEART を使用して、どの UX メトリクスを優先すべきかを明確にし、ユーザー エクスペリエンスに再投資するための健全なビジネス ケースを確立します。

HEART フレームワークとは

HEART フレームワークは、ソフトウェア製品のユーザー エクスペリエンス (UX) 改善の潜在的な領域を特定するための実用的な構造です。 「HEART」という頭字語は、ユーザー エクスペリエンスの 5 つのカテゴリである、 H appiness 、 Engagement 、Adoption、Retention、 T ask success を表しています。 この包括的なガイドの後半で、これらの各カテゴリをより詳細に定義します。

各 HEART カテゴリには、アクションを促進し、進捗状況を測定するのに役立つ 3 つの異なるコンポーネント (目標、信号、および指標) が含まれています。

• 目標は質的なビジネス目標です
• シグナルは、目標につながる質的なエンド ユーザーの行動です
• メトリクスはシグナルの定量的測定値です

後のセクションでは、目標、シグナル、指標の定義と例を示します。

このフレームワークを HEART チャートに視覚化できます。これは、後で分解する実際の製品の例に似ています。

そもそも HEART フレームワークが存在するのはなぜですか?

HEART フレームワークは、Google の Kerry Rodden、 Hilary Hutchinson、Xin Fu によって 2010 年に公開されました。これは、 PULSE (「ページ ビュー数、アップタイム、レイテンシ、S偶数日のアクティブ ユーザー、および収益」)。

ロッデン等。 は、PULSE フレームワークが UX 変更の真の影響をうまく測定できないことを発見し、より正確に「ユーザー エクスペリエンスの品質を測定し、実用的なデータを提供する」代替手段を確立しようとしました。 これらの目的を念頭に置いて、Rodden et al。 HEART フレームワークを作成し、UX デザイン チームと製品管理チームの間で注目を集めています。

HEART フレームワークが何であるかがわかったので、このフレームワークを使用して時間の経過とともに UX の改善を促進する利点について説明しましょう。

HEART フレームワークを UX に使用する利点

HEART フレームワークを使用すると、主に次の 3 つのメリットが得られます。

1. HEART は UX の成果をビジネス目標に結びつける
2. HEART は、明快さと粒度で「何を改善するか」を決定するのに役立ちます
3. HEART は、単純な報告ではなく行動を起こすように構成されています

まず、UX の強化は企業が顧客に価値を提供するための投資であるため、ある時点で企業に価値を還元する必要があることを覚えておく必要があります。 実際にビジネス目標を動かす UX の結果に集中することで、段階的な改善を行うために必要なリソースと優先順位を確保できる可能性が大幅に高くなります。

長年にわたり、私は数十の組織の UX デザイナーと 1 対 1 のタッチポイントを持ってきました。 設計者にとって何度も頭に浮かぶ問題点は、彼らが熱心に信じていた幅広い潜在的な改善を特定したにもかかわらず、これらの設計の改善を製品に持ち込むために必要なエンジニアリング帯域幅を確保できなかったことです。 いくつかのアイデアは何ヶ月もの間衰えました。

この問題の最も頻繁な根本原因は、望ましい UX の成果をビジネス目標に結びつけていないことでした。 UX の目標をビジネスの優先事項に段階的に引き上げる手助けをしたところ、彼らは提案を最終段階まで進める可能性が大幅に高くなりました。

次に、HEART は目標、シグナル、指標を使用して、潜在的なボトルネックを明確に分析し、次に取り組むべき最も価値の高いユーザー エクスペリエンス要素を特定します。

多くの場合、ユーザー インタビューやモデレートされていないユーザー テストから定性的な洞察の宝庫が得られますが、これらの洞察の一部は行動に移すべきではありません。 例として、ユーザーは、色、アニメーション、言葉遣いなどの視覚的な詳細について強い好みを表明する場合があります。 ただし、これらの視覚的な詳細は通常、個々の解釈の対象となり、ユーザー ベース全体に一般化することはできません。

幸福、エンゲージメント、採用、維持、タスクの成功のカテゴリに特に焦点を当てることで、デザインと製品を通じてサービスを提供するユーザー セグメントにとって最も重要なパターンに焦点を当てることができます。

第三に、心は自然に行動を促します。 HEART フレームワークを導入すると、UX 改善の提案でどの指標を動かすべきかがすぐにわかり、それがエンドユーザーにどのように利益をもたらすか、そしてそれがより広範なビジネスにどのようにフィードバックされるかが正確にわかります。

構造化されていない大規模な UX メトリクスのコレクションを推奨するのではなく、どの UX の結果に最初に焦点を当てるかを優先することができます。 また、定性的なユーザー インタビューだけに頼るのではなく、反復的な設計の改善をリリースするたびに、進捗状況を明確に測定できます。

次に取り組むべき問題は、誰が HEART の実装を率先して行うべきかということです。

誰が HEART フレームワークを使用する必要がありますか?

UX デザイナーは HEART フレームワークの先頭に立ち、デザインのユーザー目標を確立し、エンド ユーザー エクスペリエンスをベンチマークして改善するためのユーザー中心の指標を作成する必要があります。

デザイナーは次のようなポジションに最適です。

• ビジネスに関連するユーザーの目標を決定する
• ユーザーの目標に正確に貢献する機能指標を特定する
• メトリクスを使用して、次にどの改善を行うかを決定します
• 改善が意図した効果をもたらしたかどうかを判断する

HEART フレームワークがまだ導入されていない製品の場合、製品マネージャーはギャップを埋めるようにプッシュする必要があります。

プロダクト マネージャーは、次のようなポジションに最適です。

• ビジネス関係者に UX 投資を推奨する
• 主要な製品の相互作用を明確に特定し、長期にわたって監視および改善する
• 将来の製品機能を積極的に具体化して、望ましいユーザーの最終状態をターゲットにする

HEART フレームワークを使用する場合

HEART フレームワークは、製品の機能レベルで最適に機能します。 一般に、このフレームワークを非常に低いレベル (マイクロインタラクションやデザイン コピーなど) または非常に高いレベル (製品ファミリなど) で使用することは避けたいと考えています。

HEART の適切な粒度を選択するために、Google マップ製品を例として使用してみましょう。 製品機能の Google プレイスには、住所、評価、レビュー、道順、ウェブ リンク、その他の重要な情報など、特定の場所の詳細が表示されます。

特定のマイクロインタラクションのみをターゲットにしている場合は、時間をかけるだけの十分な投資収益率 (ROI) が得られない可能性があります。 例として、興味のあるポイントをクリックすると、Google プレイスには左側のサイドバーがスライドアウトするマイクロインタラクションがあります。 「スライディングバー インタラクション」のエンゲージメントを測定しても、ユーザー、製品、またはビジネスに大きな影響を与えることはまずありません。

一方、多くの機能を備えた製品を改善するために HEART を使用しようとすると、結果はせいぜい不明確になり、最悪の場合矛盾します。 Google マップ製品全体で HEART を使用しようとすると、Google プレイスからルート案内、サテライト ビュー、ストリート ビューに至るまで、さまざまな機能に焦点が分かれてしまいます。

同様のロジックを使用すると、製品ポートフォリオ レベルで HEART を使用することは避ける必要があります。 つまり、HEART を使用して、Google マップ、Gmail、Google カレンダーの改善に集中するかどうかを決定しようとしても、明確な結論には至りません。

HEARTカテゴリーを深く掘り下げる

HEART の各カテゴリを明確に定義しましょう: 幸福度、エンゲージメント、採用、維持、タスクの成功。

幸せ

まず、幸福度は、ユーザーが製品や機能を使用するときの感情的な状態に焦点を当てています。 ロッデン等として。 共有、幸福は、「満足度、視覚的な魅力、推奨される可能性、使いやすさの認識など、ユーザーエクスペリエンスの主観的な側面」に関連しています。

人々は使用する製品を自分のアイデンティティと関連付けるため、幸福は重要です。 使用時にポジティブな感情を生み出す製品は解決策として認識されますが、使用時にネガティブな感情を生み出す製品は問題点として認識されます。

幸福度は態度や主観的なものであるため、通常、幸福度は使用量の指標ではなく調査によって測定されます。 それでも、標準化された質問を使用することで、幸福度を数値化できます。

幸福度を測定する 1 つの方法は、ネット プロモーター スコア (NPS) の質問をすることです。「この製品を友人や同僚に勧める可能性はどのくらいですか?」

幸福度を測定するもう 1 つの方法は、Sean Ellis のプロダクト/マーケット フィットに関する質問をすることです。

婚約

第二に、エンゲージメントは、ユーザーごとの実際の機能の使用に焦点を当てています。 エンゲージメントには、機能の使用頻度とワークフローの深さの両方が含まれます。

エンゲージメントでは「適格なアクティビティ」を定義する必要があることに注意してください。つまり、すべての機能がエンド ユーザーにとって等しく価値があるわけではありません。 単純なログインや単純なページ ビューは、エンゲージメントとしてカウントされるべきではありません。そのような浅いアクティビティがユーザーの生活に真の価値を生み出したと主張するのは難しいからです。 代わりに、「やるべき仕事」（JTBD）に似た枠組みを使用して、エンドユーザーに価値を生み出すアクションを測定する必要があります。

エンゲージメントは、次の 2 つの HEART カテゴリにさらに分けることができます: 採用 (新規ユーザーの獲得) と維持 (既存ユーザーの維持)。

可決

採用は、ユーザーの獲得に重点を置いています。 つまり、機能のユーザーベースの継続的な成長を測定しようとしています。

ユーザー エクスペリエンスの設計は、ユーザーが目にしたときにのみユーザーに価値を提供できることに注意してください。 言い換えれば、「完璧な」デザインであっても、その存在をユーザーに知らせる機能が含まれておらず、ユーザーにそれを利用するよう説得するメカニズムがなければ、ユーザーにとって何の価値も発揮しません。

一部の設計者は、特定の機能に「販売」または「マーケティング」機能を追加することに反対する場合がありますが、新しいユーザーを獲得しない機能は、長期的な持続力がないことに注意してください。

顧客中心の製品採用についてのより深い議論のために、Product Teacher のチームが機能採用ガイドを作成しました。

保持

リテンションは、粘着性または繰り返し動作に焦点を当てています。 つまり、ユーザーが機能から価値を享受し続けているかどうかを測定しようとしています。 以前にこの機能を使用したことがあるユーザーに特に注目し、その機能を再び使用するかどうかを判断したいと考えています。

機能を 1 回しか使用しない場合は、好奇心から機能を使用し、長期的には価値があるとは思わなかったという仮説を立てることができます。 ユーザーがこの機能を一貫して使用し続ける場合、つまり、生活上の特定の問題を解決するために定期的にこの機能を「雇う」場合、その機能はユーザーの維持に成功しています。

顧客維持と顧客減少の詳細な内訳については、Product Teacher の顧客減少分析の包括的なガイドをご覧ください。

タスクの成功

最後に、タスクの成功は、ワークフローをナビゲートするユーザーの能力に焦点を当てています。 基本的に、タスクの成功は設計の明確さの尺度です。 カテゴリとしてのタスクの成功には、タスクの完了時間やエラー率など、頻繁に使用される UX メトリックが含まれます。

ローン申請ワークフローやチェックアウト ワークフローなど、製品ワークフローがたまたま直線的である場合は、タスクの成功を測定する方法として、「ワークフロー ファネル コンバージョン率」などの製品使用指標を使用できます。

ただし、非線形の製品ワークフローの場合、ユーザーが目的を達成できたかどうか、および達成した結果がエラーであったかどうかを知ることは非常に困難です。 このような非直線的な製品ワークフローでは、製品の使用指標ではなく、ユーザビリティ テストを活用してタスクの成功を評価します。

HEARTカテゴリー優先

これで、5 つの HEART カテゴリ (幸福​​、エンゲージメント、養子縁組、維持、タスクの成功) をしっかりと把握できました。 先に進む前に、HEART カテゴリは自然に互いに緊張関係にあることに注意してください。

例として、タスクの成功を最適化することは、喜びよりも効率に焦点を当てることを意味する場合がありますが、幸福を最適化することは、効率よりも喜びに焦点を当てることを意味する場合があります。 そして、採用は新規ユーザーの獲得に重点が置かれ、リテンションは繰り返し使用に重点が置かれるため、この 2 つのターゲット ユーザー セグメントはまったく異なります。

したがって、5 つの HEART カテゴリのうち、機能の成功の次の段階に到達するために最も重要なものを優先するようにしてください。

幸福がボトルネックなのか、それともタスクの成功がボトルネックなのか? 採用は保持よりも重要ですか、それともエンゲージメントよりも保持が重要ですか? プロダクト マネージャーは、ここでチームの方向性を設定する責任があります。

次に、これらのカテゴリを使用して、特定のユーザー エクスペリエンスの改善領域を特定する方法を掘り下げてみましょう。

HEART コンポーネントの分解

各 HEART カテゴリ内で成功を促進するために、ユーザー エクスペリエンスの有効性を分析する 3 つの要素 (目標、シグナル、指標) を使用できます。

目標

HEART の各目標は、望ましいビジネス目標に焦点を当てる必要があります。 これらの目標は、通常、本質的に質的です。 各機能と UX フローはビジネス投資であることを忘れないでください。

ソフトウェア機能の中心となる仮説は、「エンド ユーザーに価値を創造することで、ビジネスに価値をもたらす」というものです。 ビジネスの価値を獲得する方法を特定せずに、エンド ユーザーのためだけに価値を生み出すという罠にはまらないようにします。 ビジネスが考慮されていない場合、ビジネスの利害関係者は UX イニシアチブがビジネスをどのように前進させるかを判断できないため、通常、UX プロジェクトは提案段階から抜け出せません。

ビジネスの目標は、さらなる創造性を刺激する創造的な制約と考えてください。 制約がまったくない場合よりも、制約がある場合の方が、優れたアイデアを思いつくのははるかに簡単です。

信じられない場合は、ワークショップの参加者と定期的に共有しているこの演習を試してください。制約のない詩を作成します。これはかなり難しいです。 対照的に、話している犬、ビーチへの散歩、地面に落ちたアイスクリームコーンを含む詩を作成する必要があります. 制約のあるバージョンは、制約のないバージョンよりも作成が速く、視聴者にとって魅力的であることがわかります。

したがって、HEART の目標は、ビジネスを前進させる方法で UX イニシアチブを構築するための鍵となります。 組織がすでに目的と主要な結果 (OKR) を使用している場合、HEART の目標は OKR の目的とうまく組み合わせることに注意してください。

シグナル

各 HEART カテゴリの目標を決定したら、次にどの信号を探しているかを決定する必要があります。 シグナルとは、機能に対して設定した目標につながる質的なエンド ユーザーの行動です。

シグナルには、行動と感情の両方が含まれます。 「アクション」シグナルを判断するために製品の使用状況の指標に頼り、「感情」シグナルを判断するためにアンケートに頼ってください。 また、信号は正または負のいずれかになる可能性があることに注意してください。

選択した目標内に信号を根付かせることを忘れないでください。 私たちの目標は、ユーザーのニーズを解決すると同時に、ビジネスの地位を強化することです。そのため、シグナルは、設定したビジネス目標に関連付ける必要があります。

例として、次のようなシグナルの候補を考えてみましょう。

目標が「口コミの認知度を高める」ことである場合、このシグナルを含めることは理にかなっています。

しかし、HEART の目標が「ワークフローの完了時間を短縮してコスト削減を販売見込み客に提示する」ことである場合、このシグナルは適切ではありません。 マイクロアニメーションには時間がかかり、ユーザーの幸福度を高めることはできますが、ユーザーがタスクをすばやく完了する能力は向上しない可能性があります。

さらに、信号は、ユーザー エクスペリエンスが変化の唯一の説明である場合にのみ移動する必要があります。 たとえば、UX の変更ではなく、マーケティング活動に基づいて上下するシグナルを追跡する必要はありません。 マーケティング活動、カスタマー サクセス活動、販売活動などの混同要因に注意してください。

指標

最後に、HEART カテゴリの指標を考え出すことができます。 具体的には、メトリックは、以前に特定したシグナルを測定する必要があり、レポートやダッシュボードで時間の経過に伴う進捗を視覚化できるようにする必要があります。

一般に、メトリクスと顧客ベースのサイズを正規化する必要があります。 つまり、「合計使用量」は、「ユーザーごとの平均使用量」よりも追跡に役立ちません。

また、同じ信号が複数の方法で分割される可能性があることに注意してください。 例として、「Amplitude Analytics 内のダッシュボードの作成」に関心があるとします。これは、エンゲージメントの HEART カテゴリの下のシグナルです。

この 1 つのシグナルに対して、複数のメトリックを自由に使用できます。

• ユーザーごと、月ごとに作成されるダッシュボードの平均数
• 先月少なくとも 1 つのダッシュボードを作成したユーザーの割合
• ダッシュボード作成間の平均時間

また、たとえば行動セグメントやユーザー属性を使用して、各メトリックをさらにセグメント化することもできます。

結局のところ、普遍的に正しいか間違っているかを示す単一の指標はありません。 仕事に最適な指標は、十分な情報に基づいた意思決定を行うのに役立ち、利害関係者を意思決定の旅に連れて行くのに役立つ指標です。 意思決定プロセスにとって最も直感的なメトリクスを自由に選択してください。

HEART コンポーネントをまとめるには、まず HEART ゴールを考え出し、次に HEART シグナルを決定し、最後に HEART メトリクスを考え出す必要があります。

HEART 指標を前もって選択し、逆方向に作業してシグナルと目標を選択するように指示するガイドには注意してください。 最も簡単に利用できるメトリックを使用することは、適切な目標を設定するよりもメトリックのインストルメンテーションの方がはるかに簡単であるため、良い考えとは言えません。

それでは、実際の例に飛び込んで、HEART フレームワークに命を吹き込みましょう。

実際の HEART フレームワークの例

不動産業者向けの顧客関係管理システム (CRM) を構築していると想像してください。当社が出荷した重要な機能の 1 つは、不動産業者が顧客を相互に「再割り当て」する機能です。

この機能が当社の製品提供と競合他社を差別化すると考えているため、「クライアントの再割り当て」の追加の UX 改善に投資することにしました。 たとえば、「エージェントのワークロード」を表示して、割り当て担当者が担当者に過度の負担をかけないようにすることに関心があるかもしれません。 または、初めてのユーザー向けにツールヒントやウォークスルーを追加することに関心があるかもしれません。

これは、「クライアントの再割り当て」UX ワークフローをさらに改善する方法を探るために作成できる架空の HEART チャートです。 これは、以前に共有したのと同じ例です。

この HEART チャートを使用すると、機能の正常性を評価するために使用できる、関連するさまざまな UX メトリックが得られます。 エンジニアリング チームと分析チームと協力して、特定された指標を計測し、ベースラインを確立する必要があります。

ベースラインの読み取り値が得られたら、これらの指標のどれが次に改善するために最も重要であるかを決定します. そして、各指標が改善されるにつれて、他のボトルネックに繰り返し取り組み、時間の経過とともに機能 UX の健全性を強化することができます。

完成した HEART チャートがどのように見えるかの例が得られたので、HEART フレームワークを使用してアクションを推進する方法について説明しましょう。

HEART フレームワークで行動を促すための 7 つのステップ

HEART フレームワークを使用してアクションを推進するための 7 ステップのプレイブックを次に示します。 製品トリオ (PM、設計、およびエンジニアリング) の誰が各ステップに関与する必要があるかを特定しました。

まず、製品管理、製品設計、および製品エンジニアリングのトリオが、HEART フレームワークでの分析に重点を置く機能を選択する必要があります。

次に、製品管理と設計は、どの HEART カテゴリを優先するのが適切かを評価する必要があります。

第 3 に、製品管理と設計は、優先順位の高い HEART カテゴリに一致するビジネス目標を選択する必要があります。 このステップでは、製品管理が主導する必要があります。

この 3 番目のステップでは、重要な議論が生じるはずですが、これは悪いことではありません。 プロダクト マネージャーはビジネスの成果を自然に提唱し、デザイナーはユーザーの成果を自然に提唱します。 重要なのは、ビジネス目標を前進させるユーザーの成果を見つけることです。

第 4 に、デザインは、選択した目標に結び付くユーザー シグナルを選択する必要があります。 設計者は、奨励すべきさまざまなユーザーの成功状態と、回避および緩和すべきユーザーの失敗モードをより深く理解しているため、ここでは設計が主導権を握る必要があります。

第 5 に、設計、PM、およびエンジニアリングは、選択された信号を測定するために妥当な時間内にどのメトリックを計測できるかについて話し合う必要があります。 このステップではエンジニアが主導権を握る必要があります。1 か月の作業と 1 年間の作業の違いは、エンジニアリングの洞察によって決まるからです。

第 6 に、製品管理者は、インストルメント化された HEART メトリクスを、製品の OKR や、利害関係者がアクセスできるあらゆる種類のレポートやダッシュボードに追加する必要があります。

最後に、メトリクスの結果が得られたら、製品トリオは一緒にアクションに優先順位を付ける必要があります。 彼らは、どの HEART 指標の改善が最高の投資収益率をもたらすか、いつこの機能の UX を反復し続けるか、いつ次の機能に移るかを決定します。

HEART による長期監視とアラートの有効化

各 UX 分析が完了すると、製品開発チームは、過去の作業に基づいて長期的な監視とアラートを確立するよう努める必要があります。

追跡された各 HEART 指標は、レポート、ダッシュボード、またはリポジトリに一元化する必要があります。 次に、チームはメトリックのしきい値を選択して、メトリックが正常なベースラインを下回らないようにする必要があります。 このリポジトリは、さまざまな機能や製品にわたって UX の健全性を長期的に監視できるようになりました。

ただし、数十または数百の HEART メトリクスを実装している場合は特に、モニターによってかなりの精神的オーバーヘッドが発生する可能性があります。 したがって、エンジニアと協力して、Amplitude の Anomoly + Forecast 機能などのアラートを設定します。このアラートは、追跡されたメトリックが決定されたしきい値を下回ったときに自動的にトリガーされます。 これらのアラートを使用して、チームに注意とアクションを指示します。

HEART フレームワークを実装する際に避けるべき重要な注意事項

どのフレームワークにも欠点と注意点があります。 Amplitude のプロダクト エバンジェリストである John Cutler は、フレームワークについて次のように述べています。 彼らは安全ではありません。 前提条件、警告ラベル、有効期限はありません。 それらはコンテキストフリーであり、コンテキストを認識できるようにするメカニズムがありません。」

そこで、独自の UX デザインや製品に HEART を実装する際に留意すべき 4 つの警告ラベルを以下に示します。

• 選択した範囲が広すぎないことを確認してください
• すべての機能に対して「不自然な」HEART カテゴリを強制しないでください
• HEART ゴール、HEART シグナル、HEART メトリクスに優先順位を付けることを忘れないでください
• ビジネスの整合性を確保し、説得力のあるビジネス ケースを提供することを忘れないでください。

まず、選択した範囲が広すぎないことを確認してください。 前述のように、HEART は、製品全体ではなく、製品内の機能に重点を置いている場合に最も効果的です。 ただし、ここでの課題は、「機能」と「製品」がスペクトル上にあり、常にきちんと分類できるとは限らないことです。 一部の製品組織は機能を製品と見なす場合があり、一部の製品組織は製品を機能と見なす場合があります。

適切な粒度を選択したかどうかの良いリトマス試験紙は、目標 (ビジネス目標) とシグナル (エンド ユーザーの状態) の重複を目指すことですが、指標には十分な相違があります。 HEART の各目標が互いに大きく異なる場合、または各 HEART シグナルがユーザーの最終状態が大きく異なる場合は、おそらく焦点を絞り込む必要があります。 一方、HEART メトリクスがかなりの重複を示している場合は、焦点が狭すぎて、会話を 1 レベル上げる必要がある可能性があります。

次に、すべての HEART カテゴリの使用を強制しないでください。 一部の機能には、採用または保持への独立したパスがありません。 例として、ユーザー サインアップ フローを考えてみましょう。 通常、サインアップはユーザーごとに 1 回しか行われないため、このアクティベーション ワークフローに「維持」指標を押し付けようとしても意味がありません。

第三に、HEART を使用するときは、自分自身を広げすぎないように注意してください。 HEART はその性質上、複数の目標、複数のシグナル、複数の指標を持つことができます。 それらすべてを一度に追求しないでください。

パレートの法則に基づいて、労力の最も価値のある 20% がエンド ユーザーに 80% の価値をもたらし、残りの 80% は別の場所に投資する必要があります。

最後に、HEART は、ビジネスの優先事項と一致しない場合、または ROI のビジネス ケースが意味をなさない場合、まったく機能しません。 たとえば、一部の機能は「サポート終了」の成熟度に達し、継続的なビジネスの成功にとってもはや重要ではなくなっている可能性があります。

この機能の一部のユーザー エクスペリエンスは本当に使いにくいかもしれませんが、ビジネスに価値をもたらさないため、投資する意味がありません。 ビジネスが特定の機能を廃止することを既に決定している場合、その機能の UX を改善しても、長期的なユーザー価値にはつながりません。

最後に

HEART フレームワークは、UX の目的を分解し、それらをビジネスの目標に結び付けるための柔軟な構造です。 UX プラクティショナーとプロダクト マネージャーの両方が、HEART フレームワークをテクニックの武器庫に追加することを検討する必要があります。

初めて HEART を実装するときは、慣れるまでに時間がかかります。 しかし、プロセスを繰り返すうちに、フレームワークは第二の性質になり始めます。 時間が経つにつれて、チームは、ユーザーとビジネスにプラスの結果をもたらす最も価値のある UX の改善を迅速に優先できるようになります。