この記事はフルリモートデザインチームGoodpatch Anywhere Advent Calendar 2021 23日目の記事です。
2020年のGoodpatch Anywhereアドベントカレンダーで @qnoub が体験構造図を発表してから1年、Goodpatch Anywhere内でのR&Dや実践を通じて見えてきた体験構造についての私的な解釈をしたためます。
TL;DR
良いサービスをつくると良い体験がうまれて事業が良くなるって話
体験構造図とはなにか
体験構造図とは、サービスを利用するユーザーの体験を、KPIやファネル等の数値と関連づけて構造的に整理したものです。
この一年間で行ってきたこと
体験構造図の概念を広くサービス開発に適用することができるよう、活用方法や運用の定義と作成手順のフォーマット化をすべく、Goodpatch Anywhereのクライアントワークを含め様々なプロジェクトでの実践と研究を行ってきました。
体験構造図の例
/w=3840,quality=90,fit=scale-down)
ユーザー行動（ジャーニー）の構造をベースとするのが僕は好みですが、ゴールとする行動へ向けて、次のユーザー行動（結果）が起きる原因とな(りう)るユーザー体験をのせるのがベーシックな形になります。
ゴールとする行動がある場合はファネルと相性が良いことが多かったりしますが、明確にこうという形もなく、適切な構造を模索していくのがミソです。一昨日のmtgで、既存サービスと新規サービスでも表現の仕方って違うよねって話になりました。
※ToBeのユーザー体験の箇所に、「実際にあった具体的なユーザーのエピソード」をマッピングしたりすると、より手触り感を持てるかもしれません。
体験構造図とKPIの関係
“「KPI」を成長させる「ユーザー体験」” という関係を構造化しています。
/w=3840,quality=90,fit=scale-down)
事業のマネジメントにおいては、KPIの設計と運用が非常に重要ですが、サービスの企画を行う現場ではKPIやそれに紐づく数値が目標になることはあっても、アイデアの源泉となることはありません。
それは、私たちが作っているサービスが、直接KPIの数値をつくっている訳ではないからです。
例えば、KPIがCVRであるとしたら、そのCVRやCVは「hogehogeさんがサービスをこんな風に利用した」といった一つ一つの事実が抽象化されて出来ています。
サービスが直接つくるのは、そうした事実の方です。「私たちはどういった事実を起こそうとするべきなのか」という問い, 目標を持つことで、アイデアを生み出しやすくなります。
体験構造図の活用
体験構造図は、「そのユーザー体験が発生することで次の行動が生まれる」という因果関係を表現しています。
理想のユーザー体験をサービス開発の目標とし、「どんな価値を追加したらその体験を起こすことができるだろうか？」「いまの機能や画面で、この体験を遠ざけている阻害要因はどこか？」「どこかに新しい導線を引くことはできないか？」と、機能追加や改善といった施策を考えていきます。
こうして抽出した施策たちのマネジメント（仮説構築・検証）方法も開発したんですがそれは今は内緒にします。
また、体験構造図の作成や施策構築にあたって、解像度が低い箇所についてはユーザー調査（デザインリサーチ）を行うべき範囲とし、調査設計・実行へ進むこともあります。
体験構造図の作りかた
- KPIツリーなどから扱うKPIをピックアップ
- KPIの構造を明確化（ファネル等）
- 2に関連したユーザーのジャーニーを構造化
- 3のオブジェクト間に数値をいれる
- 3のジャーニー間で、次のジャーニーに進むような理想的なユーザー体験を定義する
- B = matなどで抽出して定義することが多い、論理の破綻が発生しやすいので複数人でのレビューや因果関係に注目したセルフ批判を重点的に行う必要がある
- 大抵の場合、シンプルな表現になる
- 5で定義したそれぞれの理想的なユーザー体験の要因となる体験を洗い出す
- 構造の全体感を整える
- ユーザー体験（原因）とユーザー行動（結果）の因果関係を表現した体験構造図ができる
3をつくるためにユーザーの操作を書き出してグルーピングしてジャーニーとすることも
5をさらに B = mat にかけたり
体験構造図のはまりどころ
- 体験構造図は仮説である
- 調査や施策（仮説検証）を通じて、都度アップデート, チューニングを行う必要があります
- 体験構造図が絶対の正解ではありません。疑いの目と飛躍の機会に貪欲さを持ち、野心的なアイデアを制限することは望ましくありません
- 体験構造図は運用していくものである
- 作っただけで何かが勝手に良くなることはありません。実行こそ全てであり、体験構造図はより良い実行を支えるものです
- 論理破綻が起きやすい
- 作成プロセスにヒューリスティックな工程が多く、誤りや矛盾、破綻が発生していても作業者が気付けないことがあります。「因果関係になっているか？」という観点をもち、複数人でのレビューやセルフ批判を行っていくことでこれを防ぎましょう。（論理破綻が起きていないからといって絶対に正しいこともないですが）
体験構造図が果たす役割
事業数値の因果関係にあたるユーザー体験に照準を合わせることで、「どうしたらこの体験を起こせるのか？」といった問いを持てるようになります。
この問いはサービス開発に関わるメンバーの道標となり、そのユーザー体験を目標として創造性を発揮することができます。
これは、経営がもつ戦略やサービスのビジョンを、サービス開発に関わるメンバーが仕事の中で意識し活かしやすい抽象度にフィットさせ、戦略と実行を繋げていると言えます。
戦略やビジョンを意識して、イシューに集中して取り組んでいる組織の推進力、どんどん良くなっていくサービスを想像するとわくわくしませんか。しますよね
- 一緒に体験構造図やデザインを実践を通じて研究していきたい人はこちらまで
- 事業成長に体験構造図を活かしてみたい方はこちらまで
/assets/images/8368467/original/1a35a98f-1752-4af1-9512-00d3dc369e0a?1639964808)