design-thinking

デザイン思考

最初の解決策ではなく、問題に惚れ込みましょう。アイデアだけで終わらせず、最後に次に何を学ぶべきかを示します。

使用するタイミング

• 実際のユーザーニーズが明確でない、製品、サービス、UX の課題。
• 「どうすれば〜できるか」という問いの設定、ディスカバリースプリント、構築前のコンセプト検証。
• ユーザーが実際に何をしているか、何を言っているかをもとに、依頼の枠組みを捉え直す場合。

対象外：仕様が完全に確定しており、発見のプロセスが不要な場合、またはユーザー課題を設定する必要のないコードのみの保守作業。

始める前に

1. ひとつのブロックに、デザイン課題（影響を受ける人と、その状況）と合格条件（共感、定義、アイデア創出、プロトタイプ、テスト計画）を記載します。
2. まず情報を集めます。 共感の記述を書く前に、チケット、インタビューメモ、サポートスレッド、分析データ、または製品自体を確認します。ツールでは答えられないユーザー、制約、成功のシグナルについてのみ、質問は最大3つにします。
3. 簡易版。 小さな依頼の場合は、各段階を1〜2行、アイデアを3つ、プロトタイプを1つ、シグナルを2つにします。
4. 共感の段階で実際のユーザーからの情報がない場合は、定義の段階でそのことを明記し、POV の範囲を狭く保ちます。調査結果を決して捏造しないでください。

段階

1. 共感

• 対象者： 主なユーザーまたはステークホルダー。ユーザーから得た事実と [INFERRED] を区別します。
• 用事、悩み、期待： 何をしようとしているのか、何が課題なのか。
• 状況： ニーズがいつ、どこで生じるのか。

引用を捏造しないでください。言い換えるのは、ユーザーが提供した内容に限ります。

2. 定義

• インサイト： 悩みと状況を結びつける、表面的ではない緊張関係。
• POV： 「[ユーザー] は、[インサイト] のため、[動詞] する必要があります。」
• How Might We： POV を起点に、範囲を適切に定めた問いを2〜3つ作成します。

3. アイデア創出

各 HMW をプロンプトとして使い、量と多様性を重視します。各アイデアには、desirable、feasible、viable のいずれかを仮説として付け、事実として扱わないでください。ユーザーが数を指定しない場合は、通常8〜10個のアイデアを作成します。

4. プロトタイプ

紙上のフロー、ロールプレイ用の台本、ランディングページのスモークテスト、クリック可能なスケッチなど、忠実度の低い成果物を説明します。それぞれに、目的： 答えを出すための問い。忠実度： スケッチのみとインタラクティブの間のどの段階かを1行で示します。

5. テスト計画

• 学習目標： 何が分かれば、そのアイデアが間違いだと納得できますか？
• 参加者： 対象者と人数、または「未定」。
• シグナル： 失敗する可能性も示せる形で記述した、観察対象の行動や指標。
• 次の反復： 結果がまちまちだった場合に何を変えるか。

落とし穴

• 解決策を言い換えただけの POV（「ユーザーにはダッシュボードが必要」）。
• 範囲が広すぎる HMW の問い（「エクスペリエンスを向上させる」）、または狭すぎる問い（解決策が見えてしまう）。
• desirable／feasible／viable のタグを、証明済みの事実として扱うこと。
• アイデアが間違いだと示せるシグナルがないテスト計画。

実例：references/example.md。

チェックリスト

• 課題と合格条件を記載した
• 共感の段階で事実と [INFERRED] を区別した
• アイデア創出の前に POV と HMW を設定した
• アイデアに、仮説として desirable、feasible、viable のいずれかをタグ付けした
• プロトタイプに目的と忠実度の説明を含めた
• テスト計画に学習目標と反証可能なシグナルを含めた