カスタマージャーニーマップを発表するときは、顧客の目標を一つ選び、重要な場面の根拠を示し、最後に検証したい変更へつなげます。すべての段階に感情や困りごとを埋めるところから始めないでください。どの体験に、なぜ注目すべきなのかを聞き手が理解できると、マップは役に立ちます。
ここでは、新しいチームアカウントがワークスペースを作り、最初のプレゼンを共有するまでを例にします。以下の観察、数値、発言はすべて説明用に作った架空の情報です。Presentiのアクセス解析、実際のインタビュー、顧客の成果ではありません。
自分たちの調査がまとまったら、Presentiでジャーニーの調査結果をマーケティング資料に整理できます。根拠の番号をスライドにも引き継ぎ、生成の過程で仮定が顧客の事実に変わらないようにします。
マップを見せる前に対象範囲を伝える
目標と対象区間を一文にします。「新しいワークスペースの管理者が、最初の下書きを同僚に確認してもらいたい。今回はワークスペースの作成から最初のプレゼン共有までを調べる」。対象の利用者層と利用経路も示します。二つ目のプロジェクトに戻ってきた経験豊富な管理者は、別のジャーニーです。
NN/Gは、目標を達成しようとする人を軸にジャーニーマップを定義しています。この軸があれば、プレゼンが機能一覧になるのを防げます。製品のナビゲーションに十の項目があっても、利用者が通るのは三つだけかもしれません。
資料から分かることと、分からないことを示す
調査チームが、次のような架空の記録をワークショップに持ち込んだとします。
| 記録 | 観察の例 | 裏付けられること |
|---|---|---|
| U-01 | 参加者が下書きを作り、上部ナビゲーションで招待の操作を探してから、編集画面に戻った。 | その回では招待の操作がすぐには見つからなかった |
| U-02 | 参加者がShare（共有）を見つけたが、同僚にワークスペース全体が見えるのか質問した。 | 共有時に権限について疑問が生じた |
| S-01 | サポートに寄せられる相談の例に、リンクからのアクセスに関する質問がある。 | アクセスに関する表現は調べる価値がある |
| A-01 | イベント記録の例では、最初の共有より前に編集が行われている。 | この例の流れでは、編集の後に共有が位置する |
これらの記録だけでは、問題がどの程度よく起きるかは分かりません。U-01は招待がいつも見つけにくい証拠ではなく、A-01も共有まで待った理由を説明しません。感情を実際に聞いていないなら、滑らかな感情曲線を描かないでください。実際のプロジェクトでは、各発見に調査方法、日付、参加者の状況、出典を残します。
NN/Gの調査ガイドは、体験した本人からジャーニーの情報を集め、定量的な根拠も加える方法を説明しています。両方を使って理解を深め、仮定を調査済みの事実に見せないようにします。
記録を一枚の読みやすいマップにする
この架空の例では、ワークスペース作成、下書き準備、レビュー担当者の招待という三段階を使います。各段階の下に作業と関連する記録IDを置き、解釈は別の行に分けます。そうすれば、「招待操作の位置が悪い」という解釈には異論があっても、U-01に探索が記録されていることには合意できます。
| 段階 | 顧客の作業 | 記録 | 考えられる解釈 |
|---|---|---|---|
| ワークスペース作成 | 始め方を見つける | この例には記録なし | 空欄を埋めるために困りごとを作らない |
| 下書き準備 | レビューに出せる内容を作る | A-01 | 招待する前に内容を用意したいのかもしれない |
| レビュー担当者の招待 | 適切な内容を適切な相手と共有する | U-01、U-02、S-01 | 操作を見つけることと、権限を理解することは別の問題かもしれない |
スライドが混み合うなら、出典の詳細は別のスライドに移します。主なマップには、次に判断する問いを残してください。次の調査で見るのは、招待操作を見つけられるか、それともアクセス範囲を理解できるかでしょうか。
変更を選ぶ前に、二つの仮説を比較する
架空のチームには二つの仮説があります。H1は、招待操作の場所が見つけにくいというものです。H2は、操作は見つかるものの、付与されるアクセス権限が分からずためらうというものです。目立つボタンはH1には役立っても、H2を解決しないかもしれません。アクセス範囲の説明を明確にすれば、ナビゲーションを変えずにH2へ対応できる可能性があります。
それぞれのきっかけとなった記録と一緒に、仮説として示してください。作り物の「影響度スコア」で順位を付けないことが大切です。選ぶための根拠が足りなければ、二つを区別できる調査を提案します。
次の調査で答える問いを示して終える
次の調査では、新しいワークスペースの管理者に下書きを同僚へ送ってもらいます。操作を見つけられるか、共有後のアクセス範囲を説明できるかを観察してください。アクセスについては、手助けする前に尋ねます。先に助けると、進行役が答えを教えてしまう場合があります。
成果は「五人の利用者で再設計の成功が証明された」という結論ではありません。参加者がどこを探し、何が共有されると考え、何を誤解し、次の改善でどの仮説に対応すべきかを記録することです。対象人数と制約も一緒に残します。実際のイベントデータがあれば、操作の頻度を調べるために使い、観察で得た理由とは区別します。
最後のスライドでは、未検証の再設計を承認してもらうのではなく、この調査の担当者と実施日を決めてもらえます。自分たちの記録ID、マップ、異なる仮説を使い、Presentiでジャーニーの資料を作ってみてください。根拠がない欄は、空欄のままにします。
