Framework Deep Dive

用户画像(Persona)

Persona 是一个虚构但有研究依据的用户角色,它把真实用户研究中的行为模式综合成一个有名字、有故事、有动机的人。好的 Persona 能让团队用「陈梅会用这个吗?」直接做出更好的设计决策。

「用户」是一个虚假的共识

在设计评审会上,每个人都在说「用户希望……」但每个人脑子里的「用户」是不同的。工程师想象的用户是懂技术的,设计师想象的用户是视觉敏感的,市场想象的用户是价格敏感的。这种隐性分歧是无数产品决策冲突的根源。

Alan Cooper 在 1999 年提出 Persona,正是为了解决这个问题。他发现软件开发者总是「为自己设计」,完全无法代入真实用户视角。Persona 的核心作用是:把「用户」这个抽象概念具体化为一个真实的、有名字的人,让团队在做每个决策时都有一个共同的参照物。

一个好的 Persona 回答了团队在任何设计节点都可能提出的问题:「陈梅(我们的主要 Persona)会在哪里遇到这个功能?她会理解这个操作吗?这个通知对她有价值吗?」当团队能用一个名字做出更好的设计决策,这个工具就在发挥作用。

好 Persona 的解剖:八个核心要素

Persona 不是一张人口统计表——它是一份行为与动机画像。以下是一个完整的研究型 Persona 范例,以及与「坏 Persona」的对比。

👩‍💼
陈梅
34 岁 · 某 B 轮教育 SaaS 公司产品经理 · 上海
「我每天的时间被会议切碎了,真正用来思考的时间不到两小时。我需要工具能帮我在碎片时间里也做出好决策,而不是让我另外再花时间学工具本身。」
行为目标
在季度规划周期内对齐研发和业务目标
用数据说服 CEO 优先级决策,而不是靠「感觉」
减少跨团队对齐会议,提升异步协作效率
核心痛点
工具太多:Notion、飞书、Jira 数据孤岛,切换成本高
下周的 Sprint Review 要汇报,但上周的数据还没整合好
新来的工程师不理解为什么某个决策是这样做的,她要花时间反复解释背景
实际行为(观察所得)
在手机上看竞品更新,通勤时段最活跃
在新工具中习惯找「能不能导出到 Excel」
评估新工具时先看有没有同行公司的案例
使用情境
主设备:MacBook Pro + iPhone 15
工作模式:混合办公,周一/三/五在公司
技术熟悉度:
好 Persona vs. 坏 Persona 的关键区别
好 Persona — 行为驱动
目标
「在不开额外会议的情况下让研发团队理解优先级变化的原因」
引用
「我最怕的就是开会开完还是没有结论。」(用户访谈原话)
行为
遇到新工具先找「能不能导出」,因为她不信任平台会长期存在
情境
通勤中用手机查竞品,到公司已经有了初步判断
坏 Persona — 人口统计填空
目标
「提升工作效率,用好工具」(对设计无指导意义)
引用
(无引用,或由团队自行编造)
行为
「喜欢使用移动设备和社交媒体」(无法区分任何具体设计决策)
情境
(空白,或「在办公室工作」这样的无用描述)
维度
原型画像(Proto-Persona)
研究画像(Research Persona)
数据来源
团队假设与经验
用户访谈 + 观察数据
建立时间
1–2 天
2–4 周研究 + 4–8 小时综合
准确性
需验证,可能有盲点
有数据支撑,更可信
最佳使用时机
研究前的方向假设
指导产品设计决策

什么时候该用它?

Persona 在任何「团队需要对用户视角保持一致」的节点都有价值。以下是六个最高频的应用场景。

🎨
设计评审中的快速裁决
两个设计方案争论不休时,用「陈梅会选哪个?」引导讨论回到用户视角,替代基于个人偏好的争论。
🆕
新成员快速上手产品理解
新加入的工程师或设计师通过阅读 Persona,在 1 小时内理解核心用户是谁、他们在乎什么,比任何产品介绍文档都更有代入感。
📋
功能优先级决策
在 Sprint 规划时问:「这个功能服务的是哪个 Persona?」如果答案是「两个都不太是」,这个功能就需要重新审视存在的必要性。
✍️
产品文案与 UI 措辞
「陈梅会看懂这个按钮标签吗?」「她会理解这个错误提示的意思并知道下一步怎么做吗?」Persona 让文案决策有了具体参照。
🗺️
用户旅程地图的起点
绘制用户旅程地图时,Persona 是旅程的主角。没有具体的 Persona,旅程地图就变成了泛化的流程图,失去了情感共鸣。
📊
多产品线 / 多用户群定位
当产品同时服务多个截然不同的用户群时,清晰的 Persona 体系能帮助团队分辨哪些决策要为哪个 Persona 优先,避免「为所有人设计」的陷阱。

Microsoft 残障包容性设计
(2015–2018)

2015 年,微软成立了包容性设计团队,由 Kat Holmes 领导,开始系统性地为残障用户群建立研究 Persona。这是 Persona 方法被用于改变产品方向的最有影响力的案例之一。

研究团队面访了 200 多位用户,横跨三类残障情境:永久性(如一只手臂截肢)、暂时性(手臂骨折打石膏)和情境性(抱着婴儿只有一只手可用)。这个洞察翻转了团队的假设:残障不是少数人的特殊状态,而是所有人在不同时间都会经历的情境。

Microsoft
包容性设计 Persona × Xbox 无障碍控制器 · 2015–2018
2015–2018
👤
驱动 Xbox 无障碍控制器的 Persona:Sadia
Sadia,28 岁
脑瘫患者,手部灵活性受限 · 热爱 Xbox 游戏
「我不需要怜悯,我需要的是一个能让我和朋友们一起玩游戏的控制器。现在的控制器对我来说每个按钮都要比别人多花三倍力气。」
设计决策检验方式
每一个硬件和软件设计决策都通过以下问题过滤:

「Sadia 能够使用这个功能吗?」
「如果 Sadia 只能用一只手,这个操作还能完成吗?」
「Sadia 需要多少时间来完成这个操作?」

这三个问题替代了传统的「普通用户会怎么用」假设,让设计团队始终保持在真实用户视角。
🔬
研究与 Persona 建立过程
1
面访 200+ 用户,覆盖永久、暂时、情境三类残障状态
2
发现美国 26% 成年人有某种程度影响产品使用的残障——远超任何少数群体定义
3
建立了涵盖视觉、听觉、运动、认知四大类残障情境的 Persona 体系
4
Sadia 的 Persona 成为 Xbox 硬件团队的首要设计参照,取代了原来的「平均玩家」假设
💡
超出预期的影响
Xbox 无障碍控制器 2018 年发布后 24 小时内售罄,获 Beazley 年度设计奖
微软包容性设计方法论随后开源,被数百家公司引用采纳
为「残障用户」设计的功能,事实上帮助了更广泛的用户群——比如语音控制功能帮助了所有开车时不能用手的用户
200+
研究访谈用户数
26%
美国成人受残障影响的比例
24 小时
Xbox 无障碍控制器发布后售罄时间

如何建立真正有效的 Persona

以下步骤适用于建立研究型 Persona。如果时间受限,步骤 1 后可直接进入步骤 4 建立原型画像,后续再用研究数据验证和修正。

01
确定研究目标与分层
1 天
在开始用户研究之前,先对齐团队:你们相信存在哪几类截然不同的用户群?这个假设将引导研究分层。

关键问题:是否要建立原型画像(Proto-Persona,基于假设,快速建立)还是研究画像(基于访谈数据,准确但耗时)?两者都有价值,关键是明确当前目的。

用行为差异而非人口统计来分层:不要说「25–35 岁女性用户」,而要说「经常在碎片时间使用的用户 vs. 有专门时间块的深度用户」。行为差异才决定设计需求差异。

输出:2–4 个用户群体假设,每个都有一句话的行为描述。
关键提示:Persona 数量不宜超过 4 个。超过 4 个,团队就记不住了,也不会真正使用。宁可精准描述 2 个,也不要泛泛覆盖 6 个。
02
执行用户访谈与观察
2–4 周
每个用户群体访谈 5–8 人(达到饱和点——当你开始听到重复的故事时,该分层的研究可以结束)。

访谈重点(不是问卷,是对话):
• 他们的目标是什么?(背后的动机,不只是表面需求)
• 他们现在怎么做这件事?(实际工作流程,不是理想流程)
• 什么让他们沮丧?(现有方案的失败之处)
• 他们用哪些工具,为什么选择这些工具?
• 他们如何做决策?谁会影响他们的判断?

尽量在用户的实际使用情境中观察——在会议室里谈论的行为和在实际工作中的行为往往不同。录音(获得同意),逐字记录重要引用。
关键提示:问「你通常怎么做 X?」而不是「你觉得 X 功能怎么样?」用户会给你想要听到的评价,但行为不会说谎
03
聚类分析与模式识别
1 天
把所有访谈数据放在一起(实体便利贴或数字白板均可),寻找跨用户的共同模式:

亲和图方法:把每条观察/引用/行为写在独立的便利贴上,然后把相似的聚在一起。让聚类自然浮现,不要强行套入预设分类。

寻找的模式:共同目标、共同挫折、共同行为习惯、共同的工具选择、共同的决策逻辑。

每个自然形成的聚类就是一个 Persona 的雏形。先给聚类起一个行为描述性的绰号(如「任务达人型」「探索试错型」),再给 Persona 起名字。

输出:2–4 个有清晰行为特征描述的用户群体聚类。
关键提示:这个步骤要邀请产品、设计、研发代表一起参与——亲身经历聚类过程的人,比读最终文档的人对 Persona 有更深的理解和认同。
04
建立 Persona 文档
4 小时
为每个 Persona 建立一份文档(严格控制在 1 页以内——超过 1 页就不会被使用):

必要内容:
名字 + 照片(用符合描述的库存图片,让 Persona 有人的感觉)
背景(职位、工作情境、与产品相关的生活背景,2–3 句话)
引用(来自真实访谈的逐字引用,这是 Persona 最有力的部分)
行为目标(他们试图实现什么?用行为动词描述,不是「想要更好」)
核心挫折(现有方案哪里失败了他们?)
实际行为(他们实际上怎么做的,而不是他们说的怎么做)
使用情境(什么设备、什么时间、什么环境下使用)

不要包含:薪资范围、受教育程度、家庭状况(除非与产品直接相关)。这些不影响设计决策。
关键提示:每个要点都要能回答「这会如何影响设计决策?」如果一条信息删除后不影响任何设计决策,它就不应该在 Persona 里。
05
内化到团队日常决策
持续执行
Persona 文档本身不是目标——让团队在日常中真正使用 Persona 做决策才是。

物理存在:把 Persona 打印出来贴在会议室墙上。让 Persona 的脸每天都能被团队看到,比任何数字文档的效果都好。

引入日常决策语言:
• 设计评审:「陈梅在这个情况下会怎么做?」
• Sprint 规划:「这个功能主要服务哪个 Persona?」
• 用户测试招募:「我们这次要找的是 A 型还是 B 型 Persona?」

定期更新:每 12 个月(或在发生重大市场变化时)用新一轮用户研究数据验证和更新 Persona。用户在演变,对他们的理解也应该演变。

Persona 老化警告信号:团队在讨论中不再引用 Persona 名字,或新成员根本不知道 Persona 的存在——这时候需要一次 Persona 刷新工作坊。
关键提示:如果你的 Persona 被团队称为「你的用户研究文档」而不是「陈梅」,说明它还没有被真正内化。名字是 Persona 生命力的标志。

虚构角色的真实力量:Alan Cooper 如何重塑软件设计的出发点

用户画像(Persona)方法由软件设计先驱 Alan Cooper 在 1980 年代的自我实践中发明,并通过 1999 年出版的《交互设计之路》(The Inmates Are Running the Asylum)正式推向业界。Cooper 的核心洞见是:为"普通用户"设计意味着为"没有人"设计,只有将目标用户具象为有名有姓、有目标有痛点的真实个体,设计决策才能真正以人为中心。

1983
Alan Cooper 在个人项目中首次使用 Persona 原型
Cooper 在开发一款项目管理软件时,创造了一个名叫 Kathy 的虚构用户角色,并持续对"Kathy 会怎么用这个功能"进行自问。这一非正式实践让他发现,明确具体的用户角色能显著提升设计决策的一致性和用户导向性。
1995–1998
Cooper Interaction Design 咨询实践系统化 Persona 方法
Cooper 在其交互设计咨询公司(后更名为 Cooper)中将 Persona 方法规范化,定义了角色基本信息、目标层次(体验目标、终极目标、生活目标)和行为特征的标准结构。该方法在硅谷科技公司客户群中获得实战验证。
1999
《交互设计之路》出版,Persona 正式进入设计主流
Cooper 出版《The Inmates Are Running the Asylum》,以锐利的批判性视角指出软件行业由工程师主导导致的用户体验危机,并将 Persona 方法作为解决方案系统阐述。本书成为人机交互领域的经典著作,Persona 随之成为交互设计和产品设计的标准工具。
2002
《About Face》深化 Persona 与 Goal-Directed Design 的完整体系
Cooper 联合 Robert Reimann 出版《About Face》第二版,将 Persona 置于"目标导向设计(Goal-Directed Design)"方法论体系的核心,详细阐述了 Persona 研究方法、角色类型(首要/次要/反面 Persona)和从 Persona 推导设计方案的完整流程。
2008–至今
从设计工具扩展为产品、市场、增长团队的通用语言
Persona 逐渐超越设计领域边界,被产品经理用于需求对齐,被市场团队用于内容策略和广告定向,被增长团队用于用户分群。随着数据驱动方法的兴起,"数据 Persona"(基于行为数据构建)与传统研究型 Persona 形成互补,成为现代产品团队的标配认知工具。

与这些工具搭配效果更好