現状把握または要求分析のツールとして作るジャーニーマップ

みなさんがUXデザイナーやディレクターとして新しいプロジェクトにジョインする際、プロジェクトの状況を整理するためにステークホルダーの目的や要求、現状の課題感などさまざまなことをヒアリングしますよね。ただ、実際のところヒアリングで聞き出したことがプロジェクトを進めていく中でブレていくことが多いと思います。具体的には

  • ステークホルダーが目的や要求を正しく把握していない
  • ステークホルダーが目的や要求をうまく言うことができない
  • 課題ではなく仕様が要求になる
  • ステークホルダー同士(例:エンジニアリングサイドと企画サイド、上司と現場など)で目的や要求、課題感がバラバラ
などのブレです。このようなブレがあるとで
  • プロジェクトを進める中で課題や目的が何度も変わる
  • 複数の課題を解決しようとして議論の焦点が定まらない
  • ユーザーの視点を忘れたまま仕様やビジュアルが決められる
という状況に陥りがちです。決定に時間がかかるのでスケジュールが遅れますし、ユーザーへ提供する価値が不明瞭うなままプロジェクトを進めることになります。そんな状況だと作る側だってストレスが溜まります。

もし下の3つがうまくいっていればプロジェクトが大きく失敗することはないと思います。
  • 課題が不明瞭なこと
  • 課題がうまく表現されていないこと
  • 課題が共有されていないこと

今回はUXデザインを円滑に進めるために、ステークホルダーの持っている課題を明らかにし、その課題を表現し、表現した課題を共有するための方法としてジャーニーマップを活用する方法を紹介します。

どんなジャーニーマップを作る?

ステークホルダーそれぞれが考えるユーザーの利用導線(ほぼ要求と同等)をジャーニーマップで表現したものが現状把握のためのジャーニーマップです。このジャーニーマップはワークショップ形式で作成します。ジャーニーマップを利用することでユーザー視点での表現と購入からユーザーサポートまでユーザー体験全体をステークホルダー自信が俯瞰することができます。

ジャーニーマップの作成には記載項目を指定するテンプレートを利用します。このテンプレートはステークホルダー全員同じものを利用します。ステークホルダーそれぞれ同じ視点でユーザー体験を見るためです。以下が私がよく使うテンプレートの例です。

UXTimeline
ジャーニーマップのステージにはパーチェスファネルを活用することでマーケティング担当者からエンジニアまでわかりやすくなります。私の場合以下のステージで固定することが多いです。
  • 認知時
  • 検討時
  • 購入時
  • 利用時
  • 利用後
もしバイラル回して利益を設けるようなビジネスなら利用後の次に「発信時」など入れてもよさそうです。フリーミアムモデルのようなビジネスだと検討と利用の段階が曖昧になりますが、作業慣れしていないステークホルダーも確実に記載できるよう複雑にしないほうが良いです。

ジャーニーマップは要求を含めたものなのでTo-Beタイプです。現状をトレースするAs-Isタイプはないので感情マップは不要です。その感情は担当の想定でしかなく、感情マップはむしろ使い道に困るので書かないようにするほうが良い気がします。あと目的にもよるのですが、プロジェクトが既存サービスやプロダクトの改善であればこの方法での現状把握はやらないほうが良いです。同じジャーニーマップでも現状リリースしているサービスやプロダクトの利用シーンをトレースするAs-Is型のジャーニーマップを書くほうが効果的だと思います。

ジャーニーマップを作るワークショップ

ジャーニーマップはワークショップ形式で作成します。ステークホルダー個人がペルソナを作り、そのペルソナをもとにジャーニーマップを作ります。どちらもデータではなくステークホルダーの想定を書いてもらいます。ペルソナはシナリオとちょっとしたプロフィールの書かれた簡単なものを10分程度で、ジャーニーマップは20~40分程度で作成します。真実ではなく想定を聞きたいだけなので、詳細に書かれる必要はありません。

作成したジャーニーマップは参加者それぞれに発表してもらいます。デザイナーは発表されたジャーニーマップそれぞれに対するステークホルダーの反応を観察し、どの案が共感を得られるのかを見つけます。共感を得られた案は自然とステークホルダーの共通意識となることが多い気がします。発表をなくしてしまうとステークホルダーが共感するポイントを見つけられないので発表は必ず実施します。

ターゲットユーザーが明確なビジネスであればペルソナはデザイナー側で指定してもよいかもしれません。しかしステークホルダーそれぞれで結構想定しているターゲットユーザーが違うことが多いので「プロジェクト内でターゲットユーザーすら認識が違う」ということを明確にするチャンスです。ときどき杞憂に終わる場合もありますがペルソナは作ってもらったほうが確実な気がします。

参加するステークホルダーは小さいチームであれば全員、大きいプロジェクトであればヒエラルキーの高い人と低い人を必ず入れるようにしましょう。ヒエラルキーの高い人はもちろんのことですが、より現場に近かったり開発の下流工程にいるメンバー(プログラマーやコールセンターなど)にも参加してもらうと効果的です。現場の意見は意思決定者と同じぐらい貴重な場合があります。

このようなワークをやろうとすると拒否反応を起こす人もいます。もし拒否反応が起こりそうであれば「ワークショップ」とはあえて言わず「普通の会議」としてメンバーを招集するとよいかもしれません。私の体験談ですが、会議と言いつつゲリラ的にワークショップをやる方が拒否反応が少ない気がします。その際は「現在のビジネスについて教えてください」など、教えてもらう立場として臨むと上手くいく気がします。これはデザイナーじゃなくてサラリーマンとしてのテクニックですわ。ザ。日本人。

ジャーニーマップを作ったあとどうするの?

発表されたジャーニーマップを元にデザイナーがジャーニーマップを作り直します。共感されたポイントを整理し、論理的につながるようまとめます。論理的につながらない要素は排除し、課題や可能性として別資料にリストアップします。できあがったジャーニーは「みなさんの考え」としてステークホルダーへ共有します。これでヒアリングでは見えなかったプロジェクトの現状が把握できるはずです。。

このジャーニーは現状整理のツールです。ジャーニーを作り終わった状態はヒアリングが終わった状態と同じだと思ってください。このあとの作業はプロジェクトのプロセスに依存しますが
  • 作成したジャーニーを仮設としてユーザー調査する
  • クリエイティブブリーフやビジネスモデルキャンバスなど目的やビジネスストーリーを表現できる資料を作成する
  • 作成したジャーニーを元にステージごとの戦略を練る
  • クライアントと共に要求を見直す
などがあるでしょうか。このジャーニーは「ゴムのユーザー」のようにステークホルダーが自分の都合のいいように作ったジャーニーなのでユーザーモデルとして信用できるものではありません。あくまでこれはヒアリングでは難しい「課題が不明瞭なこと」「課題がうまく表現されていないこと」「課題が共有されていないこと」への対策としての作業です。そうだとしても、全てのステークホルダーがひとつの課題に向かって解決方法を考えるきっかけを与えることができるようになるので、決まった要求から仕様やIAを検討するよりずっと効果的です。やらないよりやったほうが圧倒的にマシってやつです。

副次的効果

私の体感なのですが、このようなジャーニーマップを作ってもらったあと、これまでタッチポイントごとの検討しかしてこなかったステークホルダーが自発的にユーザー体験(時間軸)をふまえた検討を始めるようになる気がします(もちろんそうじゃない人も多数ですが)。

マネージャーが組織作りや仕事のアサインにジャーニーマップを活用したこともありました。

まとめ

これはデザインの前段階としてステークホルダーのことを知るための作業です。ステークホルダーを知る作業なので、最近UX界隈で活発に議論されている「カスタマーとの共感」につながる作業でもあります。あくまで状況把握や要求分析のツールなので、さまざまなフレームワークの一つとして候補に入れてもらえれば幸いです。