name: proto-persona description: 创建一个初始的、基于假设的人物画像，综合可用的用户研究、市场数据和利益相关者知识，形成关于目标用户的工作假设。用于对齐 type: component
目的
创建一个初始的、基于假设的人物画像，综合可用的用户研究、市场数据和利益相关者知识，形成关于目标用户的工作假设。用于在产品开发早期对齐团队、指导初步设计决策，并识别需要通过研究验证的理解缺口。
这不是一个已验证的人物画像——它是一个“原型”（原型）人物画像，随着您了解更多而演化。将其视为一个结构化的占位符，以防止设计由委员会决定，同时承认您尚未掌握所有答案。
关键概念
什么是原型人物画像？
原型人物画像是一个轻量级、基于假设的人物画像，创建自：
- 现有研究： 用户访谈、调查、分析数据（如果有）
- 市场数据： 行业报告、竞争对手分析、人口趋势
- 利益相关者知识： 销售、支持、团队见解
- 有根据的假设： 需要验证的最佳猜测
原型与已验证人物画像
| 原型人物画像 | 已验证人物画像 |
|---|---|
| 在几小时/天内创建 | 在几周/月内创建 |
| 基于假设 + 有限研究 | 基于广泛的用户研究 |
| 用于早期对齐团队 | 用于指导详细设计 |
| 快速演化 | 随时间稳定 |
| 足够开始 | 高置信度 |
为什么使用原型人物画像？
- 速度： 快速对齐团队，无需等待数月的研究
- 焦点： 提供“我们为谁构建”的共享参考点 n- 假设框架： 使假设明确，然后可以验证
- 防止通用设计： “为所有人设计” = 不为任何人设计
反模式（这不是什么）
- 不是已验证的研究： 不要将其视为事实——它是一个假设
- 不是用户研究的替代品： 用它来指导研究，而不是避免研究
- 不仅仅是人口统计数据： 年龄和位置不解释行为
- 不是永久的： 原型人物画像应随着学习而演化
何时使用
- 早期产品开发阶段（在广泛用户研究之前）
- 启动新功能或转型时
- 对齐利益相关者关于目标用户时
- 识别研究缺口（我们需要采访谁？）
何时不使用
- 在完成广泛用户研究后（改为创建已验证人物画像）
- 对于成熟产品，已知用户细分（您应该已有已验证人物画像）
- 作为定量数据的替代品（原型人物画像指导研究；研究验证它们）
应用
使用 template.md 获取完整的填充结构。
步骤1：收集可用上下文
在创建原型人物画像之前，收集：
- 用户研究： 访谈笔记、调查结果、支持票证
- 分析数据： 使用数据、人口统计、行为模式
- 市场数据： 行业报告、竞争对手用户基础
- 利益相关者见解： 销售/支持/客户成功团队与用户互动
- 产品上下文： 您要解决什么问题？（参考
skills/problem-statement/SKILL.md）
如果缺少上下文： 不要编造——注明缺口并计划研究来填补。
步骤2：定义人物画像的身份
名称
给人物画像一个头韵、易记的名称（便于引用）。
### 名称
- [头韵名称，例如“经理迈克”、“初创莎拉”、“企业艾玛”]
质量检查：
- 易记： 团队能否轻松回想？
- 非通用： 避免“用户1”或“人物画像A”
简介与人口统计
描述此人在现实世界中是谁。
### 简介与人口统计
- [年龄范围]
- [地理位置]
- [社会状态（已婚、单身、家庭等）]
- [在线存在（活跃于领英、避免社交媒体等）]
- [休闲活动]
- [职业状态（职位、行业、资历）]
质量检查：
- 行为导向，不仅仅是人口统计： 不要停在“30-40岁，住在旧金山”——添加“远程工作，活跃于Slack社区，同时处理3个副项目”
- 上下文相关： 仅包括影响产品决策的人口统计
示例：
- “35-45岁，居住在城市地区（纽约、旧金山、奥斯汀）”
- “中型科技公司总监级别（50-500名员工）”
- “活跃于领英和推特，每年参加2-3个会议”
- “已婚有年幼孩子，重视工作与生活平衡”
- “周末玩休闲运动，通勤时听商业播客”
步骤3：捕捉他们的声音
引语
使用真实或代表性的引语，揭示他们如何思考和说话。
### 引语
- “[引语1，揭示他们说什么、感受或思考]”
- “[引语2，揭示挫败感或动机]”
- “[引语3，揭示态度或信念]”
质量检查：
- 真实： 如果可用，使用访谈/支持票证中的真实引语
- 揭示性： 引语应暴露心态，不仅仅是事实（“我需要更好的工具”较弱；“我淹没在手动工作中，无法专注于战略”较强）
示例：
- “我每周花10小时在状态会议上，这些会议本可以是电子邮件。”
- “我厌倦了承诺自动化但需要开发人员设置的工具。”
- “我的团队期望我立即提供答案，但我一直在搜索数据。”
步骤4：记录他们的上下文
痛点
此人物画像经历什么问题或挫败感？（参考 skills/jobs-to-be-done/SKILL.md 获取结构。）
### 痛点
- [与问题空间相关的痛点1]
- [与问题空间相关的痛点2]
- [与问题空间相关的痛点3]
质量检查：
- 具体： “对工具感到挫败”模糊；“每周花3小时手动在工具间复制数据”具体
- 与您的产品相关： 专注于您的产品可能解决的痛点
此人试图实现什么？
他们在追求什么行为、行动或结果？
### 此人试图实现什么？
- [行为或结果1]
- [行为或结果2]
- [行为或结果3]
质量检查：
- 可观察： 您能看到此行为吗？（“获得晋升”是内部的；“提前2周交付项目”是可观察的）
- 结果导向： 不是任务（“使用仪表板”）而是结果（“更快做出数据驱动决策”）
目标
他们的愿望、需求、梦想是什么？
### 目标
- [目标1：愿望、需求或梦想]
- [目标2：愿望、需求或梦想]
- [目标3：愿望、需求或梦想]
质量检查：
- 短期和长期： 包括战术目标（“在第二季度前发布功能”）和抱负目标（“3年内成为副总裁”）
- 个人和职业： “花更多时间与家人在一起”可以与“提高团队生产力”一样相关
步骤5：理解他们的影响因素
决策权
他们是否有权力购买您的解决方案？
### 态度与影响
- **决策权：** [是/否 + 上下文（例如“有高达1万美元的预算权，超过需要执行批准”）]
质量检查：
- 采购现实： 如果他们是用户但不是买家，注明谁批准购买
决策影响因素
谁影响他们的决策？
- **决策影响因素：** [谁影响此人？（例如“老板、行业Slack频道中的同行、分析师报告”）]
质量检查：
- 具体： 不只是“他们的经理”——命名影响类型（同行推荐、Gartner报告、推特线程等）
信念与态度
什么信念和态度塑造他们的决策？
- **信念与态度：** [影响决策的信念/态度（例如“怀疑需要培训的工具”、“重视数据驱动决策”）]
质量检查：
- 与采用相关： 专注于影响他们是否使用您的产品的信念
步骤6：验证和迭代
- 与团队分享： 此人物画像是否产生共鸣？他们是否认可此人？
- 识别缺口： 我们不知道什么？（在不确定处添加“[假设—验证]”标签）
- 计划研究： 使用原型人物画像指导下一步采访谁
- 演化它： 随着学习，更新原型人物画像（或升级为已验证人物画像）
示例
查看 examples/sample.md 获取完整原型人物画像示例。
迷你示例摘录：
### 名称
- 经理迈克
### 引语
- “我花在状态会议上的时间比实际构建产品还多。”
常见陷阱
陷阱1：没有行为的人口统计
症状： “28岁，住在纽约市，有狗”
后果： 人口统计不解释为什么有人会使用您的产品。
修复： 添加行为上下文：“远程工作，活跃于5个Slack社区，重视异步沟通工具。”
陷阱2：将原型人物画像视为事实
症状： “经理迈克永远不会使用功能X，因为他讨厌复杂性”
后果： 您将假设视为已验证研究。
修复： 添加“[假设—验证]”标签并计划访谈来测试假设。
陷阱3：创建10个原型人物画像
症状： 试图前期建模每种可能的用户类型
后果： 分析瘫痪。团队无法专注于主要用户。
修复： 从1-2个原型人物画像开始（主要+次要）。随着验证和扩展添加更多。
陷阱4：编造引语
症状： 听起来像营销文案的引语：“我喜欢让我愉悦的产品！”
后果： 虚假人物画像导致虚假同理心。
修复： 使用访谈、支持票证或销售通话中的真实引语。如果尚无引语，注明“[占位符—需要研究]。”
陷阱5：从不验证
症状： 6个月前创建的原型人物画像，从未更新
后果： 您为可能错误的假设设计。
修复： 计划研究冲刺来验证关键假设。随着学习演化原型人物画像。当置信度高时升级为已验证人物画像。
参考文献
相关技能
skills/problem-statement/SKILL.md— 人物画像告知“我是”部分skills/jobs-to-be-done/SKILL.md— JTBD告知人物画像痛点/目标skills/positioning-statement/SKILL.md— 人物画像是“对于[目标]”skills/user-story/SKILL.md— 故事使用“作为一个[人物画像]”
外部框架
- Alan Cooper, The Inmates Are Running the Asylum (1998) — 人物画像概念的起源
- Jeff Gothelf, Lean UX (2013) — 原型人物画像作为基于假设的研究工具
- Indi Young, Mental Models (2008) — 行为驱动的人物画像开发
Dean的工作
- 原型人物画像配置文件提示（灵感来自Productside产品经理剧本）
来源
- 改编自
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