UX改善に効く？GoogleのHEARTフレームワーク
昨年末のネット界隈で、GoogleのHEARTというフレームワークがプチバズっていました。曰く「デザインの指標化」、曰く「UX評価における正しい指標の選び方」……非常に引きのいいワードです。
HEART自体は2014年ごろから語られていて目新しいというわけではないですが、日本語の記事があまり多くないように感じました。自分なりに感じたメリット・デメリットを記載したいと思います。
要するに
・Googleが発案した、UXを指標化するためのフレームワーク
・H / E / A / R / T の縦軸 × Goal / Signal / Metrics の横軸
・それぞれの達成具合をもとにUXを指標化し、改善行動を取る
というものです。
UXの価値は数値化できるものではないので、「UXがいい」とか「UXが高い」とかの言い方はあまりしません。「UXを高める／損ねる」という言い方はしますが、「UXが高い」と状態を形容するのはあまりしっくりきません。
HEARTフレームワークで明らかになる「指標」は、他プロダクト・他サービスと比べるためのものではなく、自プロダクト・自サービスの中で時系列的に比較、改善、運用していくためのものです。
HEARTの意味
HEARTの頭文字はそれぞれ以下を表します。頭文字を取るのは、AIDMAやAISASみたいな感じですね。
Happiness（幸福）：プロダクトを使ってどう感じるか
Engagement（愛着）：プロダクトを使う頻度
Adoption（採用）：ユーザー化のための行動を満たすか
Retention（維持）：プロダクトに戻ってくる（複数回利用する）か
Task Success（機能達成）：ユーザーは早く・簡単に目的を達成できるか
入り口であるTから最もハードルの高いHに向かって、T→R→A→E→Hと進む過程で、ユーザーはブランド選好を高めていきます。具体的な例にするとこんな感じでしょうか。
Suicaをチャージして使って（T - 機能達成）
↓
またチャージして使って（R - 維持）
↓
モバイル会員登録して（A - 採用）
↓
電車だけでなくコンビニでも使って（E - 愛着）
↓
Suicaってホントに便利！Suicaなしではいられない！（H - 幸福）
このフレームワークを用いることで、自社の顧客がどのステップにどのくらいいるのか、次のステップに進むとは具体的にどういう状態なのかがわかります。また次のステップに進んでもらうために何をすればいいか、検討する材料としても活用できます。
フレームワークの作り方
表の作り方は非常にシンプルで、以下のステップをH / E / A / R / Tの各段階ごとに繰り返すだけです。
・Goal（目標）を決める
・Goalを表すSignal（信号）を定める
・Signalの発生を検知するMetrics（指標）を定める
・それらを表に落とす
例えば上記の表では、HappinessのGoalを「ユーザーがこのアプリを便利で必要だと好意的に思うこと」としました。そのGoalを達成できているかを示すSignalは「アンケートに答える、星5をつける、レビューを書き残す」としています。
そしてSignalを計測するMetricsを考えます。「アンケートの回答率、星5がつく割合、星5をつけたユーザーがレビューを書き残した割合」が指標にできそうです。
これをEngagementのGoal、Signal、Metricsは…とH / E / A / R / T各段階ごとに繰り返し、定めていきます。
HEARTを使うメリット
① まとまっている
まあフレームワークだからまとまってるでしょ、というとそうなんですが。
このGoal・Signal・Metricsに要素を当てはめるだけで、ユーザーの各段階のUX指標が一覧で設計できます。とても直感的ですし、直感的だからこそ、この表を自社のサービスに合わせてより細分化したり、カスタマイズすることもできます。利用ハードルが低く、組織内での再現性（誰でも使える感）が高いのがグッドです。
またHEARTというグルーピングを示しているおかげで、何をどこまでやればいいかが限られている点も使いやすさを高めていると思います。3×5マスを埋めたら作業完了・UX指標完成！としている点で、曖昧だった「目標設計」という業務フローが、かなり明確になっていると思います。
② 専門知識がなくても指標設計に参加しやすい
HEARTにおける「Goal」「Signal」は日本語で定義します。そのため解析に関する高度な知識がなくても、表でいう左側2列の10マスまでは埋めることができます。
「Metrics」を定めるには分析の知識が、またそれを取得する仕組みづくりにはエンジニアリングの知識がそれぞれ必要ですが、この部分はチームで作業を代替すれば難しくはありません。
HEARTを使う注意点
① 指標だけで良い悪いの評価をされてしまう
この手法で指標設計をして、万が一その指標が施策後に改善しなかった（悪化した）場合は残酷です。
仮説がそもそも誤っていた、仮説は正しかったが施策が誤っていた、というケースはあってしかるべきものですが、事業モデルによっては取り返しがつきません。自社プロダクト・自社サービスならまだしも、クライアントワークで「うまくいかなかったので最初から作り直します」と言えるケースは、基本的にありません。
プロジェクト自体の定性評価に加えて、指標で見てもいい結果が出ているということになればとても素敵ですが、そうならなかったときを考えると、これをまるまるワークの評価に用いるのは、注意が必要だと思います。
② 指標の改善がKGI改善に直結しない
ここで取り扱った指標は「KPI」でなく「UX指標」であるという点は注意が必要です。
一般に「KPI」は「KGI」を分解したもので、「KPIの改善」は「（短期・長期を問わない）KGIの改善」と同じ意味であるべきです。しかし「UX指標」は「KGI」とは独立した指標です。
当然UXの改善は高い確率でKGIの改善に紐付くべきで、顧客がHappinessに至れば長期的には売り上げも高まるようサービスが設計されているはずです。しかし実際には、収益化の仕組みが高度に成立してない限り、UX改善への先行投資は永久に回収できません。
非常に極端ですが、例えばレストランを経営していたとして
UXを高めよう
↓
アンケートの結果、UXを損ねているのは価格だとわかった
↓
だから無料で食事を提供するんだ
↓
UXが非常に高まった！
という結果があったとしても、この例でKGI（利益）を改善するのは全く不可能でしょう。UX指標それ自体が直接KGIをドライブするものではないという点は、直感的でなく少し残念ですが、留意しておくべき事実だと思います。
まとめ
これから積極的に使っていきたいフレームワークの一つとして、HEARTをまとめました。
発表自体はだいぶ前（2014年？）なので目新しいものではありません。当時流行しなかった理由は、UXというワードがまだ流行りきってなかったから？なんでしょうか。
今ではUXというワードはその重要性も合わせて、業界で浸透しきった感があります。それらを指標化するという取り組み自体に面白みがありますし、単なるKPIツリーだけで説明しきれないサービス・プロダクトでも利用することができて使い勝手が良いと思いました。
どうしてもKPI改善に気を取られると、長期的にこれでいいんだっけ、という疑問や自己批判が浮かびます。HEARTフレームワークは、明確なKPIを持ちづらいスコープ（コーポレートサイトやアバウトだけのサイトなど）でも使えそうだなと思いました。個人的にはファンベースな施策や経営が好きなので、ファンを増やしていく取り組みを顧客に提案する際に、このフレームワークを用いながら説明していきたいと思います。