HEARTフレームワークとは？｜GoogleのUX指標をゴール・シグナル・メトリクスで設計する

リニューアルしたのに、何が良くなったのか説明できない。PVもアクティブユーザー数も横ばいで、使いやすくなったという手応えだけが残る。プロダクトの改善に関わる方なら、一度はこんな状況に立たされたことがあるのではないでしょうか。

この記事では、こうした使い心地の変化を数字で語るための定番の枠組みであるHEARTフレームワークを、初めての方にもわかるように体系立てて解説します。指標の選び方を決めるゴール・シグナル・メトリクスという手順まで、具体例とあわせて見ていきます。

HEARTフレームワークとは何か

HEARTフレームワークは、Googleでユーザー体験（UX）の調査に携わっていたケリー・ロッデン、ヒラリー・ハッチンソン、シン・フーの3人が、2010年のACM CHI（ヒューマン・コンピュータ・インタラクション分野の国際会議）で発表した論文で提案した考え方です。大規模なウェブアプリケーションで、ユーザー中心の指標を体系的に選ぶための枠組みとして広く知られるようになりました。

5つの頭文字が表すもの

HEARTという名前は、ユーザー体験を測る5つの観点の頭文字から来ています。それぞれの意味を最初に一覧で押さえておきましょう。

この5つは、主観（満足）、行動の量（関与・採用・継続）、行動の質（タスク成功）という異なる角度からユーザー体験を切り取っています。どれか一つだけを見ていると見落とす変化を、別の観点が拾ってくれるのがこの枠組みの強みです。

PULSEへの反省から生まれた

HEARTが提案された背景には、それ以前から使われていたPULSEという指標群への問題意識がありました。PULSEはPage views（ページビュー）、Uptime（稼働率）、Latency（応答速度）、Seven-day active users（7日間のアクティブユーザー）、Earnings（収益）の頭文字です。

PULSEはサービスの健康状態を見るには役立ちますが、UXの変更が良かったのか悪かったのかを判断するには粒度が粗すぎました。たとえばPVが増えたとき、それが面白くて読み進めた結果なのか、迷って行ったり来たりした結果なのかは区別できません。

そこで、ユーザーの体験そのものに寄り添った指標を選ぶ枠組みとして整理されたのがHEARTです。PULSEを捨てるのではなく、事業の健康診断とは別に、体験の良し悪しを測る物差しを持つという位置づけだと理解するとわかりやすいでしょう。

5つの観点をもう一段深く理解する

表で概要をつかんだところで、各観点の読み方と、実務で混同しやすい点を整理します。似た言葉が多いので、ここを押さえておくと後の設計がぐっと楽になります。

Happinessは態度、残りの4つは行動

Happinessだけは、ユーザーに尋ねて得る態度のデータです。アンケートの回答はログからは取れないため、別の仕組みで集める必要があります。

残りの4つは、画面上の操作ログから計算できる行動のデータです。態度と行動は必ずしも一致しないため、両方を並べて見ることに意味があります。満足度のアンケートの設計については、CSAT・CES（顧客満足度指標）とは？で詳しく扱っています。

Adoption・Engagement・Retentionの違い

この3つは、時間軸で分けると整理しやすくなります。Adoptionは使い始めた瞬間、Engagementは使っている最中の濃さ、Retentionは時間がたっても戻ってくるかどうかを見ています。

新機能の評価であれば、Adoptionは機能を一度でも試した人の割合、Engagementはその機能を週に何回使うか、Retentionは翌月もその機能を使っている人の割合、という具合に対応づけられます。機能単位での定着の測り方は、機能の定着率（アダプション）もあわせて読むと理解が深まります。

Task successは効率と正確さ

Task successは、ユーザーが来た目的を達成できたかを見る観点です。検索なら目的の結果にたどり着けたか、フォームなら送信まで終えられたか、設定画面なら迷わず変更できたかが対象になります。

ここで大切なのは、完了したかどうかだけでなく、どれだけ手間をかけずに終えられたかも含めて考えることです。同じ完了率でも、所要時間が半分になっていれば体験は明らかに良くなっています。

逆に、所要時間が伸びたからといって必ずしも悪いとは限りません。読み物のページなら長く読まれるのは良い兆候ですが、手続きの画面なら迷っているサインかもしれず、同じ数字でも画面の目的によって読み方が変わります。

ゴール・シグナル・メトリクスで指標を選ぶ

HEARTの5つの観点は、それだけでは何を測るかのカテゴリにすぎません。実際の指標に落とし込むために、論文ではあわせてゴール・シグナル・メトリクス（Goals-Signals-Metrics）という3段階の手順が示されています。

ゴール：何を達成したいのかを言葉にする

最初に、プロダクトや機能のゴールをユーザーの言葉で書き出します。ここで数字の話を始めないのがコツです。

たとえば、レポート画面を刷新するなら、ユーザーが知りたい数字に早くたどり着けるようにする、というのがゴールになります。ゴールの段階でチーム内の認識がずれていると、どれだけ精密に測っても議論はかみ合いません。

シグナル：達成したら行動はどう変わるか

次に、ゴールが達成されたときにユーザーの行動や態度がどう変わるかを考えます。これがシグナルです。

先ほどの例なら、目的のレポートを開くまでのクリック数が減る、途中で画面を行き来する回数が減る、といった変化がシグナルになります。ログとして記録できるかどうかもこの段階で確かめておきます。

メトリクス：比べられる数字に変換する

最後に、シグナルを時系列や施策の前後で比べられる数字に変換します。合計値よりも、利用者1人あたりの値や割合のほうが、利用者数の増減に左右されにくく扱いやすくなります。

ゴール・シグナル・メトリクスの流れを、先ほどのレポート画面の刷新に当てはめて書き下すと次のようになります。指標の定義を文章で残しておくと、後から誰が見ても同じ数字を計算できます。

観点: Task success
ゴール: ユーザーが目的のレポートに早くたどり着ける
シグナル: レポートを開くまでの操作が減る／画面の行き来が減る
メトリクス:
  - レポート到達率 = 目的レポートを開いたセッション ÷ レポート画面に入ったセッション
  - 到達までの中央値時間（秒）
  - 1セッションあたりの戻る操作回数
比較の単位: リリース前4週間 と リリース後4週間

具体例で設計してみる

ここからは、架空の小さなSaaSを題材に、HEARTを一つの表にまとめるところまでやってみましょう。以下の数値はすべて説明用の仮定です。

題材：ダッシュボードの新しい絞り込み機能

ある解析ツールが、ダッシュボードに流入元や端末で絞り込める新機能を追加したとします。チームが知りたいのは、この機能がユーザーの分析を本当に楽にしたかどうかです。

すべての観点を埋める必要はありません。HEARTは観点の一覧であって、プロジェクトに関係する観点だけを選べばよいというのが一般的な使い方です。この例では満足、採用、タスク成功の3つに絞ります。

数字を読むときの注意

仮に、リリース後4週間で採用率が30%、絞り込み後の閲覧継続率が80%だったとします。この数字だけでは良いのか悪いのか判断できません。

比較の基準が要るのです。リリース前の同じ期間の値、あるいは機能を出していない対照群と比べて初めて、変化が施策によるものかを議論できます。可能であれば、A/Bテストで対照群を用意するのが最も確実です。

また、採用率が高くても満足度が下がっていれば、目立つ位置に置いたせいで仕方なく触っているだけかもしれません。観点どうしを突き合わせて矛盾を探すことが、HEARTを使う本当の価値です。

よくある落とし穴

HEARTはシンプルなぶん、形だけ取り入れて失敗するパターンも決まっています。代表的なものを三つ挙げます。

5つ全部を毎回埋めようとする

最も多いのは、5つの観点すべてに指標を置かないと落ち着かないという失敗です。結果として、ダッシュボードには誰も見ない数字が並び、本当に大事な変化が埋もれてしまいます。

HEARTはチェックリストではなく、見落としを防ぐための視点の一覧だと考えましょう。その施策の成否を左右する観点を2〜3個選ぶくらいがちょうどよい場合がほとんどです。

指標から先に決めてしまう

手元にある数字から逆算して、ゴールを後付けしてしまうのも典型的な失敗です。計測しやすい数字が、必ずしも体験の良し悪しを表しているとは限りません。

ゴール・シグナル・メトリクスの順番を守るのは、このためです。指標を先に決めるとその数字を上げること自体が目的化しやすく、グッドハートの法則が指摘するような歪みを招きます。

平均値だけを見る

Engagementの平均値が上がっても、ごく一部のヘビーユーザーが大きく伸びただけかもしれません。平均だけでなく、中央値や分布、利用者層ごとの内訳もあわせて確認しましょう。

数字が動いた理由を知りたいときは、代表的なユーザーの行動を一人ずつ追うのも有効です。集計の裏で何が起きているかを確かめてから結論を出すと、判断の精度が上がります。

特に、利用開始直後の人と長く使っている人では、同じ機能でも使い方がまったく違うことがよくあります。利用期間ごとに分けて数字を見るだけでも、平均値では相殺されていた変化が浮かび上がってきます。

導入の進め方と他の枠組みとの関係

最後に、チームでHEARTを使い始めるときの進め方と、ほかの指標の枠組みとの関係を整理します。既に使っている枠組みがある場合も、置き換えではなく補い合う関係として考えられます。

小さく始める手順

いきなりプロダクト全体を対象にするより、次のリリースで出す一つの機能から始めるのがおすすめです。進め方の目安は次のとおりです。

• 対象の機能を一つ決め、関係する観点を2〜3個選ぶ
• 観点ごとにゴール・シグナル・メトリクスを一行ずつ書く
• シグナルを記録するイベントが計測されているか確かめ、なければ計測を追加する
• リリース前の基準値を取り、リリース後に同じ定義で比べる

3つ目の手順で必要なイベントが揃っていないと、どれだけ設計しても数字は取れません。何をどの名前で記録するかを先に決める方法は、計測設計（トラッキングプラン）とは？で解説しています。

北極星指標やAARRRとの使い分け

北極星指標は、プロダクト全体として追いかける一つの数字です。一方でHEARTは、個々の機能や画面の体験を評価するのに向いています。

獲得から収益までの流れを段階で見るAARRRは、事業の成長の道筋を示す枠組みです。HEARTはその各段階の中で、ユーザーがどれだけ気持ちよく使えているかを確かめる役割を担います。

つまり、北極星指標で全体の方向を決め、AARRRで成長のどこに詰まりがあるかを探し、HEARTで個別の改善の良し悪しを判定する、という役割分担が考えられます。指標全体の組み立て方については、プロダクト指標の設計も参考にしてください。

プライバシーに配慮した計測でも使える

HEARTの行動系の4観点は、個人を特定しなくても計測できます。必要なのは同じ訪問者やセッションを追えることで、名前やメールアドレスは要りません。

たとえばMonaLensのようにCookieを使わず個人情報を集めない解析ツールでも、ファネルやアンケートを組み合わせればTask successやHappinessを見ることはできます。ただし、長期のRetentionをどこまで正確に追えるかはツールの識別方式によって変わるので、事前に仕様を確認しておきましょう。

まとめ：体験を語るための共通言語

HEARTフレームワークは、満足・関与・採用・継続・タスク成功という5つの観点から、ユーザー体験を数字で語るための枠組みです。PVやアクティブユーザー数だけでは見えなかった、使い心地の変化を捉えられるようになります。

大切なのは、5つを全部埋めることではありません。ゴールを言葉にし、行動の変化をシグナルとして想像し、比べられるメトリクスに変換するという順番を守ることです。

次のリリースで一つの機能を選び、ゴール・シグナル・メトリクスを3行書くところから始めてみてはいかがでしょうか。チームで同じ言葉を使えるようになるだけでも、リリース後の振り返りは大きく変わるはずです。