理想化しないリアルなカスタマージャーニーマップの作り方 – 海外のブログ (ブログ)

Home » 03マーケティング » 理想化しないリアルなカスタマージャーニーマップの作り方 – 海外のブログ (ブログ)
03マーケティング, ペルソナ コメントはまだありません



本記事はA Book Apartから発売されているEric A. Meyer氏とSara Wachter-Boettcher氏の新刊、『Design for Real Life』第7章の転載です。


リアルなユーザーのためにデザインされなかったために、デジタルプロダクトが残念な結果に終わってしまった、という経験はあるだろう。きっとあなたは共感の重要性は理解しているはずだ。会話からユーザーの深層心理やニーズを引き出す方法も学んだだろう。しかし思慮深いはずのデザインチームが最良の意図を持ってデザインしても、迷子になってしまうことがよくあるのだ。

必要なのは各ステージに共感できる仕組みを取り入れたデザインプロセス、つまり、初期のリサーチ段階からリリースに至るまでデザインをブラッシュアップしていく中で、現実のユーザーとニーズが重視され再びそれらが中心に置かれるようなプロセスだ。

現実的なアーティファクトをつくる

Design for Real Life』第3章では、最悪の事態を想定してデザインする重要性、そしてペルソナやカスタマージャーニーマップなどのオーディエンスのアーティファクトにストレス環境下でのケースを使ってみるのがいかに有用かについて書いた。ではそのようなマテリアルの作成方法について説明しよう。

ペルソナを理想化しない

リサーチフェーズで多くのユーザーが心を開いてくれれば、実際の人間の豊かな感情をデータへと引き出すことができるようになる。夫婦問題、最悪の別れ、事故、自殺を図った友人や、いじめられた過去などだ。インタビューした相手の話を直接使うというより、人々の抱える複雑なテーマや、多様な苦労体験について考えるヒントをもらえることが重要だ。ペルソナの心理状態、トリガー、そしてニーズに関する現実的な詳細について盛り込む手助けになる。年齢や収入、住んでいる地域や学歴などの典型的な統計だけに頼るよりも、もっと深く役立つはずだ。

こういう多様なインプットは、より良いペルソナのイメージを選択するのにも役立つ。ストックフォトにあるようなお気楽な人々とは異なるイメージを探したり、撮影したりしてみてほしい。表現や服装のスタイルに変化を持たせよう。ユーザーインタビューでの答えと同じようにこのペルソナが答えてくれると想像できれば、プロセスは軌道に乗っていると考えていい。

現実に即したペルソナができれば、危機の瞬間を想像したり、ユーザーのストレス要因を引き起こすシナリオをテストしたりするのが随分と容易になる。「危機」と言っても、自然災害や深刻な救急疾患とは限らない。例えば注文がまったく違っていた場合や、ユーザーが空港に急いでいて情報が必要な場合だったりする。

ペルソナやシナリオを書くにあたって、実体が奪い去ってしまわないようにしよう。飾り立てず、可能ならユーザーのエピソードや言葉、感情の断片を取り入れよう。今後このようなペルソナを扱う誰もが、あなたと同じように彼らの力になりたいと強く思うだろう。

カスタマージャーニーマップの作り方

第3章では、Sara氏がリフォーム会社で用いた手法、すなわちカスタマージャーニーマップについて言及した。カスタマーエクスペリエンスマップとも呼ばれるこの手法は、例えばサンフランシスコに拠点を置くデザインコンサル会社Adaptive Path(最近Capital Oneに買収された)など、多くのデザインにおいて成果を築いている。

Adaptive Pathは2013年、専門知識を詳細なガイドの形に落とし込み、無料で使えるサイト「mappingexperiences.com」を作成した。このガイドはカスタマーエクスペリエンスをどのように調査するか、マッピングワークショップをどうファシリテートするか、またあなたのインサイトをどう生かすかということに重点を置いている。そのプロセスでは、以下のような項目を記録する。

  • レンズ:どのペルソナをマップするか、またそのシナリオは何か?
  • タッチポイント:ユーザーがあなたの会社とやり取りする瞬間は?
  • チャネル:そのやり取りがどこで起こるのか?オンライン、電話、または他の場所は?
  • アクション:ユーザーが自分のニーズを満たすために何をしているか?
  • 考え:ユーザーが自分たちのエクスペリエンスをどのように組み立て、期待値をどう定義しているか?
  • 感情:ユーザーが彼らのジャーニー(道筋)に沿って抱く感情(ポジティブ/ネガティブ)は?

多くのUXプロセスと同様に、ジャーニーマップの作成は通常、ポストイットを使って始める。チームに分かれ、時間をかけてユーザーの道筋を精密に示し、そのステップを水平方向に広げてゆく。各ステップの下には違う色のポストイットを使って、タッチポイントとチャネルの他に、ユーザーの行動、考え、そして感情を記述していく。結果として大きく(乱雑でもある)カラフルな格子模様が、壁に大きく広がっているはずだ(図7.1)。

Photo of sticky notes organized on a wall
図7.1:典型的なジャーニーマップのアクティビティ。参加者はポストイットを使って複数の段階を通じたユーザーの成長や、時間を追ったニーズを表す。

ジャーニーマップは利点だらけだ。ユーザーの観点からコンテンツを評価し、タッチポイントやチャネルでのギャップや食い違いを明らかにする助けになるし、メジャーなシステムを繰り返し徐々に改善するための枠組みを作ってくれる。その上、誰のジャーニーをマップしているか注意深く考えれば、以前には認識も検証もされていないストレス環境下でのケースを見出すのにこの手法が有力な手段になりうるということも、私たちは発見した。

理想化しない、現実的なペルソナとシナリオを用いるように心がけよう。例えば航空会社であれば、フライトのキャンセルに遭った人や、障害を持った親戚と旅行をしている人、または葬式に参列するために土壇場でチケットを予約する必要のある人などの体験を書き出すといい。銀行なら、住宅ローンに申し込んで断られた、長年取引のある顧客を書き出すといいかもしれない。大学なら、親世代が大学に行っていない低所得の家庭出身の学生などが考えられる。他にもまだ例はあるだろう。

私たちの経験から言えば、組織内からできるだけ多くの人にこの作業に参加してもらうことも重要だ。開発者やライターなどのWeb関連の人たちだけでなく、マーケティング、カスタマーサービス、セールス、ビジネスや製品部門などのグループからも参加してもらうべきだ。そうやって部署を越えて協力することにより、ジャーニーに多様な視点を持ち込むことができる。ユーザーが持つ可能性がある、様々なタッチポイントをより深く理解できるし、ある1つのチームが非現実的な想定をするのを防ぐことができるのだ。ユーザーの道筋を物理的に記述していくという、この活動の実践的な性質によって、全員がユーザーの考え方に真に入り込むよう強いられる。参加者が組織中心の考え方に引き戻されるのを阻止し、見つけた問題を修正するための助けを得られる確率が上がる。

理想的なエクスペリエンスを決めるだけでなく、うまくいかない場合の現実でのエクスペリエンスを記述するのにも時間をかけるべきだ。下記に例を挙げる。

  • ペインポイント:どういう箇所でユーザーがつまずき、問い合わせが必要で、またはサイトやアプリから離脱しようとするのかリサーチや分析によって判断する。
  • 途切れたフロー:タッチポイント間、またはサイト上での特別なインタラクション(フォームなど)を介したトランジションが、うまく機能していない場所。
  • コンテンツのギャップ:ユーザーがある特定のコンテンツを必要としているが、それが存在しないこと。または、適切なタイミングで適切な場所にないこと。

ジャーニーには多くのことを書き出せる。たとえばチャネル、疑問、感情、アクション、コンテンツのニーズとギャップ、カタリスト(触媒)、その他にもいろいろだ。そして様々な方法で視覚化することもできる。会議室の壁にポストイット(あとで振り返るための数枚の写真も)さえあればそれ以上は要らないこともあるだろう。またある時には、数日かけて協力し、事後にもっと洗練されたドキュメントを作成した方がいいかもしれない。これらはマップするエクスペリエンスの複雑さや、最終的なアーティファクトに必要な忠実度、そしてもちろんそのプロセスにどれだけ時間を割けるかにもよる。

チームメンバーにとってジャーニーマップが初めてなら、小グループでのキックオフやブレインストーミングセッションのうち1~2時間とって、各グループで違うユーザーの道筋の概略を書いてみると良い導入になる。すでにUXプロセスの一部なら、より広範囲のペルソナとシナリオに着手すればいいだけかもしれない。どちらにせよ、ストレス環境下でのケースにハイライトしたジャーニーマップを構築することにより、以下のことがわかってくる。

  • 緊急のユースケースに対応するため、他の人のエクスペリエンスを弱めることなくコンテンツの優先順位を決める方法。これは前述のリフォーム会社が取った手法だ。ストレス環境下でのケースを検証することで、わかりやすい言葉を優先し、何を、一覧のセクションを見てすぐに分かるように配置すべきかが考えやすくなる。
  • その時にユーザーが考えたり感じたりしていることからかけ離れた、または、ずれている説明や写真がある場所。例えば、生理カレンダーアプリのGlowが、タンポンを買い忘れているだけの独身の女性についてのカスタマージャーニーを書き出したとする。そうすればデザイナーは、それぞれのタッチポイントで、アプリのコピーがこの女性のニーズと感情について正しくない想定をしていたと理解することができたかもしれない。そしてより幅広いポテンシャルユーザーにマッチしたメッセージに調整することができただろう。
  • ストレス環境下でのケースのユーザー向けのコンテンツに何かギャップが存在しているかどうか。例えば、もしフィラデルフィア小児病院が危機に瀕しているユーザーのジャーニーマップを作成したとすると、Eric氏の体験したように、救急外来についての情報が病院のサイト上に存在していなかった、というコンテンツギャップを生まずに済んだかもしれない。

抑制と均衡をプロセスに取り入れる4つの手法

オーディエンスをより現実に近い形で表現できたら、次は、間違ってひどい結果になってしまうことを避けるように、抑制と均衡をあなたのプロセスに組み入れて、チームにリマインドする4つの手法をご紹介する。

1. WWAHDテスト

デザインに関する決定に関してストレステストをする場合、最も簡単な方法は「人はどう行動する?(WWAHD?—What would a human do?)」と聞いてみることだ。フォームをデザインするとき、すべての質問を想像上の人に対して読み上げて、その聞こえ方を確認し、どのような答えが返ってくるか想像してみるといい。

MailChimpのKate Kiefer Lee氏は、コピー文章の使われる場所や方法にかかわらず、このテストをすべてのコピー文章で行うよう勧めている。誤りを発見したり、フローを改善したり、表現を和らげたりする効果があるからだ。彼女は次のように述べている。

声に出して読みながら、現実の人間に話しかけているように振る舞い、「私は実生活のなかで誰かにこう言うだろうか?」と自問しよう。書いた文が時として、自分で思う以上に重苦しく、あるいは冷淡な印象を与えることもあるのだ。

今度何らかの文章を公開する時は、時間をとって声に出して読み上げよう。誰かに読み上げてもらい、それを自分で聞くのも有効だ。友人や同僚に頼んで読んでもらうか、テキスト読み上げツール利用しても良い(参考記事)。

上記の最後の点も、優れたアドバイスである。あなたの話を聞いてもメリットのないユーザーにとってあなたのコンテンツがどのように聞こえるかを、より良く認識できるからだ。合成された音声が読み上げるのを聞いて、言葉がおかしかったり、不快に感じたりする部分があれば、実際に画面上で使えるコンテンツにするにはまだ改善が必要だと分かるだろう。

2. プレモーテム

デザイン段階では、私たちは登録数や売り上げの増加、訪問頻度の上昇、エンゲージドユーザーの増加といった、想像上の結果にバイアスをかけてしまう。なぜなら、具体的な目標が頭にあって、それに精力を注ぐことになるからだ。しかしその場合、他の結果の可能性を忘れるか、少なくとも軽視しやすくなる。

そうしたバイアスを早期に解消する1つの方法は、プロジェクトのプレモーテムを行うことだ。プレモーテムとは、この用語名が示唆しているように、プロジェクトを事前に評価することである。Gary Klein氏によると、そうすればプロジェクトを「事後分析するのではなく改善することができる」。Klein氏は2007年の『Harvard Business Review』で、プレモーテムについて初めて記している。

プレモーテムを実践するにはまず、リーダーが、プロジェクトは大失敗だったとチーム全員に告げる。次に、数分間かけて、その失敗の原因として思いつくすべてのことを各自が自由に書き出す。(Harvard Business Review

Klein氏によれば、このプロセスは、「事前の後知恵(prospective hindsight)」をもたらすので効果がある。これはウォートン・スクール、コーネル大学、コロラド大学の研究者が1989年の研究で使った用語であり、「物事がすでに起こったと想像することで、チームが未来の結果に対する原因を正しく特定する能力は30%高まる」という。

例えば、運動・活動を追跡するアプリの登録プロセスをデザインしているとしよう。プレモーテムでは、「6カ月後、登録解除率が上がったとする。それはなぜか?」と考える。この仮定的状況を説明できる答えを想像するのだ。例えば、分かりにくすぎる、個人的すぎる情報を求めている、手違いでプロセスに行き止まりが生じている、など。想像することは、チームがその結果を回避し、より良いプロセスをデザインするのに役立つだろう。

3. 質問プロトコル

身に着けておきたいもう1つの手法はCaroline Jarrett氏の質問プロトコルであり、これについては第4章で紹介した。要約すると、質問プロトコルとは、以下の点について問うことで、ユーザーに尋ねるすべての情報が意図的かつ適切であるようにするツールだ。

– 組織内で回答を使うのは誰か
– 回答を何のために使うか
– 回答は必須、任意のどちらであるか
– 必須回答の場合、ユーザーがフォームを単に埋めようとして適当な情報を入力したらどうなるか

だが、プロトコルを作るだけではいけない。組織内で活用する必要がある。例えば、Jarrett氏はこのアプローチを、英国のガバメントデジタルサービス(GDS)の標準的手法に組み込んだ。GDSはその答えを使って、プロジェクトに携わるデザイナーやライターのための明確な戦略的ガイドラインを作成した。以下の例は、ユーザーの氏名に関するアドバイスである。

ユーザーの氏名を尋ねないことをおすすめする。

ユーザーの負担を増やし、性別や配偶者の有無を明かすよう強いる可能性があるが、ユーザーはそれを望まないかもしれない。連絡の際に氏名を使わずに呼びかける適切な方法はある。

氏名のフィールドを設ける必要があるなら、ドロップダウンリストではなく、自由入力の任意フィールドにする。ユーザーの肩書きの範囲を予測することは不可能であり、必ず誰かの気分を害することになる(GOV.UK Service Manual)。

推奨事項が明示されており、氏名を尋ねないことを勧める理由も説明されているので、このガイドラインに従えば、チームは初めから正しい方向に進むことができる。

ユーザープロフィールがプロダクトの体験の主要部分である場合、質問プロトコルを変更・拡張して、収集されたデータをある部門がどう使うかだけでなく、プロダクト自体がどう使うか説明することも必要かもしれない。例えば、レストランのレコメンデーションサービスは、ユーザーの位置情報を尋ねる理由について、「このサービスで近接度に基づいて結果の優先順位を付けるのに必要なため」のように説明することも考えられる。しかし、ビジネス雑誌、レシピのキュレーションサービス、さらには公営空港に至るまで、理由なしに位置情報を収集するサイトは数え切れないほど存在する。もしこれらの組織が質問プロトコルを使ったら、自分たちがやっていることの理由を説明するのに苦労するかもしれない。

この手法を「プロトコル」と呼ぶ必要もない。組織によっては、堅苦しすぎる呼び方であるし、これを確立されたデザインプロセスに追加するのは大変だろう。その代わり、これらの質問や手法を機能仕様の中に組み入れるか、会議の議題にすることも考えられる。ただし、どのように行うにせよ、「望ましい」というアドホックな形ではなく、一貫性がありプロセスに根づくような方法を模索してほしい。

4. 指名反対者

チームで作業をすると、各個人だけでは決してできなかった仕事を成し遂げられるので、力は何倍にも増大する。しかし、どんなチームでも「集団思考」に陥りがちである。つまり、意図的でない場合が多いのだが、多数意見に集まる傾向があるのだ。するとチームは、明らかに手遅れな状態になるまで、想定に対する疑問を持たないかもしれない。想定を疑うという明示的な仕事を誰か1人に割り当てることは、この問題を回避する1つの方法だ。

私たちは、この役割を「指名反対者(Designated Dissenter)」と呼んでいる。どのチームでも、「プロジェクトの基礎を成しているすべての決定事項を評価し、状況や想定に変化があった場合にその決定事項がどのようにくつがえりそうかを問う」という仕事を1人に割り当てるのだ。この仕事は、プロジェクトの存続期間中、指名反対者の主な役割となる。指名反対者は異議を唱え、考慮の足りない想定や起こりうる失態について指摘する義務がある。

例えば、第1章でFacebookの最初の「1年のまとめ」機能に至った想定について論じた。もしそのプロジェクトに指名反対者がいれば、Facebookは私たちとよく似たプロセスを経ていたことだろう。「このプロジェクトにとって典型的なユーザーとは?」と考え、「素晴らしい1年を過ごした人で、思い出を友人とシェアしたい人」という答えを出す。この答えが、「ひどい1年を過ごしたユーザーにとってはどうか? シェアすることに関心のないユーザーは? その両方に当てはまる場合は?」という最初の質問につながるのだ。

指名反対者は、そうした大まかな質問の域を超え、デザインのあらゆる側面に対して批判的な目を向ける。コピーやデザインの要素を注視して、「これがばかげていたり、無神経だったり、侮辱的だったり、どぎつかったりする状況とは? このエラーメッセージの想定が間違っているとしたらどうなるか?」と自問する。すべてのステップにおいて想定を見つけ、それをくつがえすのだ(前の数セクションで論じたツールは、このプロセスで非常に役立つ)。

しかし、その次のプロジェクトでは、別の誰かが指名反対者にならなければならない。それには2つの理由がある。

  1. チームの全メンバーが指名反対者の役割を引き受けることで、全員がそのスキルを学んで伸ばす機会を持てる。
  2. 同じ人がすべてのプロジェクトで指名反対者になると、チームの残りのメンバーがその人のことを、水を差す人として無視するようになる恐れがある。

全員が指名反対者を経験するまでは、どのプロジェクトにも新しい指名反対者がつく。チームに新メンバーが入ったら、その人にとって2番目か3番目のプロジェクトで指名反対者にしよう。そうすれば、難しい役割を引き受ける前に、チームの動き方にまず慣れて、物事の進み方を観察することができる。

こうした様々な手法の目的は、バイアスの研究者Jack B. Soll氏、Katherine L. Milkman氏、John W. Payne氏が「外部視点(outside view)」と呼んだものを設けることであり、それには非常に大きな利点がある。

外部視点があれば、「計画錯誤」に陥るのを防ぐこともできる。計画錯誤とは、実際には失敗する可能性がかなり高いのに、大成功するという物語を作り出してやっていくことである(Harvard Business Review)。

私たちの物語は大抵、完全な成功を描いている。実はそれこそが、デザインプロセスの要点である。しかし、まさにその目標のせいで、私たちは計画錯誤に陥りやすくなる。理想的ケースだけを想像して他の可能性は考慮しないという状況だ。

ストレステストを行う2つの手法

ユーザビリティテストはもちろん重要であり、ストレス環境下のケースでユーザビリティをテストすることはなおさら重要だ。問題なのは、多くのケースで、実際に危機的状況や他の高ストレスの状況のただなかにいる被験者を見つけられないことである。そして、たとえ見つかったとしても、その時期にユーザビリティテストを課すべきかは倫理的に見て疑問だ。では、そのようなケースについては、どうやってテストするのだろうか。

私たちは、これに役立ちそうな2つの既存の手法を特定した。1つはテストにとってより現実的な状況を作り出すこと、もう1つはユーザーがドラマのような状況のロールプレイをするシナリオを使うことである。

1. より現実的なテスト

第3章で紹介した実験では、知的活動の内容が難しくなると被験者の認知資源が減少し、意志力にも変化がもたらされた。

それを踏まえると、認知資源を消費する活動を各テストの冒頭で課すようにすれば、現実に起こる認知資源の消耗をより反映したユーザビリティテストにすることができる。例えば、被験者に記事を読ませる、単純な論理パズルを解かせる、『Bejeweled』のような気楽なビデオゲームを数回プレイさせる、メールの返信のような日常的タスクを行わせる、といったものだ。

被験者がそのような活動に従事したあとで、ユーザビリティテストそのものを実施する。最初のタスクで知的に消耗したり、状況が変化したりで、被験者が使える認知資源は減少していることになる。つまり、製品を実際に使う形に近づいているだろう。

ある意味、実験室にちょっとした実地テストを持ち込むようなものだ。これは、プロセスの初期段階で潜在的な問題を特定するのに役立つし、もし本当の実地テストを行うことができるなら、その分さらに効果的で有用なものとなる。

だが、テストにストレス要因を追加する前に、以下の要領で、ユーザーにその状況を知らせておくようにする必要がある。

  • 被験者に求める行為を明確かつ分かりやすく示し、テスト参加のインフォームドコンセントを被験者から得るようにする。
  • 被験者を個人的に評価するわけではないこと、そしてテストが難しくなりすぎたり負担が大きくなりすぎたりした場合は被験者がいつでも辞退できることについて留意し、それを被験者にも伝える。

結局、個人ではなくプロダクトをテストすることが目的なのだ。

2. ストレス環境下のロールプレイ

ボリウッド映画は壮大なストーリー展開と空想的な状況設定で知られているが、研究者のApala Lahiri Chavan氏によれば、ストレスに特化したユーザビリティテストの示唆にも満ちているという。

多くのアジア文化では、デザインを批評することは文化的に失礼であり、何かを見つけられないと認めるのは恥ずかしいことである。こうした背景があるにもかかわらず価値ある情報を得ようと、Chavan氏はテストの標準的タスクを空想的シナリオに置き換えた。例えば、被験者に、「姪が既婚の殺し屋と結婚しようとしていると知ったばかり」という状況を想像させる。被験者は、結婚することを直ちにやめさせるため、航空券を予約する必要がある。このようなロールプレイによって、被験者は文化的規範から抜け出すことができた。そして、ボタンラベルや分かりにくいフロー、プロセスの余分なステップに対して不満を述べたのだ(Chavan氏の方法と結果の詳細については、Eric Schaffer氏が執筆した2004年の書籍『Institutionalization of Usability: A Step-by-Step Guide』の129~130ページを参照)。

この方法は、アジア市場に売り込むのに便利なだけではない。ユーザーの背景にかかわらず誰かがあなたのサイトや製品をストレス環境下で使おうとする時に何が起こるか、ということを確認するのにも役立つ。現実の危機に直面している人に、プロトタイプのテストに協力するよう頼むわけにはいかないからである。しかし、危機的状況のロールプレイをユーザーに依頼することならできる。製品やサービスのテストを、医学的な緊急事態や、財布が盗まれたあと、事故に遭った直後などに試さざるをえないという設定にするのだ。

このプロセスは、ありとあらゆる危機的シナリオまでは扱えないだろうが、コンテンツの優先順位がおかしかったり、ユーザーフローが役に立たなかったり、メッセージが陽気すぎたりするような部分を特定するのに有効だろう。そして、すでにユーザビリティテストを行っているなら、危機的シナリオを1つや2つ加えても余分な時間は大してかからないだろう。

まとめ: 共感には協力が不可欠

以上の手法のそれぞれについて1つ気付いたかもしれないが、これらは基本的に分野横断的なものである。デザインチームは、共感というレンズを通して互いの仕事の話や批評をし、コンテンツストラテジストやライターは、デザイナーや開発者と協力してより良いフォームやインタラクションを作る。どこを向いても、最善の解決法は、協力することが単に励みになるだけでなくチームの構造にアクティブに組み込まれている状況から生まれるのだ、ということが分かる。あなたの組織ではまだ十分な準備ができていないとしても、あなたはその準備に貢献することができる。


こんな記事もよく読まれています





コメントを残す