株式会社VERSAROCが提供するUXデザインnoteマガジン。今回はUXデザインのダブルダイヤモンドプロセスにおける Define（定義）のフェーズについて解説します。プロダクトを開発する際、ユーザーの情報を収集するDiscover（探索）の後のフェーズであり、その後のアイディア出しやプロトタイプ制作に関わる本質的なニーズを定義していく大切なフェーズです。

Define（定義）フェーズがうまくいけばプロダクトの方向性をチームで共有できますし、プロセスの後半でプロダクト全体を見直す必要が出た際も重要なポイントのなるフェーズです。UXデザインのプロセスに仮説を立てて望んでいけるように、ぜひ最後までご覧ください。

Define（定義）フェーズとは

Define（定義）フェーズとは、UXデザインのダブルダイヤモンドモデルのプロセスの1つの工程です。『調査・共感して、とくべき課題を定め、アイデアを出して、作ってみて、確かめてみる』というプロセス全体の中の『解くべき課題を定める』フェーズとなります。Define（定義）フェーズでユーザーの解くべき課題を定めることで、データに基づいて作られた明確なユーザーモデル「ペルソナ」を定義します。

ペルソナについては、Discover（探索）のフェーズでユーザーインタビューを実施する前にも作りましたが、調査前の段階はあくまで仮説のユーザーでしかありませんでした。こうした仮説のペルソナをUXデザイナーはプロトペルソナと呼びます。

Discover（探索）フェーズの調査によって仮説ではない生のユーザーのデータが集まっていますから、プロトペルソナを元に、Define（定義）フェーズではデータに基づいた詳細な人物像を描けるようになります。そしてこのデータに基づいて作られたユーザーモデルこそがペルソナなのです。

プロトペルソナは数時間で制作できるのに対し、ペルソナは制作期間が長くなり、数週間を要するケースも珍しくありません。Define（定義）フェーズにてUXデザイナーがペルソナの『解くべき課題を定める』ことでその後のアイディアや試作の精度が上がるのです。

▼Discover（探索）フェーズの解説はこちら

Define（定義）では共通認識を揃える

Define（定義）の目的は集めたデータからユーザーの課題を明確にしたうえで、プロジェクトに関わるメンバー間の共通認識を揃えることです。Define（定義）の前段階であるDiscover（探索）フェーズにて、ユーザーインタビューやフィールドワークを通して顧客の声を集めているはずです。これらのデータから課題とその解決策を見出すデザインブリーフを作成します。

Define（定義）フェーズは、Discover（探索）フェーズで入手した大量の情報を分析することで意味のあるデータに変えていく作業と言い換えてもよいでしょう。データだけを集めているだけではいけません。集めたデータをビジネスの視点から見つめ、UXデザイナーが適切に解釈することで初めて意味のあるデータとなるのです。

一方で、データを解釈するときには自分だけの解釈にならないよう注意も必要です。プロダクトに関わるメンバーの意見も聞いて、他者の思考プロセスも取り入れることでユーザーの本質的なニーズを探っていきます。

ニーズを明らかにする「上位下位関係分析」

ユーザーから得た情報からより深いニーズを明らかにするDefine（定義）フェーズにて、UXデザイナーは予算やスケジュールに合わせていくつかの手法を使い分けます。代表例としてカスタマージャーニーマップや親和図法などがありますが、本記事では「上位下位関係分析」について解説します。

上位下位関係分析の特徴と手順

上位下位関係分析とは、インタビューで得た情報を階層的に整理し、全体の構造を明確にするための手法です。複雑な問題やシステムを構成する要素がツリー状にまとまっていくため視覚的に捉えやすく、チーム間で意見を交換する際に役立ちます。おおまかにいえば、次の3ステップで進めていきます。

1. インタビューから「事象」を収集

2. 「事象」をグルーピング

3. グループを「行為目標」として上位概念化

4. 「行為目標」をグルーピング

5. グループを「本質的なニーズ」として上位概念化

ユーザーインタビューにて集めた情報から「ユーザーがしたいこと」を推測して「行為目標」として仮説にし、さらにそれを抽象化して「本質的なニーズ」を探っていきます。ふせんなどを使って複数名のチームで取り組みやすく、相互に意見交換をしながらユーザーニーズを探っていけます。

上位下位関係分析のコツ

上位下位関係分析のコツはユーザーのニーズを抽象的にしすぎないことです。事象から抽象度を挙げていくと、最終的に「幸せになりたい」のような抽象度になってしまうケースがあります。ユーザーのニーズとして「幸せになりたい」のは間違いないはずですが、ビジネスのプロダクトとして「幸せにするサービス」を目指すのはあまりよい目標とは言えないでしょう。

また、最初にふせんに書くユーザーの事象は、その内容がわかる程度に書く必要があります。たとえば10代の休日の過ごし方についてインタビューをし「起きてからしばらくはTikTokを眺めている」という事象がわかった場合、ふせんに「TikTok」と単語だけ書いてしまうと分析がうまくいかない場合があります。ふせんを読むだけでチームメンバーが内容を想像できる程度には詳細を書くようにしましょう。

Define（定義）フェーズを進めるポイント

最後に、Define（定義）フェーズを進める上で、意識しておくと良いポイントを解説します。

• データを求めすぎない

• 仮説でいいから定義する

それぞれチェックしていきましょう

データを求めすぎない

Define（定義）フェーズはユーザーの情報をもとに進めますから、Discover（探索）フェーズで集めた情報の量や質が十分かどうか不安を感じるケースもあるでしょう。ここで覚えておいて欲しいのは、今ある情報でプロジェクトを推し進めていくのもUXデザイナーの腕の見せ所だということです。

Define（定義）フェーズで使われる分析手法は多数あり、それらはとても有効です。しかし実際のプロジェクトは予算も工期も限りがあるため、すべての分析手法を試すことは不可能です。予算や納期に応じて適切に手法を使いわけ、今あるデータの中でベストを尽くすようにしましょう。

また、仮に予算や時間が無限にあったとしても「完璧にデータが集まる」なんてことはあり得ません。ユーザー自身すら自覚していないニーズを探るのですから、完璧はあり得ないのです。データの質や量を求めすぎず、手元にある情報で進めていくことは大切なポイントのひとつです。

仮説でいいから定義する

ユーザーの本質的なニーズを定義する際に、それが正しいのか気になるケースもあると思います。結論として、Define（定義）の段階でそれが本当に正しいのかは知る方法がないため、仮説でいいから定義することは大事なポイントとなります。仮説が正しいかどうかはこの後のフェーズでテストしますから、まずは仮説を定義していくことが重要です。

まとめ

Define（定義）フェーズでは、ユーザーから集めた情報を整理して解釈し、ユーザーの本質的なニーズの仮説を立ててチームメンバーの共通認識にします。仮説でつくられたプロトペルナに実際の情報が加わり、より詳細なペルソナになるのです。

ここで立てた仮説を、つぎのIdeate（発想）のフェーズで磨いていきます。まずは手元にある情報でできる限り明確な仮説を定義していくと良いでしょう。