要約：ユーザー・ニーズステートメントは、問題ステートメントや観点ステートメントとも呼ばれ、解決しようとする問題について定義し、整合性をとるための強力で基本的なツールである。
デザイン思考（だけでなく、あらゆるプロダクト開発プロセス）において、可能性のある解決策を生み出すことに時間とリソースを費やす前に、解決したい問題を定義することが重要です。このアプローチは、リソースを最大限に活用し、プロトタイピング、テスト、および実装の段階での摩擦や意見の相違の可能性を低減させます。
ユーザー・ニーズステートメントは、しばしば問題ステートメントや観点ステートメントとも呼ばれ、デザイン思考の第2段階である定義段階における主要なツールであり、アイデア出しに進む前に異なる観点を調整します。どの用語（ユーザー・ニーズ、問題点、観点）を使うかは問題ではなく、組織全体で一貫性を保つことが重要です。
定義：ユーザー・ニーズ・ステートメントとは、特定のユーザーが誰であるか、そのユーザーのニーズは何か、なぜそのユーザーにとってそのニーズが重要なのかを要約するために使用される、実行可能な問題ステートメントのことです。1）問題に対する観点を凝縮し、2）デザイン思考のプロセスを通じて成功の指標を提供するために、解決策の候補を生み出す前に解決したいことを定義します。
最も重要なことは、ユーザー・ニーズ記述の目的は、デザインによって何を達成したいかであり、どのように達成するかではありません。ボタンなどのUI実装のような特定の機能から、ユーザーが解決しなければならない問題についての深い洞察へと、私たちの想定される解決策を前進させるのに役立ちます。簡単に言うと、ユーザー・ニーズは、解決策を表す名詞ではなく、動詞（目標や最終状態）としてとらえることを推奨しています。たとえば、ユーザーはドロップダウン（名詞）を必要としているのではなく、選択可能な選択肢を確認し、その中から1つを選ぶ（動詞）必要があります。ダッシュボード（名詞）は必要なく、さまざまな情報を一箇所で消化する（動詞）必要があります。 名詞は、ユーザーのニーズに対する解決策になり得ますが、唯一の解決策ではありません。これらの名詞に焦点を当てると、最適とは言えないデザインで終わってしまう危険性があるのです。アイディエーションの全目的はアイデアを探索することなので、早々に解決策を選択して自分を閉じ込めてしまわないようにしましょう。
フォーマット：3つの要素
従来のニーズ・ステートメントは3つの要素で構成されています。1) ユーザー、2) ニーズ、3) ゴール。これらは、[ユーザー] は[ゴールを達成する]ために[ニーズ]を行う必要がある、 というパターンで組み合わされます。例えば、
「2児の母でマルチタスクなアリーダ」は、「本当に大切なことにもっと時間を割く」ために、「自分の居心地の良い場所を離れずに、素早く自信を持って選択肢を比較すること」を必要としています。
このユーザーは、あなたが調査した特定のペルソナまたは実際のエンドユーザー・セグメントに対応する必要があります。特に、大規模なチームや調査から離れたステークホルダーがニーズステートメントを使用する場合は、誰がユーザーであるかを思い出させるための短いキャッチフレーズを含めると便利です。
- アリーダ：マルチタスクで技術に精通した2児の母。
- キャロル・アン：冒険好きな研究者。
- 都会で暮らすYouTuber：サム。
ニーズは現実的であるべきで、またユーザーのものであるべきで、チームが作り上げたものであってはならないし、ソリューションとして言い表すべきものでもありません。機能、インターフェース部品、特定の技術から離れることが重要です。例えば、以下のような目標が考えられます。
- 快適な環境を離れることなく、素早く自信を持って選択肢を比較すること。
- 家庭とのバランスを保ちながら、他の人と出会い、交流すること。
- 重要な決断をする際に、他者から肯定的な意見を得ること。
ユーザーは、自分が何を必要としているのかを、口ではそう言っていても、必ずしも理解しているとは限らないということを心に留めておいてください。ヘンリー・フォードの有名な言葉に、「何が欲しいかと尋ねたら、馬が速くなることだと答えただろう」というのがあります。ユーザーの真のニーズを理解することが、あなたの仕事です。
インサイト（目標）とは、そのニーズを満たすための結果です。それは共感に根ざしたものであるべきです。このソリューションによって、ユーザーは何を達成できるのか？ 例えば、ユーザーの希望、恐れ、動機などを考えてみましょう。
- 本当に大切なことにもっと時間を使いたい
- 新しい友人を夕食に招待することに自信を持ちたい
- いつも後回しにしていた生涯の夢を実現したい
メリット
ユーザー・ニーズステートメントを作成する認識と協力のプロセス、そして完成したステートメントは、あなたのチームと組織にとって重要な利益をもたらします。
ユーザーとニーズを把握する
ニーズ・ステートメントは、ユーザーとそのニーズに関する知識を1つの文章に凝縮します。特に、解決策を探す前に、リサーチインサイト（アンケートの回答、ユーザーインタビューの記録、共感マップ）を凝縮するのに役立ちます - したがって、明快さと時間配分を高めます。
簡潔な目標に沿ったチームの調整
ユーザー・ニーズ・ステートメントは、ユーザーとそのニーズを複数のチームメンバーやステークホルダーに伝えるための、簡潔で明確な方法です。一度作成すれば、プロジェクト全体を通して、あなたとあなたのチームが何を解決しようとしているのか、その指針として機能するはずです。
成功のためのベンチマークと測定基準を明確にする
ユーザー・ニーズは、適切に作成されれば、アイデア出し、プロトタイピング、テストが始まる前に、成功のための指標を提供するという利点もあります。インサイトやゴールを使って、「これが達成できたかどうか、どうやって知ることができるか？そして、ニーズ・ステートメントを作成する際に、それに対応する成功のための指標を設定します。このようなアプローチは、将来的な摩擦を減らし、チームや組織にとっての明確な基準を設定することができます。
プロセス
1. スコープを設定する
ユーザーのニーズは、さまざまなスコープに適用することができます。1つのプロジェクトに複数のニーズ・ステートメントが存在する可能性があります。包括的なステートメントと、そのユーザータイプに対するより小さな目標を明確にする下位のニーズ・ステートメントがあります。現在のプロジェクトのニーズに基づいて、ニーズ分析の範囲を決めるとよいでしょう。
次のような目的がある場合は、「包括的」または「親」（広範なスコープ）のニーズ・ステートメントを作成することから始めます。
- 長期的なビジョンやロードマップのための整合性を確立すること
- プロダクトコンセプトの初期段階における問題ステートメントを定義すること
「親」ニーズステートメントは、プロジェクトの各コンポーネントを統括する広範な目標を持つ可能性があります。例えば、上記のニーズ・ステートメントは、親ゴールとして考えることができます。
「マルチタスクでテクノロジーに精通した2児の母であるアリダ」は、「本当に大切なことにもっと時間を割く」ために、「快適な環境を離れることなく、素早く自信を持って選択肢を比較する」ことを必要としているのです。
逆に、次のような目標がある場合は、「子供」（小さな範囲）のニーズ・ステートメントから始めると効果的です。
- ニーズ・ステートメントを使いこなし、流暢に話すことができるようになること
- 個人のプラクティショナーまたはUXチームとして成功するための個人的なベンチマークを作成すること
- より大きなプロダクトまたはサービス内のユーザー・ニーズについて、チームを調整すること
- 1週間のスプリントの目標を設定すること
「子」ニーズステートメントには、具体的なニーズと、1～2回のリリースで満足できるゴールがあります。
「マルチタスクでテクノロジーに精通した2児の母であるアリダ」は、家族のスケジュールを前もって調整し、さらなるストレスを防ぐために、「インストール予約をする」必要があります。
2. 定性調査を実施する（または既存のものを収集する ）
ユーザーとそのニーズを理解するために必要なリサーチを収集します。ユーザーインタビュー、フィールド調査、日記調査、定性調査などの定性的情報は、ユーザーに関する深い洞察を得るのに役立ちます。また、共感マップ、ジャーニーマップ、サービス設計図など、あなたのチームがすでに作成したマップにも目を向けてください。
3. 生成し、組み合わせる
リサーチ結果をもとに、ニーズ・ステートメントの3つの変数（キャッチフレーズを持つユーザー、ニーズ、インサイト）の候補を生成します。最初から完璧なステートメントを作ろうとせず、それぞれの変数を単独で考え、次にミックス＆マッチを始めるのです。ユーザーの真のニーズを表すステートメントができあがるまで、さまざまな組み合わせで考えてみましょう。
初めての人は、研究成果以外のものをニーズ・ステートメントに含めることに不安を感じることがあります。しかし、ユーザーが直接的に何を必要としているのか、なぜ必要としているのかを語るとは限らないことを忘れてはなりません。そのため、私たちユーザー・エクスペリエンスの専門家は、リサーチと専門知識を組み合わせて、インサイトを導き出すことが重要です。 AirbnbのRebecca Sinclairは、「あなたはデザイナーである」と言います。あなたの仕事は、深く共感できる聞き手となり、彼らの問題を解決する方法を想像することです。お客さまが想像していたものよりも、もっといいものをつくる責任がある。お客さまはインスピレーションですが、あなたはクリエイターなのです」。これを実践するためには、「なぜ」と自問し続けることです。
- ユーザーは何に関心があるのか？
- ユーザーにとって、なぜそれが重要なのか？
- ユーザーの行動の原動力は何なのか？
- ユーザーは何を得ることができるのか？
4. ステートメントを批評する
作業用のステートメントができたら、それに対する批評と反復を始めます。言葉を変えたり、異なるインプットを組み合わせたり、ミックス＆マッチしてください。自分自身に質問を投げかけてみてください。
- ユーザーのニーズを名詞としてではなく、動詞として考えていますか？
- このニーズ・ステートメントがあれば、あなたはアイデアを思いつくことができますか？
- このニーズ・ステートメントは、そのニーズを解決することがユーザーの人生において何を意味するのか、そのニュアンスを捉えていますか？
5. 測定方法を追加する
最終的なニーズ・ステートメントが決まったら、その成功の度合いをどのように測定するかを明確にしましょう。もし、そのニーズを満たすことができたとしたら、どのようにしてそれを知ることができるでしょうか？一般的な測定方法としては、以下のようなものがあります。
- 顧客満足度
- 返品数
- 契約更新や継続利用
- 定期購入や定期購入の回数
- プロダクトを推薦する可能性
ユーザー・ニーズ・ステートメントの実践
ユーザー・ニーズステートメントは、プロダクト開発サイクル全体を通じて活用することで、その効果を最大限に発揮します。以下は、ユーザー・ニーズステートメントを作成し、参照することが有益である場合、およびその理由についての例です。
例1: リサーチ
- どんな時に？ユーザーインタビューから得られた重要な発見を分析し、共有する時に。
- どのように？個々のリサーチ分析が完了したら、自分自身でユーザー・ニーズステートメントを作成します。このユーザー・ニーズを他の研究者が作成したものと比較します。インタビューの洞察を最も客観的に表現するユーザー・ニーズ声明ができるまで、さまざまなニーズ声明を組み合わせ、リミックスします。
- どうして？： 調査から得られた本質的な情報を、消化、共有、配布が容易な単一の実用的なステートメントに凝縮するため。
ヒント：ユーザーセグメント間の違いを明確にするために、異なるユーザーのニーズステートメントを直接比較します。
例2：プロジェクトキックオフ
- どんな時に？：新しいリリースサイクルまたはスプリントの開始に際して目標を特定するとき。
- どのように？：1時間のワークショップで、ユーザー・ニーズ・ステートメントを作成します。参加者に、特定のユーザーに対するニーズと洞察を生み出してもらいます。1つの声明に合意するまで、混ぜたり、合わせたり、書き直したりするように促す。
- どうして？：チームメンバーが団結できるように、明確なステートメントを作成し、複数部門のチーム間で整合性と優先順位を強制します。
ヒント: 各チームメンバーに声明文に署名またはイニシャルを入れてもらい、リリース目標に賛同し連携していることを示す。
例3: 振り返り
- どんな時に？：追加された機能または能力が実装された後に、その成功をレビューするとき。
- どのように？： プロジェクトの開始時に作成されたユーザー・ニーズ声明に戻ることによって、回顧を開始します。参加者に、声明に対する成功の認識を順位付けしてもらう。
- どうして？：初の目的に対して、実装されたものの効果を比較するため（ユーザー・ニーズ記述には、クリック率の向上、再購入の増加など、成功の意味を明確に定義する必要があります）。
ヒント 成功に関する自己評価と、新機能のアナリティクスおよびユーザーデータを比較します。関係性やテーマを特定し、その洞察を次のリリースに役立てます。
ユーザー・ニーズ・ステートメントと開発タスク、ストーリー、エピックとの比較
一見すると、ユーザー・ニーズ・ステートメントは、プロダクト開発でよく使われる他の構造と似ているように見えます。開発タスク、ユーザーストーリー、エピックは、しばしば同じ形式をとります。ユーザーには "何かをする方法 "が必要です。
この違いをより明確にするために、ニーズ・ステートメントと開発ステートメントを比較してみましょう。
- ニーズ・ステートメント：[マルチタスクでテクノロジーに精通した2児の母であるAliedaは、「本当に重要なことにもっと時間を割く」ために、「快適な環境を離れることなく、素早く自信を持って選択肢を比較する」必要があります。
- 開発ステートメント 」ユーザーは、異なる価格を見るために比較表を必要としています。
ニーズステートメントでは、特定のユーザー、そのユーザーが必要とすること、そしてなぜアリーダがそのニーズを持つのかについて、明確で共感できる洞察が得られます。開発ステートメントでは、一般的なユーザーとソリューション（比較表）を提示し、ソリューションが何をサポートするかを説明するインサイトがあり、調査に基づくものではありません。
どちらにもその時期と場所があります。デザイン思考プロセスの初期段階であれば、アイデア出しやプロトタイピングを通して柱となる質の高いニーズステートメントを生成するよう、自分を追い込むべきです。開発ステートメントは、何を解決したいのかがわかった時点で、実装のためのメカニズムとして使用します。
もしあなたが現在、ユーザー・ニーズ記述に似たエピック、ストーリー、タスクを扱っているなら、それらに立ち返り、「ユーザーをもっと具体的にできないか」と自分自身に問いかけてみてください。名詞を動詞に変えたら、そのニーズはどのように変わるでしょうか？より深い洞察は何でしょうか？
まとめ
ユーザー・ニーズ・ステートメントは、その名が示すように、私たちが解決しようとするエンドユーザーの問題と、それがなぜ解決する価値があるのかを明確にするものです。ユーザー・ニーズを名詞として考えるのをやめ、動詞として考え始めるためのツールなのです。また、ニーズ・ステートメントを共同作業で正しく作成すれば、チームや組織として何を達成したいかを示す、唯一の真実の情報源となります。
