分析
要点
この段階は、ユーザーモデリングを行い、次の「製作」の段階のためのアウトプットを作成する段階です。
エンジニアの仕事で言うと、まさにモデリングです。感覚で言うと、 UML でモデリングする感覚に近いです。ただ、 UXD のモデリングは UML よりも抽象化の作業がとても重要で難しいです。
ユーザーのモデリングはあくまでもインタビューログから抜き出された、行動と意図のファクトベースで行います。しかし、 UXD の抽象化では、不確定要素の抽象化を多く繰り返します。その抽象化を繰り返す中で、ファクトじゃない想像が介入する余地が多分にあり、結果として正確なモデリングができなくなる可能性があります。
例えば、オブジェクト指向が分かる人はもう分かっていると思いますが、各行動と意図のペアのそれぞれが、あるクラスのインスタンスです。何のクラスのインスタンスかは分からないので、本質的ニーズを基準に似ているインスタンス同士でクラスを作ります。そして、クラス同士で、また更にスーパークラスを作ります。
つまり、形や定義のないインスタンスからクラスを考えて、名前をつけて、そのスーパークラスを考えて、名前をつけるを繰り返します。これは、難しいのが分かってもらえると思います。
また、終わりがないので、のめり込んで作り込みすぎてしまうということもあります。そういうことを防ぐために、時間で区切るのは非常に効果的な方法です。時間、スプリントを決めてやるのは効果的な方法だと思います。
ここは、抽象化の作業が多く正解もないので、モヤモヤが多い段階です。そんな時は「わかった時にまた戻ってくれば良いかー。」って、考えが大事だと思います。この段階は、ユーザーと向き合う段階です。誰もここで一発で正解を出せと言っている訳ではないのです。ユーザーの本質的ニーズを真摯に考えられれば充分だと思います。
この章の残りは下記の点を詳細に書きます。
- アウトプットの種類
- ユーザーモデリング
- 価値マップ
- ペルソナ
- CJM（AS_IS）
アウトプットの種類
ユーザーモデリングの後に、モデリング結果をどのレイヤー（層）で切り出すかでアウトプットが異なります。
主に「価値層」、「属性層」、「行為層」と呼ばれるレイヤーで切り出すのが基本的です。それぞれのレイヤーのざっくりとした説明を下記に示します。
- 価値層
- 「〜したい」という本質的ニーズを切り出したレイヤー
- 属性層
- 具体的な人物の特徴を切り出したレイヤー
- 行為層
- 時間軸をもち行動の変遷を切り出したレイヤー
そして、それぞれのレイヤーのアウトプットが名称の違いがあるかもしれませんが下記になります。
- 価値層 -> 価値マップ
- 属性層 -> ペルソナ
- 行為層 -> CJM（カスタマージャーニーマップ）
基本的にアウトプットの順番は、 「価値マップ」 -> 「ペルソナ」 -> 「CJM」 となります。なぜなら、ペルソナの UX ゴールを設定する際に価値マップを利用し、 CJM の心の声や感情曲線を作る時にペルソナを使うからです。
それぞれの完成度や作成の仕方は、会社やチームによって差があると思いますが作成手順の流れは、おそらくこの流れに準拠していると思います。各アウトプットがそれの前のアウトプットに依存している設計になっています。
この感覚は、エンジニアのモジュールのレイヤー分けとほとんど同じです。
プロセス自体もレイヤーに分けられていますが、ユーザーモデリングもレイヤー分けしてお互いの依存度を最小限にしています。どこかバグが出た時に、どこを修正すれば良いのか検討が付きやすいので、このレイヤーに分ける作業はエンジニアと相性が良いと思います。
また、出て来るアウトプット自体は UML ととても似ています。（僕がそう思ってるだけかもしれませんが。笑）
- 価値マップ -> UML のクラス図
- ペルソナ -> UML のユースケース図のアクターとシナリオ
- CJM -> UML のアクティビティ図
この点を見ても、エンジニアにも馴染みやすいんじゃないかなと思います。
より詳しくレイヤーとアウトプットについて書いた記事があるので、もっと詳しく知りたい人はこちらを読んで下さい。
## ユーザーモデリング
あまり手法の説明はするつもり無いのですが、このユーザーモデリングは UXD の重要な要素なので汎用性の高い手法を１つ紹介します。
ユーザーモデリングをするには色々手法はありますが、 KJ 法を紹介します。 KJ 法はユーザーの行動と意図から徐々に抽象化していく手法です。
抽象化に対象の慣れが必要ですが、徐々に抽象化をしていくのでファクトベースでない個人の想像が入ることを防ぐことができます。この点が、 KJ 方の大きな利点であり、初心者でもやりやすい点だと思います。
はじめに KJ 法を実際にやる前に注意しておかなければならないことがあるます。それは、メンバーや実施のタイミングなどで、大きくモデリング結果が変わることです。
メンバーのユーザーに対する理解度が高ければ高いほど、本質的ニーズに近いモデリング結果が得られます。また、メンバーが抽象度のコントロールに慣れていればいるほど、具体性の高いモデリング結果が得られます。
本質的ニーズに近く、具体性が高いというのはユーザーモデリングにおいてとても重要です。
この２軸がなければ、ただの「手段」の提供になってしまったり、「世界をより良くしたい」みたいな分析しなくても分かるような結果ができてしまいます。
しかし、 UXD はリーン開発と同じで学習して行く開発手法です。
最初のうちは今のチームの最適を作ることを心がけると良いと思います。あとは、抽象化の作業の段階でアイディア出しと勘違いする場合があります。アイディアを出したくなる気持ちはわかりますが、今はユーザーに向き合うことに集中して下さい。
それでは、具体的な KJ 方のやり方を示します。
カード化
インタビュー（調査）で得られたユーザーの声をカードに落とし込んでいきます。
まずは、インタビューのログを読み込みます。その際に、ユーザーの行動とその行動の意図に下線を引きます。また、意見やアイディアも意図と一緒に下線を引きます。次に、下線を引いた行動を意図と一緒にカードに書き出す。その時にアイディアは別のカードに分けておきます。インタビュー相手ごとにポストイットの色を分けると後でログを見返す時に分かりやすくなります。
統合化
抽象度をコントロールしながら、複数カードを統合していきます。そして、そのグループに名前を付けていきます。
まずは、初めはなんでも良いので基準となるカードを２つ距離を置いて模造紙に貼り付けます。
そこに感覚的似ていると思うカードは近くに貼り、似ていないと思うカードは遠くに貼ります。この「感覚的」って言うのが難しいです。「なるべく言語化をしないでチームがなんとなく理解できる感じ」が「感覚的」だと思って下さい。早い段階からグルーピングを言語化しすぎると、その先入観やバイアスのせいで価値探索の発想が限定的になります。モヤモヤすると思いますが、それが正しい状態です。徐々に抽象化していくと、この近い・遠いの理由が何だったのか気づくようになります。ここで、カードの等距離な配置はなるべく避けて下さい。カード間の関係において全く同じになることはないので、ガンガン感覚的に何処かに寄せて下さい。
ただ、明らかに間違ってるのは、カードに書いてある単語や行動だけに引っ張られて近くなっている場合です。ユーザーの意図を意識して似ている、または似ていないを決める必要があります。また、時系列のフレームワークを使って整理しようとするのも間違いです。時間の経過を伴わない体験もあるはずです。安易に分かりやすいフレームワークで整理しようとしてはいけません。
カードを寄せていくのと、俯瞰してみるのを繰り返して下さい。
すると、徐々に４〜５枚ぐらいの塊が見えてきます。４〜５枚ぐらいがちょうどよい抽象化レベルだと思ってくだい。しかし、やっていくとポストイットが１色だけのグループができてしまうと思いますが、これはできるだけ避けて下さい。この後に、ペルソナを作る段階で１色だけのグループは個人の行動なので、典型的な行動とならずペルソナ作りが難しくなるか、間違う可能性があります。
カードのグループができたら、それをまとめたグループに名前を付けます。
その際に、抽象度を常に意識して下さい。グループの単位で最大限の具体性を持つ名前を心がけて下さい。グループに名前を付ける時に、ある程度、解釈が入ります。この「解釈」は「想像」とは違うことも気をつけて下さい。あくまで、カードに書いてあることから考えることが「解釈」です。
ここで分析者たちの「想像」が入った瞬間に、そこからはユーザーの本質的ニーズもペルソナも行動も出てきません。特に初心者はいきなり正解は出ないので何回も名前を付けて、チームの納得いくものを見つけると良いと思います。
また、価値マップのニーズの書き出しの前までは、特定の定性表は現避けた方が良いです。
例えば、「より良く」や「効率的」とか「業務」などの、どうとでも取れるような表現を避けて下さい。何度も言っていますが、抽象化と言ってもある程度の具体性は必要なのです。どうしても定性表現が出るのはグループがまだ大き過ぎる可能性があります。具体性を保てる最小単位でグループを小さくまとめることを意識して下さい。
ここまでできるとユーザーモデリングは完成です。
しかし、正直、ここがプロセスの中で一番難しいです。「感覚」、「なんとなく」を多く含んだまま進むので、エンジニアなら「早く何なのかはっきりさせたい！」と思ってしまうと思います。僕はそうでした。
しかし、ここは本当に「なんとなく」で良いです。深く考えても分かりません。とりあえず、ちゃんと考えてプロセスを前に進めることが重要です。後のプロセスで、「こういうことだったのか！」と気づく時が来ます。今分からないことは、プロセスを通して学んだ後に分かる時が来ます。その時まで、「モヤモヤ」覚えていることが大切だと思います。
価値マップ
統合化されたユーザーモデリングの結果を価値層で切り出して、価値マップを作っていきます。
価値マップは、この後に、ペルソナや CJM を作る時にどの価値に着目してサービスを作っていくか検討する時に使います。
多くの関連が集中している価値に着目してサービスを作ったり、関連している２~３個の価値をまとめて１つの価値にしてしまいサービスを作ったりします。
価値マップはユーザーモデリングの結果を、次のステップで作成します。
価値導出
ユーザーモデリングで出てきたグループに対して「〜したい」というニーズを探し出します。
この段階で、インタビューのログからカード化の時に作っておいた、インタビュー相手のアイディアを「〜したい」で書いて追加します。しかし、インタビュー相手のアイディアの真偽はよく判断する必要があります。インタビューの誘導によりその場しのぎで適当なアイディアを言う可能性もあるからです。「ユーザーの意見だから」と盲目に追加することは必ずしも正解ではないのです。
また、この段階でニーズが、グループの名前の言い換えになるのは抽象度のコントロールが上手くできてないです。
グループの名前がある程度の具体性を持っていれば、グループ名の言い換え表現ではなく、「それってつまりこういうことだよね」とニーズが出てきます。
更に、ニーズが抽象的すぎるのも間違っている可能性があります。
「安心・安全」や「便利」みたいな言葉出てきがちです。これは、分析しなくてもわかってる価値の典型例です。更に、一企業では手に負えないニーズである可能性が高いです。できるだけ、抽象度は抑えつつニーズを導出しましょう。
図解化
統合化されたグループ間の関係性を図示していきます。下記のような種類で関係性を考えるとやりやすいです。
基本的に似ているグループは近くにあるはずなので、近くにあるグループ同士の関連を考察していくことになります。
グループ間の関係性を考察している時に、グループとグループの間にニーズがあれば追加します。完成形は下のキャプチャーのようになります。
これは、見て分かる通りクラス図や ER 図書いてる時と感覚が近いです。
お互いの関係性を示していくと、関連度が集中しているニーズが見つかったりします。そのおかげで、提供する価値の大きさやインパクトが可視化されます。
ペルソナ
統合化されたユーザーモデリングの結果を属性層で切り出して、ペルソナを作っていきます。
僕は、基本的にサービスは、「誰でも使えるデザイン」を目指のではなく、「誰かのためのデザイン」を目指すことを前提に作られるべきだと思っています。その「誰か」をペルソナにするというわけです。
注意が必要なのは、ペルソナはサービスを使ってくれる「典型的」なユーザーであるべきです。
ペルソナを作るにあたって、エンジニアが考えがちなのが、アクセスログで見つかる「平均的」なユーザーです。「平均的」と「典型的」は大きく違います。
アクセスログで大部分を占めているユーザーは、確かに大事なセグメントです。しかし、求めている価値はユーザーによって様々な可能性が高いです。そんな中で、ログから見えるユーザーから施策を考えて実施しても、一点の数値は伸びるかもせれませんが、どこか別の数値が下がる現象が起こるかもしれません。
サービス内で辻褄が合った施策をしないと、こういうことが起こります。僕も１年ほど前にログだけを見て、サービス改善していた時に、同じことが起こりました。
そんな時にペルソナのような「典型的」なニーズをもった、「典型的」なユーザーは役立つと思います。
また、場合によっては、複数ペルソナを作ったり、後述するペルソナ作成のステップを簡略化してやる場合もあります。
自分たちの状況に合わせたペルソナ作りを意識することが重要です。
ペルソナはユーザーモデリングの結果を、次のステップで作成します。
属性の抽出
ユーザー分析からユーザーの行動を一覧に並べてみます。それが、今回のペルソナがする行動のリストとなるわけです。
その行動のリストに対してその人としての属性を出してみます。例えば、「タスクを忘れないようにポストイットに書き出している」のような行動があった場合、そこから読み取れるペルソナの属性は「急にタスクを頼まれて忙しい」、「忘れっぽい」、「几帳面」などが読み取れるす。
ここで、注意が必要なのは、この属性の抽出は、とても属人的になりやすく主観が入りやすいです。なので、属性の抽出はチームでやってより客観的な抽出ができるようにお互いに干渉しあった方がより客観的な属性が抽出できます。
また、1つのインタビュー相手からできた行動はペルソナの属性というより、ただのインタビュー相手の属性です。なので、属性の抽出が特定のインタビュー相手に偏らないように注意が必要です。
ストーリーにする
抽出された属性を使って、ペルソナのコンテキストとブランド・プレファレンスをストーリーにしていきます。
コンテキストとは、ペルソナの置かれている状況です。
ペルソナが、調査の目的に対してどんな状況にいるかをストーリーにしていきます。
また、ブランド・プレファレンスは、趣味・嗜好です。
インタビューから調査の目的とは違うが、ペルソナの人となりが分かるようにストーリーにしていきます。
この際に、コンテキストとブランド・プレファレンスを箇条書きで書くこともありますが、文章を使ってストーリーにしたほうが良いです。なぜなら、ストーリーにするとただの箇条書きと比べてペルソナが想像し易いです。そのことにより、「こんな人いないよ」みたいなことを防げます。また、カスタマージャーニーマップでの共感の時に役立ちます。
ここでストーリーにした時に、想像が書き込まれてないかに気をつける必要があります。
あくまでもインタビューからのファクトベースでペルソナを作るべきです。ストーリーにするのにのめり込んでしまい、想像が付け足せれてしまっては、せっかくの分析結果がもったいなくなってしまいます。それぞれの単語・文の根拠がどこにあるかを意識して作ると良いです。
また、何度も言っていますが、ある程度の具体性は重要です。あやふやな表現は、あやふやな UX につながるので、できるだけ詳細に作ることを心がけてください。
UX ゴールを設定する
このペルソナが達成したい UX ゴール（体験価値）を決めます。
この時に、価値マップを使います。
このペルソナが置かれているコンテキストと価値マップを照らし合わせると、「今回の目的で、このペルソナならこの価値と相性が良かも」と思う価値が1〜3個ぐらい出てくると思います。
1個の時は問題なく、そのまま UX ゴールすれば良いですが、複数の時はそれらを1段階抽象化した価値を UX ゴールに設定します。
プロフィールを決める
最後に、このペルソナにプロフィールを付与します。
プロフィール情報を追加して、人としての真実味を高めます。プロフィールとして名前や年齢、性別を入れるのは多くの場合共通ですが、その他の情報は盛り込みすぎないように気をつけてください。コンテキストにつながる項目を入れるだけで十分です。
プロフィール項目が決まったら、その項目ごとにインタビュー相手の共通点や平均値、中央値を入れてプロフィールを作っていきます。
年齢、趣味みたいなものはしょうがないので、平均値や中央値使っても問題ありません。ただ、予めターゲットが決まっている場合は、その値を使います。
また、ペルソナに真実味をもたせるのが目的なのでありえない名前は辞めたほうが良いです。更に、有名人の名前をつけるとペルソナイメージが有名人に引っ張られてしまうので、避けるべきです。
出来上がりのサンプルキャプチャー貼っておきます。
CJM(AS_IS)
統合化されたユーザーモデリングの結果を行為層で切り出して、 CJM を作っていきます。
CJM はユーザーモデリングの結果を時間軸にそって並べて、ユーザーの行動と心の変遷を可視化するツールです。
重要なのは、ユーザーの一連の行動と心の移り変わりを見て、問題点や改善点を見つけることです。ここで、見つけた課題が次のプロセスの重要な要素になります。
また、調査に基づく AS_IS （現在）の CJM があり、そこから問題点を発見し TO_BE （理想）の CJM を設計していくという段階を踏みます。
なので、AS_IS と TO_BE の CJM をごっちゃにしないように気をつける必要があります。ここでは、 AS_IS のユーザーの行動に集中して下さい。
CJM はユーザーモデリングの強力な手法の１つです。この段階のアウトプットの中では、 CJM が一番重要だと言っても良いと思います。
しかし、注意が必要です。 CJM では1つのシナリオにフォーカスしてしまうので、分岐する様々な課題を見逃してしまうということがあります。複数のペルソナや利用状況がある時は、複数のシーンで CJM を作ることをおすすめします。
CJM はユーザーモデリングの結果を、次のステップで作成します。
フォーカスするジャーニーを決める
価値マップで UX ゴールの価値の中にある行動を基準にします。
その際、時間軸が統一できる行動にしぼる必要があります。時間軸が異なることによって、 CJM が複数になる可能性もあります。
例えば、複数の UX ゴールの価値の中に行動が、ある行動は1日単位でペルソナが行動する時間軸だが、別の行動は1時間単位のような場合もあります。この場合は、2つの CJM を作るなどして、時間の粒度を揃えることを意識する必要があります。
ペルソナの行動を並べる
フォーカスするジャーニーの範囲にあるユーザーモデリングの行動を時系列に並べます。
その際に、行動の抽象度が同じになるように意識して下さい。ものによっては行動の抽象度が高い場合があり、その時はユーザーモデリングのグループを小さくして、より小さい単位の行動を抽出します。
漠然と「行動」と言っても、粒度の単位で下記の３つに分けられます。
- 行動詳細
- ユーザーモデリングのカードに書いてあるそのまま
- 意図を伴い詳細が記述されている行動のこと
- 行動
- 「行動詳細」の行動の部分
- フェーズ
- 「行動」について、大きくまとめて、何をしているのか区切りをつける
- マーケティング用語の AISAS みたいな分類はこれにあたる
粒度で言うと、 「フェーズ」 > 「行動」 > 「行動詳細」 の順番です。「フェーズ」が一番大きく、「行動詳細」が一番小さいです。
また、「行動」とは、「行動詳細」の行動の部分を抜き出した部分です。
「行動詳細」は意図も含まれているが、「行動」は意図の部分がなくなることになります。その際に、意図は違うがほとんど同じ「行動」になるある可能性があります。その時はまとめてしまって良いです。つまり、カードの数で言うと、「行動」は「行動詳細」と同じか少ない枚数になるはずです。これをやることで、ペルソナが大きな流れとして、どんな行動をしているかをわかりやすくすることができます。
最後に、「フェーズ」とは、大きくまとめて、何をしているのか区切りをつける役割があります。
マーケティング用語の AISAS みたいなものです。しかし、 AISAS は「注意 関心 検索 購買 情報共有」であるが、ペルソナによっては「準備 食べる お風呂はいる 寝る」みたいなモデルになる可能性もあります。マーケティングをやっている人に CJM が馴染みあるのはマーケティングの考え方と、ここの段階がよく似ているからと言われています。しかし、 UXD ではボトムアップでペルソナのためのモデルを作るのに対して、マーケティングは AISAS などの型をトップダウンで使うところに大きな違いがあります。
タッチポイント出し
行動に対して、どんな接点があるかを書き出します。
ここには、アプリや雑誌、チラシなどが含まれます。また、ペルソナが行動するにあたって関与する物・人は全部書き表します。しかし、自然な流れである必要があるので、あまりに特異なタッチポイントは避けるべきです。特異なタッチポイントであるかは、ユーザーモデリングの際の、グループに含まれるインタビュー相手全員に共通するかどうかで判断すると良いです。
また、ここではイラストを使うと良いです。 CJM は文字ばかりでビジュアル化された思考が少ないです。ここでイラストがあるとペルソナの行動がビジュアル化されて、チーム内のイメージ共有が良くなると思います。（ここはすごい主観です。）
ペルソナの心の中を並べる
フォーカスするジャーニーの範囲にあるペルソナの心の中を時系列に並べ、感情の変化を可視化します。
これはペルソナの心の声を想像するしかないです。（すみません、論理的でなくて。。。）
しかし、なるべく違和感のない感情曲線にするために、各行動詳細に対して、ペルソナの心の声を考えて、感情曲線の1点を決めるようにします。
この段階は想像がメインで、ペルソナがしっかりできていないと、かなりアウトプットとしては微妙なものができます。
なので、この感情曲線のメンテナンスはプロセスを繰り返す中で頻繁に行われます。自分の仮説が違った時は、「この感情曲線が自分の思っていたのと違ったんだ」となることが、僕の経験上多いです。
また、ペルソナの感情の流れが可視化される分、ペルソナの課題が見つけやすくなります。上手にできると、課題発見の強力なツールになります。
間違っても良いんで、とりあえず感情曲線書いてみて、どんどん修正していくスタンスの方が改善のサイクルが早いと思います。
サンプルのキャプチャー貼っておきます。
あわせて読みたい
- エンジニアによるエンジニアのための UX デザイン開発実践ガイド 導入編
- エンジニアによるエンジニアのための UX デザイン開発実践ガイド 調査編
- エンジニアによるエンジニアのための UX デザイン開発実践ガイド 分析編
- エンジニアによるエンジニアのための UX デザイン開発実践ガイド 製作編
- エンジニアによるエンジニアのための UX デザイン開発実践ガイド 検証編
