proto-persona

用途

创建初步的、基于假设的用户画像，将现有用户研究、市场数据和利益相关方知识综合起来，形成关于目标用户的工作假设。借此在产品开发早期让团队达成一致，指导初步设计决策，并找出需要通过研究验证的认知盲区。

这不是经过验证的用户画像，而是一个会随着认知加深而不断演进的“原型”用户画像。可以把它看作一个结构化的占位方案：它能避免设计变成委员会决策，同时也承认我们还没有所有答案。

输入

最适用： 你需要为其建立工作画像的目标用户或细分群体。 也有帮助： 现有的各种信号——支持反馈主题、销售案例、分析数据、过往研究——以及该用户画像将指导的决策。

调用时一并提供的任何内容——技能名称后的文本、粘贴的上下文内容，或附加的 ARGUMENTS: 行——都视为已经给出的答案。使用这些信息，并跳过其中已涵盖的问题；不要重复询问。

没有提供任何信息也没关系。 此技能会询问你认为用户是谁、你已掌握哪些信息，然后整理这些内容，并标出需要验证的假设。

调用示例： 为采用我们收据扫描应用的个体簿记员创建原型用户画像——信号：30 条支持工单和 4 份销售通话记录。

核心概念

什么是原型用户画像？

原型用户画像是一种轻量级、由假设驱动的用户画像，基于以下信息创建：

• 现有研究： 用户访谈、问卷、分析数据（如有）
• 市场数据： 行业报告、竞品分析、人口趋势
• 利益相关方知识： 销售、支持和团队洞察
• 有根据的假设： 需要验证的最佳推测

原型用户画像与经过验证的用户画像

原型用户画像	经过验证的用户画像
用几小时或几天创建	用几周或几个月创建
基于假设和有限研究	基于广泛的用户研究
用于团队早期达成一致	用于指导详细设计
快速演进	长期稳定
足以起步	置信度高

为什么要使用原型用户画像？

• 速度： 无需等待数月的研究，就能让团队快速达成一致
• 聚焦： 为“我们正在为谁打造产品”提供共同的参照点
• 假设框定： 明确列出假设，以便后续验证
• 避免泛化设计： “为所有人设计”＝为任何人都没设计

反模式（它不是什么）

• 不是经过验证的研究： 不要把它当作事实——它只是一种假设
• 不能取代用户研究： 用它来指导研究，而不是回避研究
• 不只是人口统计数据： 年龄和所在地无法解释行为
• 不是一成不变的： 随着认知加深，原型用户画像也应不断演进

适用场景

• 产品开发早期阶段（尚未开展广泛的用户研究）
• 启动新功能或业务转型
• 让利益相关方就目标用户达成一致
• 发现研究缺口（我们需要访谈哪些人？）

不适用场景

• 已完成广泛的用户研究（应改为创建经过验证的用户画像）
• 用户细分已明确的成熟产品（此时应该已经有经过验证的用户画像）
• 替代定量数据（原型用户画像用于指导研究；研究用于验证画像）

---

应用

使用 template.md 填写完整结构。

步骤 1：收集现有上下文

创建原型用户画像前，请收集：

• 用户研究： 访谈记录、问卷结果、支持工单
• 分析数据： 使用数据、人口统计信息、行为模式
• 市场数据： 行业报告、竞品用户群体
• 利益相关方洞察： 与用户有接触的销售、支持、CS 团队
• 产品背景： 你要解决什么问题？（参阅 skills/problem-statement/SKILL.md）

如果缺少上下文： 不要捏造信息——记录缺口，并规划研究以补齐信息。

---

步骤 2：定义用户画像的身份

名称

为该用户画像取一个押头韵、容易记住的名字（便于引用）。

### Name
- [Alliterative name, e.g., "Manager Mike," "Startup Sarah," "Enterprise Emma"]

质量检查：

• 容易记住： 团队能轻松记住这个名字吗？
• 避免泛泛而谈： 避免使用“用户 1”或“用户画像 A”

---

简介与人口统计信息

描述这个人在现实生活中的身份。

### Bio & Demographics
- [Age range]
- [Geographic location]
- [Social status (married, single, family, etc.)]
- [Online presence (active on LinkedIn, avoids social media, etc.)]
- [Leisure activities]
- [Career status (job title, industry, seniority)]

质量检查：

• 关注行为，而不只是人口统计信息： 不要只写“30-40 岁，住在旧金山”——还要补充“远程办公，活跃于 Slack 社群，同时兼顾 3 个副业项目”
• 与背景相关： 只纳入会影响产品决策的人口统计信息

示例：

• “35-45 岁，居住在城市地区（纽约、旧金山、奥斯汀）”
• “在中型科技公司（50-500 名员工）担任总监级职务”
• “活跃于 LinkedIn 和 Twitter，每年参加 2-3 场会议”
• “已婚，有年幼的孩子，重视工作与生活的平衡”
• “周末参加休闲体育活动，通勤时收听商业播客”

---

第 3 步：记录他们的表达方式

引言

使用真实或具有代表性的引言，展现他们的思维和表达方式。

### Quotes
- "[Quote 1 revealing what they say, feel, or think]"
- "[Quote 2 revealing frustrations or motivations]"
- "[Quote 3 revealing attitudes or beliefs]"

质量检查：

• 真实： 如有访谈或支持工单中的真实引言，请使用
• 能揭示想法： 引言应展现其思维方式，而不只是事实（“我需要更好的工具”就比较弱；“我被手动工作压得喘不过气，根本无法专注于战略”就很有力）

示例：

• “我每周花 10 小时参加本可以通过邮件解决的状态会议。”
• “我受够了那些声称能自动化，却还得找开发人员来配置的工具。”
• “团队希望我能立即给出答案，但我却一直在搜索数据。”

---

第 4 步：记录他们的背景

痛点

这个用户画像会遇到哪些问题或挫折？（结构请参考 skills/jobs-to-be-done/SKILL.md。）

### Pains
- [Pain point 1 related to the problem space]
- [Pain point 2 related to the problem space]
- [Pain point 3 related to the problem space]

质量检查：

• 具体： “对工具感到不满”很笼统；“每周花 3 小时在不同工具之间手动复制数据”则很具体
• 与产品相关： 聚焦产品能够解决的痛点

---

这个人正在努力达成什么？

他们追求哪些行为、行动或结果？

### What is This Person Trying to Accomplish?
- [Behavior or outcome 1]
- [Behavior or outcome 2]
- [Behavior or outcome 3]

质量检查：

• 可观察： 这种行为能被观察到吗？（“获得晋升”是内在目标；“提前 2 周交付项目”则可以观察）
• 以结果为中心： 写结果（“更快地做出数据驱动的决策”），而不是任务（“使用仪表板”）

---

目标

他们想要什么、需要什么、梦想实现什么？

### Goals
- [Goal 1: want, need, or dream]
- [Goal 2: want, need, or dream]
- [Goal 3: want, need, or dream]

质量检查：

• 涵盖短期和长期目标： 包括战术性目标（“在第 2 季度前发布功能”）和愿景目标（“在 3 年内成为副总裁”）
• 兼顾个人和职业目标： “花更多时间陪伴家人”可能与“提高团队效率”同样重要

---

第 5 步：了解影响因素

决策权

他们是否有权购买你的解决方案？

### Attitudes & Influences

- **Decision-Making Authority:** [Yes/No + context (e.g., "Has budget authority up to $10k, needs exec approval above that")]

质量检查：

• 符合采购实际： 如果他们是使用者而非购买者，请注明由谁批准采购

---

决策影响者

谁会影响他们的决策？

- **Decision Influencers:** [Who influences this person? (e.g., "Boss, peers in industry Slack channels, analyst reports")]

质量检查：

• 具体： 不要只写“他们的经理”，要列出具体的影响因素类型（同事推荐、Gartner 报告、Twitter 讨论串等）

---

信念与态度

哪些信念和态度会影响他们的决策？

- **Beliefs & Attitudes:** [Beliefs/attitudes that impact decisions (e.g., "Skeptical of tools that require training," "Values data-driven decision making")]

质量检查：

• 与采用相关： 聚焦于会影响他们是否使用产品的信念

---

第 6 步：验证并迭代

• 与团队分享： 这个用户画像是否引发共鸣？他们能认出这个人吗？
• 找出信息缺口： 我们还不知道什么？（对不确定的内容添加“[ASSUMPTION—VALIDATE]”标签）
• 规划研究： 用原型用户画像指导下一步访谈对象的选择
• 持续完善： 随着了解的深入，更新原型用户画像（或将其升级为已验证的用户画像）

---

示例

完整的原型用户画像示例请参阅 examples/sample.md。

简短示例摘录：

### Name
- Manager Mike

### Quotes
- "I spend more time in status meetings than actually building product."

---

常见误区

坑点 1：只有人口统计信息，没有行为信息

症状：“28 岁，住在纽约市，有一只狗”

**后果：**人口统计信息无法解释 为什么 某人会使用你的产品。

**解决方法：**补充行为背景：“远程办公，活跃于 5 个 Slack 社群，重视异步沟通工具。”

---

坑点 2：把原型用户画像当作事实

症状：“经理 Mike 绝不会使用功能 X，因为他讨厌复杂性。”

**后果：**你把假设当成了已验证的研究结果。

**解决方法：**添加“[ASSUMPTION—VALIDATE]”标签，并计划开展访谈来检验假设。

---

坑点 3：创建 10 个原型用户画像

**症状：**试图预先描绘所有可能的用户类型。

**后果：**分析瘫痪。团队无法聚焦于主要用户。

**解决方法：**从 1-2 个原型用户画像（主要用户 + 次要用户）开始。随着验证和拓展，再增加更多画像。

---

坑点 4：捏造引语

**症状：**听起来像营销文案的引语：“我喜欢能给我带来惊喜的产品！”

**后果：**虚假的用户画像会导致虚假的共情。

**解决方法：**使用访谈、支持工单或销售电话中的真实引语。如果还没有引语，请注明“[PLACEHOLDER—NEEDS RESEARCH]”。

---

坑点 5：从不验证

**症状：**原型用户画像创建于 6 个月前，此后从未更新。

**后果：**你正在围绕一个可能错误的假设进行设计。

**解决方法：**规划研究冲刺，验证关键假设。随着认知加深，迭代原型用户画像。当信心足够高时，将其升级为已验证的用户画像。

---

参考资料

相关技能

• skills/problem-statement/SKILL.md — 用户画像为“I am”部分提供信息
• skills/jobs-to-be-done/SKILL.md — JTBD 为用户画像的痛点和目标提供信息
• skills/positioning-statement/SKILL.md — 用户画像对应“For [target]”
• skills/user-story/SKILL.md — 用户故事使用“As a [persona]”

外部框架

• Alan Cooper，《The Inmates Are Running the Asylum》（1998）— 用户画像概念的起源
• Jeff Gothelf，《Lean UX》（2013）— 原型用户画像作为假设驱动的研究工具
• Indi Young，《Mental Models》（2008）— 行为驱动的用户画像开发

Dean 的作品

• Proto-Persona Profile Prompt（灵感源自 Productside Product Manager's Playbook）

来源

• 改编自 https://github.com/deanpeters/product-manager-prompts 仓库中的 prompts/proto-persona-profile.md。

---

**技能类型：**组件 建议文件名：proto-persona.md 建议放置位置：/skills/components/ **依赖项：**引用 skills/jobs-to-be-done/SKILL.md、skills/problem-statement/SKILL.md 使用方：skills/positioning-statement/SKILL.md、skills/user-story/SKILL.md、skills/problem-statement/SKILL.md