research

リサーチ

ユーザーが指定するプロダクトについて、新たにUXリサーチを行います。

現在の、エビデンスに裏付けられたユーザーの問題に焦点を当てます。ログイン後のプロダクト体験、セルフサービスのフロー、オンボーディング、ドキュメント／ヘルプ、開発者体験、サポートにおける摩擦、プロダクトのワークフローを優先します。

重要な上書き指示

• 作業を進める前に、プラグインルーター $index を参照してください。
• $critical-overrides に従ってください。

ユーザーコンテキスト

作業を始める前に、$user-context を読み込み、ローカルシェルにアクセスできる場合は、そのプリフライトスクリプトを実行してください。

関連する場合は、保存済みのプロダクト URL、Figma ファイル、スクリーンショット、参考画像、コードベースのパス、Storybook、トークン、デザインシステム、ブランドアセット、コンポーネント参照、ブラウザーの設定、共有先を、根拠資料として使用してください。

保存済みの参考資料をすべて確認する必要はありません。現在のタスクに必要なものだけを確認してください。

契約

• 調査を始める前に、対象のプロダクト、対象ユーザー、対象期間、調査範囲を言い換えて確認してください。
• 既定では公開情報源を使用してください。コネクターが利用可能で、ユーザーの依頼で許可されている場合は、内部情報源も使用してください。
• 入手できる場合は、情報源を引用してください。
• 観察されたエビデンスと推論を分けてください。
• 個別のエピソードから過剰な主張をしないでください。
• 苦情を羅列するだけにしないでください。明確なプロダクトのストーリーを伝えてください。
• 情報源にアクセスできない場合や、根拠が弱い場合は、明確に伝えてください。

ワークフロー

1. 調査範囲を言い換えて確認します。

2. 公開情報源を検索します。

• Reddit
• X/Twitter
• Hacker News
• Stack Overflow
• GitHub のイシュー／ディスカッション
• 関連するフォーラム、ブログ、レビュー、YouTube のコメント、開発者コミュニティ

3. 利用可能な場合は、内部情報源を検索します。

• Slack
• Gong
• Notion
• Google Drive／ドキュメント
• Linear／Jira／GitHub
• 利用可能であれば、サポートや CRM の記録

4. エビデンスを、最もシグナルの強いUX上の問題ごとに分類します。

5. 次の項目を分けます。

• プロダクトの UI／ワークフローにおける摩擦
• ドキュメント／ヘルプにおける摩擦
• オンボーディングにおける摩擦
• アカウント、請求、権限、セットアップに関する摩擦
• 開発者／API／SDK に関する摩擦
• 信頼性／パフォーマンスの問題
• 機能リクエスト

6. 深刻度、頻度、確信度、プロダクトへの影響力に基づいて、問題に優先順位を付けます。

7. 明確なプロダクトのストーリーを伝えます。

出力

ユーザーが別の形式を希望しない限り、チャット内のリサーチブリーフを既定とします。

次の内容を含めてください。

• エグゼクティブサマリー：核心となるストーリーを5～7文でまとめます。
• 優先順位付きUX上の問題：各問題について、問題、ユーザーの目標、該当する箇所、何が妨げられるか、エビデンス、深刻度、頻度の兆候、確信度、推奨するプロダクト上の対応を記載します。
• 情報源マップ：検索した情報源、それぞれから得られた内容、シグナルが弱かった箇所を示します。
• 機会マップ：推奨事項を「今週対応」「今四半期に対応」「さらなる調査が必要」に分類します。

ルール

• 入手できる場合は、情報源を引用してください。
• 個別のエピソードから過剰な主張をしないでください。
• 声の大きい苦情と、頻繁に発生する問題を区別してください。
• UX上の摩擦と、機能の不足を区別してください。
• 信頼性／パフォーマンスの問題と、UXワークフロー上の問題を区別してください。
• 内部情報だけに基づくエビデンスは、公開情報に基づくエビデンスと分けて示してください。
• ブリーフは明快かつ具体的にし、読みやすくまとめてください。