mcpField
R
research-decision-room

research-decision-room

github.com/nexu-ioデザイン・UI104.6k2.2k 回インストール今日更新
リポジトリ

research-decision-room について

プロダクトやデザインのチームが、多様な調査証拠を単一ページの HTML 意思決定資料にまとめるスキルです。証拠、テーマ、確信度、トレードオフ、提案、実験を一か所に整理し、不確実性や証拠の限界も明示します。

主な機能

  1. 01意思決定の枠組みと仮定の明示
  2. 02構造化された証拠台帳
  3. 03確信度と矛盾を含むテーマ
  4. 04機会のスコアリング表
  5. 05意思決定メモと実験キュー
  6. 06自己完結型のインタラクティブ HTML

活用シーン

  1. 01製品機能を開発するか判断
  2. 02ユーザー離脱やオンボーディングの調査
  3. 03調査結果を関係者と共有

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/nexu-io/open-design --skill research-decision-room

インストール後、Claude Code で/research-decision-roomを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

example.html
references/
checklist.md
evidence-model.md

詳細

Research Decision Room Skill

製品チームやデザインチームが、まとまりのないエビデンスを明確な次の一手に変えられるよう支援する、1 ページの HTML 意思決定資料を作成します。出力は、見た目を飾るためのリサーチ資料ではありません。エビデンス、テーマ、確信度、トレードオフ、推奨する実験をまとめて見渡せる、議論のための作業スペースです。

リソース一覧

research-decision-room/
├── SKILL.md
├── example.html
└── references/
    ├── checklist.md
    └── evidence-model.md

統合を始める前に references/evidence-model.md を読み、資料を出力する前に references/checklist.md を実行してください。

このスキルを使う場面

次のような情報がユーザーから提供された場合に、このスキルを使ってください。

  • インタビューのメモ、ユーザビリティテストでの観察、サポートチケット、営業通話のメモ、アプリストアのレビュー、NPS のコメント、アンケートの自由記述、分析データの抜粋、製品の意思決定に関する背景情報。
  • エビデンスに基づく判断が必要な場合：「X を作るべきか？」「どのオンボーディング経路を試すべきか？」「ユーザーが離脱するのはなぜか？」「顧客が言う『遅い』とは、具体的に何を意味するのか？」
  • 長いリサーチレポートを読まないステークホルダーに調査結果を共有する必要がある場合。

純粋なビジュアルの着想、キャンペーンのアイデア出し、ブランドのムードボードには使わないでください。

ワークフロー

ステップ 1 - 意思決定の枠組みを定める

ユーザーのプロンプトから、意思決定の範囲を特定します。ユーザーが意思決定の内容を示していない場合は、エビデンスから導き出し、推定であることを明記します。

次の項目を含む簡潔な枠組みを作成します。

  • 意思決定に関する問い。
  • 対象者またはセグメント。
  • 対象期間。
  • 既知の制約。
  • この資料では判断しないこと。

重要な背景情報が不足していてもタスクの実行が妨げられない場合は、漠然とした質問をするのではなく、仮定であることを明記して進めます。

ステップ 2 - エビデンス台帳を作成する

references/evidence-model.md のモデルを使って、有用なシグナルをすべて台帳の行に整理します。

各台帳の行には、次の項目を含める必要があります。

  • id：I-03、T-14、M-02 などの短く安定した ID。
  • source_type：インタビュー、ユーザビリティ、サポート、アンケート、分析、営業、現場メモ、ステークホルダーのいずれか。
  • segment：ユーザーの種類、または「不明」。
  • signal：1 文で表した観察内容。
  • quote_or_metric：直接引用、指標、または「未提供」。
  • strength：強、中、弱。
  • limitations：このエビデンスに偏りや不完全さが生じる可能性がある理由。

引用、参加者数、日付、収益への影響、指標を決して捏造しないでください。ユーザーから数値が提供されていない場合は「未提供」と記載し、確信度を高めるためにどのようなエビデンスが必要かを説明します。

ステップ 3 - テーマと緊張関係を統合する

エビデンスを 4〜6 個のテーマに分類します。各テーマについて、次の項目を記載します。

  • 平易でわかりやすいテーマ名。
  • そのテーマを裏付けるエビデンス ID の一覧。
  • UI への不満だけでなく、その背後にある行動の説明。
  • 確信度（高、中、低）。
  • 矛盾点やセグメント間の違い。

名詞より動詞を優先します。「最初の空の状態で多くを求められると、チームはセットアップを中断する」は、「オンボーディングの問題」よりも適切です。

ステップ 4 - 機会を評価する

3〜5 個の選択肢を含む機会マトリクスを作成します。各選択肢を 1〜5 の尺度で評価します。

  • エビデンスの強さ。
  • ユーザーの苦痛。
  • ビジネス上の効果。
  • 実装リスク（5 はリスクが低く、1 はリスクが高いことを示します）。

合計スコアを示しますが、スコアだけで判断しないでください。最有力の推奨案が選ばれた理由を 1 文で加えます。

ステップ 5 - 意思決定メモを作成する

次の項目を含む意思決定メモを作成します。

  1. 推奨する方針。
  2. 今取り組む理由。
  3. それを裏付けるエビデンス。
  4. 誤りである可能性。
  5. 次に測定する項目。
  6. 後戻り可能な次のステップ。

1 分以内で読める長さにまとめます。

ステップ 6 - HTML アーティファクトを作成する

自己完結型の index.html を作成します。タイポグラフィ、余白、 色の役割、コンポーネントのトーンには、有効な DESIGN.md を使用しますが、情報アーキテクチャは 次の構成で維持してください。

  1. 意思決定に関する問い、自信度、最終更新ラベルを含むヘッダー。
  2. 推奨事項、リスク、次の実験を含むエグゼクティブ向け概要。
  3. フィルターチップ付きのエビデンス台帳。
  4. エビデンス ID と自信度を含むテーママップ。
  5. 機会マトリクス。
  6. 意思決定メモ。
  7. 担当者、指標、成功しきい値を含む実験キュー。
  8. 前提条件と制約事項。

アーティファクトは操作可能でありながら、長期的に利用できるものにします。エビデンスのフィルタリング、ビューの切り替え、関連 ID の強調表示には、シンプルなバニラ JavaScript を使用できます。 フレームワークへの依存は不要です。

ステップ 7 - 自己チェックして出力する

チェックリストを実行します。その後、簡潔な概要文を 1 つと HTML アーティファクトを 1 つ出力します。

<artifact identifier="research-decision-room" type="text/html" title="Research Decision Room">
<!doctype html>
<html>...</html>
</artifact>

閉じる </artifact> の後には何も記述しないでください。

コメント

Markdown 対応