product-taste-intuition

プロダクトのセンスと直感

対象範囲

対象

• 意図的な体験、観察、批評を通じたプロダクトのセンス（「良い」とはどのようなものか）の習得
• 直感を仮説を生み出すものとして活用すること（「なんとなく」を検証可能な仮説に変える）
• 繰り返し実践できる練習サイクルの構築（体験時間 → 分析 → 検証 → センスのルールを更新）

使用する場面

• 「プロダクトのセンス／プロダクト感覚を磨くのを手伝ってください。」
• 「自社のプロダクトカテゴリーで『優れたオンボーディング』がどのようなものかを基準化してください。」
• 「このフローに関する直感を、検証可能な仮説に変えてください。」
• 「優れたプロダクトを体系的に調査し、パターンを抽出する方法を作ってください。」

使用しない場面

• 何を作るかを決める必要がある場合（problem-definition、prioritizing-roadmap、またはdefining-product-visionを使用してください）。
• まずユーザーの根拠が必要な場合（conducting-user-interviewsまたはusability-testingを使用してください）。
• 美的観点のみの批評を求めている場合（ここで扱うのはプロダクト体験です。価値、UX、明瞭さ、信頼、速度であり、ビジュアルだけではありません）。
• 対象ユーザー、ユースケース、または改善したい「センスの領域」を挙げられない場合（まず範囲を絞ります）。

入力

最低限必要な情報

• 改善したいセンスの領域（1つ選択）：オンボーディング、アクティベーション、ナビゲーション／IA、エディター／ワークフロー、価格設定／パッケージングのUX、通知、リテンションの仕組み、信頼／安全性、パフォーマンス／レイテンシーの体感、コピー／語り口
• 対象ユーザーと、その領域における主要なジョブ・トゥ・ビー・ダン
• 調査するベンチマーク製品／体験を3～10件（または「不明のため、提案してください」）
• 期間（例：60～120分のスプリント、または2～4週間の練習計画）
• 制約（プラットフォーム、地域、アクセシビリティ、コンプライアンス、ブランドの語り口など）

情報が不足している場合の対応

• references/INTAKE.mdから最大5つの質問をします。
• それでも情報が不足している場合は、前提を明示して進め、範囲の異なる2つの選択肢（狭い範囲と広い範囲）を提示します。

成果物

センス基準化パックを作成します（チャット内のMarkdown形式、または希望に応じてファイル形式）：

1. センス基準化ブリーフ（領域、対象ユーザー／ジョブ、「良い」の定義、制約）
2. ベンチマークセット（5～10件）＋「選定理由」＋調査するポイント
3. プロダクト調査ノート（ベンチマークごとに1ページ）、一貫した批評テンプレートを使用
4. センスのルール＋アンチパターン（根拠から導いた、すべきこと／避けるべきこと）
5. 直感 → 仮説ログ（検証可能な仮説＋予測されるシグナル）
6. 検証計画（定性・定量チェック、最小限実用的なテスト）
7. 練習計画（2～4週間：体験時間＋週ごとの統合サイクル）
8. リスク／未解決の質問／次のステップ（必ず含める）

テンプレート：references/TEMPLATES.md

ワークフロー（8ステップ）

1) 情報収集＋センスの領域を選ぶ（課題を絞る）

• 入力： ユーザーの状況、references/INTAKE.md。
• アクション： センスの領域を1つ、対象となる「場面」を1つ（例：初回利用時のオンボーディング）選びます。対象ユーザー、ジョブ、制約を定義します。期間を設定します。
• 成果物： センス基準化ブリーフ（ドラフト）。
• 確認事項： 関係者が「どの具体的な体験を対象に、センスを基準化するのか」という質問に答えられること。

2) 「良いセンス」を雰囲気ではなく判断基準として定義する

• 入力： 領域＋ユーザー／ジョブ。
• アクション： 6～10個の基準を作成します（例：明瞭さ、価値実現までの時間、信頼、主体性、エラーからの回復、体感速度、認知負荷）。明示的なトレードオフ（何を犠牲にするか）も加えます。
• 成果物： ブリーフ内の基準一覧＋トレードオフのセクション。
• 確認事項： 基準がプロダクト内で観察可能であり（UIや動作を具体的に指摘でき）、汎用的な形容詞にとどまっていないこと。

3) ベンチマークセットを作る（厳選した体験時間）

• 入力： 既知のベンチマーク（またはなし）。
• アクション： 5～10件の優れた事例を選びます（直接の競合、隣接領域の事例、「ゴールドスタンダード」を少なくとも1件）。それぞれについて、調査する内容と関連する理由を記載します。
• 成果物： ベンチマークセットの表。
• 確認事項： 局所最適を避けるため、セットに「カテゴリー外」の参考事例が少なくとも2件含まれていること。

4) 貪欲なユーザーのように学ぶ（構造化された観察）

• 入力： ベンチマーク、批評テンプレート。
• アクション： 各プロダクトを対象ユーザーとして利用します。摩擦、満足感、混乱、信頼が損なわれる瞬間など、細かな出来事を記録します。「なぜ良い／悪いのか」より先に「何が起きたのか」を記録します。
• 出力： プロダクト調査メモ（ドラフト）。
• 確認事項： 各ベンチマークのメモには、スクリーンショットや引用があればそれらを添えた具体的な出来事を少なくとも3件含めます。ない場合は、正確に説明します。

5) 統合する：観察結果をセンスのルールとアンチパターンに変換する

• 入力： 各ベンチマークの調査メモ。
• アクション： パターンを分類します。根拠と適用箇所を添えて、ルールを DO／DO NOT の形式にします。「AI スロップ」（ありきたりで、一貫性がなく、ユーザー体験に合わないもの）を生み出すアンチパターンも追加します。
• 出力： センスのルール＋アンチパターン。
• 確認事項： 各ルールは、異なるベンチマークから得た2件以上の観察結果に裏付けられているか、「仮説」と明記されています。

6) 直感を仮説の生成に使う（検証可能にする）

• 入力： ルール＋直感的な反応。
• アクション： 「違和感があるのは、……だから」のような直感を記述し、予測される兆候と反証となる兆候を含む、検証可能な仮説に変換します。
• 出力： 直感 → 仮説ログ。
• 確認事項： 各仮説には、明確な反証条件を設定します（「Y の後に X が変化しなければ、私たちの仮説は誤りです」）。

7) 最小限の実行可能な確認で検証する（定性＋定量）

• 入力： 仮説ログ、利用可能なデータ／調査へのアクセス。
• アクション： 仮説ごとに、最も手軽な検証方法を選びます。ユーザビリティタスク、割り込み質問、セッションリプレイの確認、ファネルの一部分析、A/B テストのスモークテスト、コピーのテストなどがあります。成功指標とサンプルを定義します。
• 出力： 担当者と実施頻度が分かる場合はそれを含む検証計画。
• 確認事項： 検証手順は定められた時間内に実行可能で、機密データを必要としません。

8) 実践のサイクルと品質ゲートを作成して完成させる

• 入力： ドラフトパック。
• アクション： 2〜4週間の実践計画（学習時間のスケジュール＋毎週の統合）を作成します。references/CHECKLISTS.md を実施し、references/RUBRIC.md で採点します。リスク／未解決の質問／次のステップを追加します。
• 出力： 最終版センス調整パック。
• 確認事項： 読者は追加の背景情報なしで実践計画に従うことができます。前提条件は明記されています。

品質ゲート（必須）

• references/CHECKLISTS.md と references/RUBRIC.md を使用します。
• リスク、未解決の質問、次のステップを必ず含めます。

例

例1（オンボーディング）： 「一流の事例と比較して、オンボーディングに対する私たちのセンスを調整してください。対象ユーザーは初めて PM になる人です。制限時間は90分です。センス調整パックを出力してください。」
期待される結果：ベンチマーク一式、批評メモ、センスのルール、仮説、簡易な検証計画。

例2（B2B ワークフロー UX）： 「『プロジェクトを作成』するフローが遅く、分かりにくいと直感的に感じます。これを検証可能な仮説と検証計画に変えてください。」
期待される結果：反証条件と最小限の実行可能な確認を含む、直感→仮説ログ。

境界の例： 「一般に、優れたセンスとは何か教えてください。」
応答：具体的な領域と対象ユーザー／タスクを求めます。それ以外の場合は、領域の選択肢を提示し、範囲を絞った出発点を提案します。