synthetic-users について
synthetic-usersは、実地調査の前に合成ペルソナでインタビューガイドを試すUXリサーチスキルです。質問の欠陥を見つけて改訂版を作成しますが、シミュレーションの回答は証拠ではないと明示します。
主な機能
- 01特性の出典を示すペルソナ
- 02懐疑的なペルソナを最低1人作成
- 03特性に基づくシミュレーション回答
- 045種類の質問の欠陥を確認
- 05インタビューガイドの改訂
- 06日付付きの調査成果物
活用シーン
- 01実地調査前のインタビューガイド確認
- 02誘導的・仮定的な質問の発見
- 03質問が行動の具体例を促すか確認
- 04実際のインタビュー用改訂台本の準備
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ pedroromeroluna/ ai-first-product-skills --skill synthetic-usersインストール後、Claude Code で/synthetic-usersを入力して読み込まれたか確認します。
詳細
synthetic-users — Diagnosis + Script v2
パイプラインの第4ステーションです。ux-research が作成したガイドを、実際のフィールドワークに最初の1分を費やす前に、合成ペルソナ(明示的な特性を持つシミュレーション上のプロフィール)を使って試します。一般的なドメインの例:B2B の予約管理アプリでは、小規模クリニックの管理者と、類似ツールを試したものの使うのをやめた懐疑的な人物をシミュレーションできます。
呼び出されるタイミング
| タイミング | From / to |
|---|---|
ux-research の Research Plan に v1 ガイドがすでにある | ux-research からの入口(.agents/skills/ux-research/SKILL.md) |
| Diagnosis + Script v2 が作成された | 出口:実際のフィールドワーク — インタビューなど、オペレーターが担当する実際の作業です。このパックのスキルには含まれません |
| 実際のフィールドワークの後 | 生の回答を insight-engine(.agents/skills/insight-engine/SKILL.md)で収束させ、そこからパイプラインは prd が作成する戦略レイヤー(.agents/skills/prd/SKILL.md)へ進みます |
ルールその1
これは何も検証しません。 セッションの冒頭でこの文を述べ、終了時にも繰り返します。合成ペルソナの回答は、実際のユーザーで何かが機能する証拠にはなりません。目的はただ1つ、フィールドワークの時間を費やす前にガイドの欠陥を見つけることです。それ以外の目的はありません。本文で何度このルールを繰り返していても、仮説を検証したかのように読める Diagnosis は、適切に書かれていません。
合成ペルソナ
各プロフィールを作成する際は、.agents/skills/grill/SKILL.md#method のプレッシャー手法を使います。パスを引用し、決してコピーはしません。プロフィールに加える前に、提案された各特性の出所をプレッシャーをかけて確認します。
シミュレーション上の各ペルソナには、特性とその明示的な出所が付与されます。各特性に個別に印を付けます。
| 印 | 出所 |
|---|---|
| (evidence) | このセグメントについてすでに行われた実際の調査 — インタビュー、利用状況の数値、Discovery Brief または Market Brief に含まれる情報など |
| (public data: | 対象セグメントが属する母集団を説明する公開データセット。名前とリンクを引用します |
| (assumption) | 調査も公開データも根拠にない構成 |
印のない特性はプロフィールに加えません。
特性を assumption とする前に、公開データを検索します。 検索するカタログは Kaggle(kaggle.com/datasets)、Hugging Face(huggingface.co/datasets)、Google Dataset Search(datasetsearch.research.google.com)です。データセットがその特性を対象としている場合は (public data: <source>) と記し、対象となるデータセットがなければ (assumption) のままにします。
公開データに evidence の印を付けることはありません。 公開データセットが説明するのは一般的な母集団であり、この製品のセグメントではありません。公開データを evidence として数えると、合成ペルソナの検証度を実際以上に高く見せてしまいます。
少なくとも1人は懐疑的なペルソナを含め、その理由を示します。 すでに類似のものを試して使うのをやめた人、ビジネス上の異議(コストやプロセスの変更)がある人、あるいは仮説が前提とする問題をそもそも抱えていない人などです。仮説を支持するだけのペルソナの集合では、欠陥を見つける役には立ちません。確認する役には立ちます。
シミュレーション上の回答にはすべて、その根拠となる特性を、その特性の印とともに明記します。 例:「使いません。すでに Jira を使っています(根拠:Jira を毎日使っている、public data)」。特性にどの印が付いていても、回答そのものは常に作りものです。特性を明示することで、どの回答に根拠があり、どの回答が純粋な構成なのかがわかり、質問の不備とペルソナの構築の不備を区別できます。
コストを添えずに「とても気に入りました!」とは答えません。 合成ペルソナの熱意ある回答にはすべて、そのコストや摩擦も添えます。本人にとって何が負担になるのか、何を懸念しているのか、何をやめる必要があるのかを示します。熱意だけの回答は、学ぶためではなく、仮説を確認するためにガイドが作られているという兆候です。
質問の不備の分類
v1 スクリプトのすべての質問をこの一覧に照らしてレビューし、見つかった不備には書き換え案を添えて記録します。不備を指摘するだけではいけません。
| 不備 | 例 | 書き換え |
|---|---|---|
| 誘導質問(答えを示唆している) | "自動リマインダーがあれば便利だと思いませんか?" | "今日、予約を忘れないようにするにはどうしていますか?" |
| 仮定の質問(「〜を使いますか?」) | "予約を自動で変更してくれる機能があれば使いますか?" | "最後に予約の変更が必要になったときのことを教えてください" |
| 二重質問 | "ダッシュボードは分かりやすく、すばやく使えますか?" | 属性ごとに1つずつ、2つの質問に分けます |
| 行動に結びつかない質問 | "一般的に、予約管理についてどう思いますか?" | "チームの予約を管理したのは、いつが最後ですか?" |
| セグメントで使われていない専門用語 | プロダクトチーム内で使われている技術用語 | 先行調査から得た、セグメントが使う言葉 |
Diagnosis + Script v2
最後に、成果物を読み込んだプロダクトノードに関する、日付入りの調査として次の場所に記録します。
research/<YYYY-MM-DD>-script-diagnosis.md
日付を付け、上書きはしません。パスは、脳の tree.md にある content: */products/*/research/*.md
の行に含まれるため、新しい glob もリゾルバーの行も必要ありません。プロダクトノードがない場合は、同じファイル(<YYYY-MM-DD>-script-diagnosis.md)を現在のフォルダーに保存します。
Diagnosis は次の4つのセクションを、この順番で、それぞれ文字どおりの見出しを付けて記載します。
## Synthetic personas
## Simulation
## Defects found and rewrites
## Script v2
- 合成ペルソナ:各プロフィールと、その特性に付けた
(evidence)、(public data: <source>)、または(assumption)のラベルを記載し、懐疑的なペルソナはそのように明示します。 - シミュレーション:v1 スクリプトに対するシミュレーション回答を記載します。各回答では、根拠となる特性を明示し、熱意にはすべてその代償を添えます。
- 見つかった不備と書き換え:分類にある不備のうち、実際に見つかったものをすべて書き換え案とともに記載します。
- Script v2:実際のフィールドワークに使える、修正済みのガイドを記載します。
Script v2 セクションは、ルール1を明記した文「これは何も検証しません」で始まり、最後の質問の後にも同じ文を記載して終わります。
この成果物が主張しないこと
Diagnosis + Script v2 は、実際のフィールドワークに代わるものではありません。実在の人への最初のインタビューに、不備のあるスクリプトが持ち込まれるのを減らすためのステップです。実際のフィールドワークで得られた内容を統合し、トランスクリプトから知見を導き出すことは、このスキルの役割ではありません。それは insight-engine の役割です。
保存先
スキルは成果物を作成する前に保存先を解決し、作成後に解決することはありません。ケースは3つ、保存先は2つです。
- プロダクトノードが読み込まれている場合:成果物は、そのノードの
research/<YYYY-MM-DD>-<name>.mdに保存します。 - ブレインはあるものの、プロダクトノードがない場合 — まだワークスペースがない場合、またはプロダクトノードのないワークスペースの場合:成果物は現在のフォルダー内のファイルに書き込みます。
- ブレインがまったくない場合:成果物は現在のフォルダー内のファイルに書き込みます。
プロダクトノードがない場合、いずれにしてもファイルは現在のフォルダーに書き込まれます。終了メッセージでは、書き込んだパスだけを示してそこで終わります。これは、このスキルの通常の終了方法であり、例外として説明するものではありません。
このスキルは、どの保存先を使うか尋ねることも、3つ目の保存先を勝手に作ることもありません。
残りのパックは、スキルを1つずつインストールします。まず .agents/skills/ を確認し、次に .claude/skills/ を確認します(両方にあるスキルは1つとして数えます)。まだないスキルだけを提示してください — セッションごとに1回のみです。このスキルがセッション中に初めて終了する際に提示し、同じ成果物や別の成果物で後から終了しても、再度提示することはありません。
grill—npx skills add pedroromeroluna/ai-first-product-skills --skill grillinsight-engine—npx skills add pedroromeroluna/ai-first-product-skills --skill insight-engineprd—npx skills add pedroromeroluna/ai-first-product-skills --skill prdux-research—npx skills add pedroromeroluna/ai-first-product-skills --skill ux-research
パック全体を一度にインストールする場合:npx skills add pedroromeroluna/ai-first-product-skills。このコマンドはパックが提供するものをインストールします。上記のスキルは、それぞれの名前を指定してインストールします。