user-modeling

ユーザーモデリング

ユーザーをより深く理解し、より良いプロダクトの意思決定に役立てます。

このスキルの目的

ストックフォト付きのマーケティングペルソナではなく、ユーザーのニーズや行動を明らかにする、行動に基づくユーザーモデルを作成します。

入力要件

このスキルは、次の情報があると最も効果を発揮します。

• problem-framing の出力（問題の定義、ターゲットユーザー、JTBD）
• 既存の調査資料（インタビュー、アンケート、サポートチケット、Reddit のスレッド、レビューなど）

調査資料がない場合は、仮説から始めることもできます。ただし、検証が必要な点として明示します。

ワークフロー

ステップ 1：コンテキストを収集する

上流の成果物を取り込むか、次の質問をします。

• 誰のために作っていますか？
• そのユーザーについて、すでにどのようなことが分かっていますか？
• 見込みユーザーと話したことはありますか？
• レビュー、フォーラム、サポートチケットなどのデータソースはありますか？

ステップ 2：ユーザーセグメントを特定する

次のような意味のある違いを探します。

• 目標 — 何を達成しようとしていますか？
• 状況 — いつ、どこでその問題に直面しますか？
• 制約 — 選択肢を制限するものは何ですか？
• スキルレベル — どの程度の知識や経験がありますか？
• 頻度 — どのくらいの頻度でこの問題に直面しますか？

すべての違いが重要とは限りません。何を作るかが変わる違いに焦点を当てます。

ステップ 3：ペルソナを作成する

意味のある各セグメントについて、簡潔なペルソナを作成します。焦点がぼやけないよう、ペルソナは最大 2～3 人にします。

ステップ 4：シナリオを定義する

各ペルソナについて、プロダクトを使う具体的なシナリオを 2～3 個定義します。これらはユーザーストーリーやフローの基礎になります。

ステップ 5：インサイトを特定する

プロダクトの意思決定に役立つパターンを明らかにします。

• すべてのペルソナに共通する点は何ですか？
• どこに違いがありますか？
• それぞれに対して、何を変えて作りますか？

ユーザーに提示しながら、Write ツールを使って出力を design/02-user-modeling.md に自動保存します。

出力形式

# User Modeling: [Project Name]

## Context
[Brief summary of the problem space and what we know]

**Research basis:**
- [Source 1: what it told us]
- [Source 2: what it told us]
- [Or: "Based on assumptions—needs validation"]

---

## Personas

### Persona 1: [Name/Label]
*[One-line description of who they are]*

**Goals:**
- [Primary goal]
- [Secondary goal]

**Context:**
- [When they encounter the problem]
- [Where they encounter it]
- [What else is going on]

**Pain points:**
- [Frustration 1]
- [Frustration 2]

**Current behavior:**
- [How they solve this today]
- [Tools they use]
- [Workarounds they've developed]

**Constraints:**
- [Time/budget/skill/access limitations]

**What success looks like:**
- [How they'd know the problem is solved]

**Quote:** *"[Something they might say that captures their mindset]"*

---

### Persona 2: [Name/Label]
*[One-line description]*

[Same structure]

---

### Persona 3: [Name/Label]
*[One-line description]*

[Same structure]

---

## Scenarios

### Persona 1 Scenarios

**Scenario 1.1: [Name]**
- **Situation:** [Context—what's happening]
- **Trigger:** [What prompts them to act]
- **Goal:** [What they're trying to accomplish]
- **Current approach:** [How they handle it today]
- **Frustration:** [What's broken about current approach]

**Scenario 1.2: [Name]**
[Same structure]

### Persona 2 Scenarios

**Scenario 2.1: [Name]**
[Same structure]

---

## Key Insights

### Commonalities
[What all personas share—these are table-stakes features]
- [Insight 1]
- [Insight 2]

### Divergences
[Where personas differ—these inform prioritization]
- [Persona 1] needs [X], while [Persona 2] needs [Y]
- [Persona 1] is [context], while [Persona 2] is [different context]

### Design Implications
[How this should influence what you build]
- [Implication 1]
- [Implication 2]
- [Implication 3]

---

## Validation Needed
[What assumptions need testing]
- [ ] [Assumption to validate]
- [ ] [Assumption to validate]

適用ガイドライン

最小（明らかなユーザータイプが 1 つの場合）：

• ペルソナ 1 人、シナリオ 2～3 個
• Divergences セクションは省略
• 全体で 1 ページ

標準（ユーザータイプが 2～3 種類の場合）：

• 以下に示す全構成を使用
• 全体で 2～3 ページ

調査重視（実際のユーザーデータがある場合）：

• 調査の概要を含める
• 実際のユーザーの引用を追加する
• 付録でソースデータにリンクする

優れたペルソナとは

優れたペルソナ：

• 属性ではなく、目標や行動によって定義されている
• 何を作るかを変えるような気づきをもたらす
• 個人ではなく、パターンに基づいている
• 意思決定に使えるだけの具体性がある

よくないペルソナ：

• ストックフォトに年齢、職業、趣味を添えただけ
• 誰にでも当てはまるほど抽象的
• 1 件のインタビュー、または純粋な仮定に基づいている
• プロダクトの意思決定に役立たない

避けるべきアンチパターン

• 何でも盛り込む — 重要でない限り、属性を追加しない
• クローン軍団 — ペルソナに意味のある違いがなければ、統合する
• 願望の投影 — ユーザーにこうあってほしいという姿ではなく、実際の姿をモデル化する
• エッジケースの収集 — 考えられるすべてのユーザーではなく、主要なユーザーに焦点を当てる

引き継ぎ

ペルソナを提示した後、次のように尋ねます。

「/solution-scoping に進んで機能の優先順位を決めますか？それとも /prd-generation に進みますか？」

注： コンテキストを保持するため、ファイルは design/02-user-modeling.md に自動保存されます。