デザイン思考とは？5つの段階、実例、多くのチームがつまずく理由

デザイン思考は、人間中心の反復型デザインワークフローであり、共感、定義、発想、試作、テストという5つの主要段階で問題を解決します。 チームはこれらを固定順序で進めるのではなく、ユーザーを理解し、適切な問題を捉え、仮定を検証し、解決策を確定する前に不確実性を減らすために使います。

問題は、多くのチームがデザイン思考を5段階のチェックリストとして扱っていることです。試作品のないまま調査が長引き、ワークショップで案が出ても行動せず、本当の問題が明らかになる前にAIがコンセプトを生成します。難しいのは、何を探索し、テストし、作る価値があるかを判断することです。

Virseは、調査、アイデア、試作品、AIによる探索を結び付けます。 その無限キャンバス、共有プロジェクトコンテキスト、複数のAIエージェント、チームの長期記憶によって、チームはユーザーの問題やプロジェクトの判断根拠を見失わず、探索を速められます。

デザイン思考を簡単に説明すると？

デザイン思考とは、何を作るか決める前に、人々が本当に必要としているものを知ることです。

実践的なデザイン思考は、六つの行動にまとめられます。

1. 人と状況を理解する。
2. 根本の問題を特定する。
3. 複数の解決策を探る。
4. 重要な仮定をプロトタイプやモックアップにする。
5. 実際のやり取りを通じて仮定を検証する。
6. 根拠に基づいて問題または解決策を見直す。

デザイン思考の簡単な例

大学のチームが次の依頼を受けたとします。

学食アプリをリデザインする。

解決策から入るチームは、すぐにメニュー、ナビゲーション、注文画面を作り直すかもしれません。デザイン思考のチームは、まず学生がなぜ困っているのかを調べます。

調査でわかる本当の問題は、注文そのものではないかもしれません。学生は授業の合間に学食の列に並ぶ時間があるか予測できないのです。

問いは次のものから、

学食アプリをどうリデザインすべきか？

次のように変わります。

昼食を取る時間が十分にあるか、学生が判断できるようにするには？

この捉え直しから、待ち時間の推定、受け取りシステム、混雑状況の表示、物理的なディスプレイ、あるいはまったく別の解決策が生まれます。

教訓は単純です。関係者の要望が示すのは、根本の問題ではなく提案済みの解決策であることが多く、製品デザインではその違いを見極める必要があります。

デザイン思考プロセスの5つの段階とは？

最もよく知られたモデルには、共感、定義、発想、試作、テストがあります。必ず順番に行う五つの手順より、繰り返し使える活動の形として捉えるとよいでしょう。

共感：設計する前にユーザーを理解する

共感の段階では、人々が何をし、何を必要とし、どこで困り、その理由が何かを調べます。

インタビュー、観察、文脈的調査、関係者との対話、行動の根拠などを利用できます。

本記事で検討した実務の一例では、チームは没入体験、観察、自由回答型インタビュー、優先順位付け、問題分解を組み合わせました。実務者は、先進的・一般的・極端なユーザーと関係者について、各区分およそ8〜9人が参加し、最終的に数十の製品・サービス案が生まれたと報告しています。

この人数は普遍的な調査基準ではありません。有用な原則は、さまざまな行動に直接触れるほうが、社内の仮定だけに頼るより確かな材料が得られるということです。

定義：調査を適切な問題に変える

調査は情報を生みます。定義はその情報を、チームが取り組める問題に変えます。

比較してみましょう。

解決策の表明：モバイルで行列を追跡する機能が必要だ。

問題の表明：学生は昼食の時間が十分にあるかを確実に判断する方法を必要としている。

前者はすでに答えを選んでいます。後者は解決策の可能性を開いたままにします。

良い問題設定では、機能を選ぶ前に繰り返す行動、満たされないニーズ、対立、制約、仮定を探ります。

発想：方針を確定する前に代替案を探る

発想では、一つの方向に多くを投じる前に、意図的に代替案を作ります。

有用な手法には、「どうすれば〜できるか」という問い、Crazy 8s、逆転の練習、最悪のアイデア、共同スケッチがあります。

部門横断チームは、ここで独特の難しさに直面します。エンジニアは自然にAPI、データベース、構成、費用、実装の複雑さを考えます。その専門知識は不可欠ですが、最初からすべての制約を当てはめると、可能性を早々に狭めてしまいます。

実践的な原則は次のとおりです。

まず発散し、その後に収束する。

広く探索してから、実現可能性、事業の成立性、技術的制約、責任を判断に戻します。

試作：仮定を検証可能にする

プロトタイプは実験であって、小さな完成品ではありません。

紙の画面、ワイヤーフレーム、絵コンテ、サービスの模擬体験、物理模型、自動化業務を手作業で再現したものなどが使えます。

適切な再現度は問いによって変わります。ユーザーが流れを理解するか知りたいなら、ワイヤーフレームで十分かもしれません。新しいサービスへの信頼を知りたいなら、技術を実装するよりサービスを模擬するほうが役立つ場合があります。

最良のプロトタイプは通常、現在の問いに信頼できる形で答えられる、最も低コストの試作品です。

テスト：実際の行動から学ぶ

テストは、社内の意見を観察可能な根拠に置き換えます。

チームはためらい、誤解、想定外の行動、成立しなかった仮定、提案した解決策が実際に役立つ兆候を探します。

テストの結果、定義や共感に戻ることがあります。それは失敗ではありません。

テストの目的は、チームが正しかったと証明することではなく、学ぶことです。

なぜデザイン思考は直線的な5段階のプロセスではないのか？

デザイン思考には、唯一の普遍的な順序はありません。

同じ学習の仕組みを、組織ごとに異なる構造で整理しています。

4段階・5段階・7段階の枠組みはどう対応するか

用語は異なっても、三つのモデルには共通する流れがあります。

理解 → 明確化 → 探索 → 制作 → テスト → 学習 → 反復

IxDFは主要な設計活動を、認識しやすい五つのモードに分けます。HBSは事業向けの4段階モデルに圧縮します。本記事で検討したIDEO Uの枠組みは、問題設定、着想、統合、アイデア生成、制作、テスト、伝達をより細かく分けています。

実務のチームにとっては、図の箱の数よりも学習の循環が重要です。

試作前のUX調査はどれくらい必要か？

すべてのチームに調査の終わりを教える、普遍的なインタビュー数、日数、週数はありません。

よりよい問いは次のものです。

もう一度調査するほうが、仮定を検証可能にするより多くを学べるか？

長い調査期間からわかること

実務事例の検討では、12週から18週超も調査を続けながら、ユーザーに試作品を見せていないと報告されたプロジェクトがありました。

別の実務者は、自分のプロジェクトでは4〜6週間の調査と計画でワイヤーフレームに進めることが多かったと述べています。

これらは個別事例の観察であり、普遍的な基準ではありません。行動、技術、事業、規制上の不確実性の大きさはプロジェクトによって違います。

より重要なのは、発見事項を生み続けても重要な仮定の検証を避けていると、調査の価値が失われるという傾向です。

いつ試作を始めるべきか？

実務で役立つ判断基準は次のとおりです。

アイデアを具体化するほうが、社内でさらに議論するより多くを学べるときに試作する。

基本的な行動が不明なら調査を続けます。重要な仮定を安く試せるようになったら試作を始めます。

これにより、早すぎる設計と調査による停滞の両方を避けやすくなります。

実際の組織でデザイン思考ワークショップが失敗する理由は？

見える儀式だけをまねて学習を取り除くと、ワークショップは失敗します。

よくある失敗の流れは次のとおりです。

ワークショップ → アイデア → 発表 → 担当者なし → 試作なし → 変化なし

何がデザイン思考を見せかけにするのか？

実務事例やユーザーの質問を調べる中で、デザインワークフローに次の原因が繰り返し見られました。

• 実際のユーザーの根拠がない
• 決定の責任者がいない
• 実装への道筋がない
• 試作品がない
• その後の対応がない
• ワークショップ参加そのものが成果物になる

ワークショップは、その後に起こることを変えるべきです。問題を明確にし、仮定を特定し、コンセプトに優先順位を付け、プロトタイプやモックアップを作り、責任者を決めることができます。

その後に何も変わらなければ、チームが終えたのは活動であって、デザインプロセスではありません。

実装まで進んだワークショップの事例

ある実務事例では、複数の関係者によるワークショップを4か月間、およそ月1回行い、初回から公開まで約6か月かかりました。

活動は発想にとどまらず、より広いサービスの再設計と、デザインシステムおよびコンポーネントライブラリの開発まで続きました。

実務者は米国と海外市場で公開が成功したと述べましたが、収益、コンバージョン、継続率の数値は示されていません。

E-E-A-Tの観点では、この区別が重要です。裏付けるデータなしに、報告された成功を定量的な事業効果として提示すべきではありません。

すべてのUXプロジェクトに完全なデザイン思考プロセスが必要か？

いいえ。デザイン思考は、全プロジェクトに同じ順序を強いるのではなく、不確実性に合わせるべきです。

よく理解された購入手続きを改善するチームと、新しいサービスを作るチームでは、不確実性は同じではありません。

手順の儀式ではなく学習を守る

次の問いではなく、

すべての段階を終えたか？

こう問いましょう。

どの不確実性が最も高くつく誤りにつながり、それを減らす最速で信頼できる方法は何か？

すでに確かな調査があるなら、探索を繰り返しても価値は小さいかもしれません。

問題は明確でもユーザーの行動が不確かなら、試作を優先します。

ユーザーは概念を理解していても実装が非現実的なら、実現可能性の検討を前倒しします。

デザイン思考の目的は、手順を完璧に守ることではなく、よりよく学び判断することです。

AIはデザイン思考と試作をどう変えているか？

AIは解決策の候補を作る費用を下げますが、問題設定、判断、優先順位付け、テストを不要にはしません。

AIは解決策の探索を速める

本記事で検討した実務のワークフローでは、AIがビジュアルの変案、試作、ムードボード、補助素材の制作を加速しています。

正確な生産性向上幅は、作業、ツール、流れによって大きく異なるため、個々の数値を普遍的な基準にはできません。

戦略的に大切なのは方向性です。別のビジュアル案を作ることが、より安く、より速くなっています。

生成が速くなるほど問題設定の価値が増す

チームが多くの方向性を素早く作れるとき、制作がいつも最大のボトルネックとは限りません。

難しい問いは次のようになります。

• どのユーザーの問題が重要か？
• どの仮定から検証すべきか？
• 今はどの制約が重要か？
• どの変案が意味のある代替案か？
• ユーザーは実際に何をしたか？
• どの解決策を製品やデザインシステムに取り入れるべきか？

誤ったコンセプトの変案を増やしても、価値は増えません。

AIを使う制作チームにとって、デザイン思考はますます、実験を的確に方向付けるための方法になります。

デザイン思考で最もよくある誤りは？

本記事で調べた事例と質問では、四つの誤りが繰り返し現れました。

問題を理解する前にFigmaを使い始める

Figmaは解決策を表現する助けになります。しかし、それが正しいニーズに応えるかは判断しません。

画面を早く作りすぎると、仮定が要件に変わってしまいます。

試作品を磨き込みすぎる

再現度が高いほど投資が増え、愛着も強くなりがちです。

まずは問いに答えられる最低限の再現度で始めます。

調査の成果物を学習と同一視する

ペルソナ、ジャーニーマップ、スライド、報告書は根拠を整理できますが、それ自体が成果ではありません。

調査は最終的に、判断、試作品、実験、実装のいずれかを変えるべきです。

既存のアイデアを認めるためだけにテストする

良いテストでは、チームが間違っていると発見できなければなりません。

確認のためのテストは同意を生み、不確実性を減らすテストは学びを生みます。

よくある質問

デザイン思考はUXと同じですか？

いいえ。DTはより広い問題解決のアプローチで、UXは製品、サービス、システムを使う人の体験に焦点を当てます。UXチームは調査、問題設定、試作、テストなどのDT手法をよく使いますが、UXにはインタラクション設計、情報設計、ユーザビリティ、画面の作業も含まれます。

試作前のUX調査はどのくらい必要ですか？

普遍的な期間はありません。検討した実務事例には、12週から18週超も調査して試作品がないケースから、4〜6週間でワイヤーフレーム制作に進めた経験までありました。より有効な原則は、議論や調査を続けるより、やり取りによって重要な問いに直接答えられるときに試作することです。

すべてのUXプロジェクトにDTの全5段階が必要ですか？

いいえ。既存の根拠とプロジェクトのリスクに応じて、活動を組み合わせ、繰り返し、短縮し、省略できます。目的は5段階を終えることではなく、高くつく誤りにつながる不確実性を減らすことです。

AIがあってもDTは有効ですか？

はい。ただし役割は変化しています。AIは発想、ビジュアル生成、素材制作、試作を加速できます。DTは、どの問題が重要か、どの仮定を検証すべきか、根拠を次の設計判断にどう反映するかを決めるために、引き続き役立ちます。

まとめ

デザイン思考は5段階の儀式ではなく、人間中心の学習システムとして捉えるとよいでしょう。 IxDF、HBS、本記事で検討したIDEO Uの枠組みは構造こそ違いますが、人を理解し、問題を明確にし、代替案を探り、仮定を具体化して試し、学ぶという論理を共有しています。実例は柔軟性の大切さも示します。調査はテストのないまま長引き、担当者や実装のないワークショップは失敗し、AIは解決策の生成を速めています。したがって、デザイン思考の持続的な価値は枠組みそのものではなく、適切な問題を特定し、根拠で不確実性を減らし、現実がチームの仮定と食い違えば方向を変える実践にあります。