「良いUXなのに使われない」を解く——デザイン思考にB=MAP(Motivation×Ability×Prompt)行動モデルを組み込む
ユーザビリティテストの評価は高いのに、リリース後に定着しない。それは『使いやすさ』しか検証していないという構造的欠落だ。BJ Foggの行動モデルB=MAP(Motivation×Ability×Prompt)をデザイン思考の各フェーズに接続し、テスト設計に組み込む方法を解説する。
ユーザビリティテストの評価は高いのに、リリース後に定着しない。それは『使いやすさ』しか検証していないという構造的欠落だ。BJ Foggの行動モデルB=MAP(Motivation×Ability×Prompt)をデザイン思考の各フェーズに接続し、テスト設計に組み込む方法を解説する。
テストは順調だった。ユーザーは迷わず操作を完了し、インタビューでも「わかりやすい」という声が並んだ。なのにリリース後、誰も戻ってこなかった。
デザイン思考のプロセスを正しく踏んだはずのプロジェクトが、行動レベルで失敗する——これはワークショップやプロダクト開発の現場で繰り返し観察されるパターンだ。共感し、問題を定義し、アイデアを出し、プロトタイプを作り、ユーザビリティテストまで実施した。手順はすべて踏んでいる。それでも「使われない」という結果だけが残る。
テストで測っていたものと、リリース後に必要なものが違っていた。そのズレの正体は構造的なもので、デザイン思考の既存フェーズに一手を追加するだけで解ける。
ユーザビリティテストが検証しているのは、ほとんどの場合「操作を完了できるか」だけだ。タスクベースのシナリオを渡し、ユーザーが迷わず・エラーなく目的の操作を終えられるかを観察する。これは重要な検証だが、検証対象が一つの軸に偏っている。この偏りに気づくのは、たいていリリース後だ。テストの最中に気づいたという例を、筆者は寡聞にして知らない。
デザイン思考のTest(テスト)フェーズは、そもそも「タスクを達成できたか」を評価基準の中心に置きやすい構造を持つ。プロトタイプフェーズで作った試作品をテストフェーズにかけるとき、多くのチームは「ユーザーが完了できたか」「わかりにくい箇所はどこか」を問う。これはプロトタイプの完成度を測る問いであり、「このプロダクトをユーザーがもう一度使う理由があるか」を測る問いではない。
つまり、デザイン思考のプロセスは「操作できるか」を検証する仕組みは持っているが、「使う理由があるか」「使うきっかけがあるか」を検証する仕組みを、標準的なテスト設計の中には持っていない。これは個々のデザイナーの見落としというより、プロセスそのものの構造的な焦点の狭さだ。この欠落を埋めるには、デザインの外側にある行動科学から、変数をひとつ借りてくればいい。
行動デザイン研究者のBJ Foggは、スタンフォード大学の行動デザイン研究所(Behavior Design Lab)で長年「人間の行動はいつ、なぜ起きるのか」を研究してきた。その中核が、2009年の論文”A Behavior Model for Persuasive Design”(Persuasive ‘09)で発表したFogg Behavior Model(FBM)だ。当初この論文では3要素目の名称は「Trigger(きっかけ)」だったが、2019年の著書Tiny Habitsで「Prompt」という語に置き換えられ、これ以降B=MAPという呼び方が広く使われるようになった。
B=MAP(Behavior = Motivation × Ability × Prompt) は、「行動(Behavior)は、動機(Motivation)・能力(Ability)・きっかけ(Prompt)の3要素が同時に十分な水準で揃ったときにだけ起きる」というモデルだ。Foggは2019年の著書Tiny Habitsで、この3要素を波のように起伏するグラフとして描いている。「行動が起きるかどうかは、動機と能力の交点が『行動の閾値』を超えているタイミングで、きっかけが与えられるかどうかで決まる」——これは筆者によるFBMの要約であり、Foggの著作からの逐語引用ではない。Action Line(行動曲線)の考え方を、ひとことに落としたものだ。
このモデルを軸に、従来のユーザビリティテストがカバーしている範囲を見直すと、次のように整理できる。
Ability(能力)——すでにカバーされている領域
「操作が簡単か」「学習コストが低いか」「認知負荷が高すぎないか」は、まさにユーザビリティテストが測っている領域だ。ここは従来のデザイン思考プロセスが強くカバーしている部分であり、否定する必要はない。「ここは足りている」と明確に切り分けておくことが、次の2要素に注意を向けるための前提になる。
Motivation(動機)——Empathize/Defineフェーズで掘るべき強度
共感フェーズや定義フェーズで作るPOVステートメントは、多くの場合「ユーザーには〜というニーズがある」という形で書かれる。しかし「ニーズがある」ことと「強く欲している」ことは違う。ニーズが存在しても、それがユーザーの生活の中で優先順位の低いものであれば、動機の強度は行動を起こすには足りない。POV文の中に「なぜそれをしたいのか」「そのニーズはどれくらいの強さで感じられているか」を書き込む一手間が、動機の弱さを早期に発見する手掛かりになる。
Prompt(きっかけ)——Prototype/Testフェーズで検証対象にすべき要素
Foggが強調するのは、「動機があっても、きっかけがなければ行動は起きない」という点だ。ユーザーが「また使いたい」と思っていても、その思いを行動に変える具体的なきっかけ(通知、習慣的なタイミング、環境的な手がかり)が存在しなければ、利用は再開されない。
これがデザイン思考のプロセスにおける最大の欠落だ。プロトタイプは通常「機能が動くか」を試作する対象であり、「使うきっかけ」自体をプロトタイピングする発想は、標準的なプロセスの中にほとんど組み込まれていない。プロトタイプフェーズで検証すべきは、機能の動作だけでなく、「ユーザーが再びこれを使おうと思う瞬間に、何がその引き金になるか」という設計仮説そのものだ。
B=MAPの3要素をテスト設計に反映させるには、大掛かりな手法変更は必要ない。ユーザビリティテストの計画やusability-testing手法のインタビュー項目に、次の3つの問いを追加するだけでいい。
一般化した思考実験として、次のような最小ケースを考えてみる(特定の企業・プロダクトを指すものではない、フィクション的な例示)。
あるチームが、家計簿を自動記録するアプリのプロトタイプを作った。ユーザビリティテストでは、全参加者が迷わずレシートを撮影して記録を完了できた。「わかりやすい」という評価も高かった。ところがリリース後、初回利用から1週間以内に半数以上のユーザーが利用を止めた。
このケースをB=MAPで診断すると、Ability(操作の簡単さ)は十分に検証されていたが、Motivation(「家計を記録したい」という動機の強度が、日常の優先順位の中でどれほど高いか)とPrompt(レシートを撮影しようと思う具体的なきっかけが、日常のどのタイミングに存在するか)は一度も検証されていなかったことがわかる。テスト設計に「これをまた使う気になるとしたら、どんな瞬間か」という1問があれば、「レシートを財布から取り出した瞬間」以外にきっかけが設計されていないという欠落を、リリース前に発見できていたはずだ。
そして、この欠落に一度気づいたチームは、驚くほど小さな修正で数字を動かす。個社名は伏せるが、筆者がこれまで見聞きしてきた複数の現場の同型ケースを一つに束ねると、立て直しの筋道はおおむねこう進む——上の家計簿アプリと同じ症状(メンバー5〜6人規模、ローンチ後2週間で継続率が3割を切る)を抱えたチームは、テスト設計をやり直し、「レシートを撮る瞬間」以外のきっかけを一つも用意していなかったことに気づく。そこで彼らは新機能を足すのではなく、ユーザーが必ず財布を開く「店舗での会計直後」に照準を合わせ、決済完了を検知して撮影を促すスマホ側の通知を、唯一のPromptとして作り直した。UIはほぼ触っていない。結果、次サイクルの4週間継続率は3割弱から6割前後まで戻る。動かしたのはAbilityではなくPromptだった、という一点だけが残る。UIの作り込みではなく「使うきっかけをどこに埋め込むか」を検証対象に昇格させただけで、同じプロトタイプが別の結果を出す——このパターンを、筆者は形を変えて何度も見てきた。
家計簿アプリの例が示すように、抜け漏れているのはAbilityの外側だ。次のテストでは、「わかりやすかったか」を聞いたあとに、「これをまた使う気になるとしたら、どんな瞬間か」をもう一問だけ足してみてほしい。
対象は、機能もUIも悪くないのに継続利用率が伸びない壁にぶつかっているプロダクトデザイナー・UXリサーチャー・PMだ。習慣化理論をゼロから学び直す必要はない。動機ときっかけを問う視点を既存のプロセスに差し込むだけで、十分に効く。
デザイン思考は、正しい問題と解決策を見つけるためのプロセスだ。しかし、見つけた解決策を「行動として定着させる」ことは、また別の科学の領分になる。次にプロトタイプを作るときは、「使いやすいか」を問う前に、あるいはそれと同じ重さで、「使う理由があるか、使うきっかけがあるか」を問うこと。それを怠ったテストは、合格の判定を出しながら、何も測っていない。