产品沉思录 - 用户画像的起源：The origin of personas

type

status

date

slug

summary

category

icon

password

这是 2017 年初翻译的一篇关于 Persona 的起源，最近整理笔记的时候又发现了，似乎没在这里发过，所以重新整理了下。知道过去，才能更好地设计未来。

当时正在帮许多公司做产品咨询，发现许多公司并不知道自己的用户是谁，沟通起来效率也很低，就额外增加了 Persona 这堂课和这个调研部分。不过当时也激起了自己的好奇心，想知道用户画像到底是怎么来的，便有了此文。

2017 年中加入丁香医生之后，也要求团队做了大量的用户调研，最终沉淀了一些用户画像，文章末尾有一些早期案例（不代表今日用户构成），仅供参考。

本文作者阿兰·库珀（ Alan Cooper ），交互设计的提倡者。现在经营一家设计公司 Cooper，并且著书讲述如何让软件的用户界面更加人性化。库珀有些时候被叫做 Visual Basic 之父，虽然大多数的工作是由微软的内部开发团队完成的，但是对于 Windows 可视化设计工具的创意是来源于库珀的。

《交互设计之路：让科技回归人性》，出版于 1998 年，介绍了使用人物角色（ Persona ）作为实际的交互设计工具。基于其中一个章节的讨论，人物角色由于其不同寻常的能力和极高的效率在软件行业得到了普及。人物角色曾经在实验室中得到了多年的发展，其完整的发展历程早就公布于世。只是这些年我在 Cooper 的工作中经常使用而已，随着那本书的出版，很多人来追问人物角色的起源是什么，这里我们就来仔细谈谈。

在《硅谷之火》这本书中，作者 Paul Freiberger 和 Mike Swaine ，早在 1975 年写出了「微机上的第一款商业软件」，像同时期的那么多软件一样，它非常的难用，其真正证明的是：写出一个易于使用的软件比大家想象的更有难度。尽管我一直致力于让软件更加易用，但是直到 1983 年，在我完成了 15 个商业或私人项目之后，我才开始寻找一种有效的方法来解决这个问题。

我当时在写一个关键路径管理软件的时候，姑且叫他「 Plan*it 」吧，我采访了七八个将来可能是这个软件使用者的同事。特别是我与一位在 Carlick 广告公司的名叫 Kathy 女士进行了很深入的沟通。当时 Kathy 的工作主要是负责运营，确保项目中每个人都得到充分的发挥。这就像一个经典的项目管理任务。Kathy 就顺理成章的成为了我的第一个人物角色的原型。

在 1983 年，计算机的性能还是非常的孱弱，往往一次编译就需要好几个小时。我基本上利用午饭的时间进行编译。我当时住在加利福尼亚的蒙特利，靠近 Old Del Monte 高尔夫球场。饭后计算机往往还在继续进行着编译，我就会去球场走几圈。从我家可以不受打扰的走到第九球洞，就是散步中，我设计了我的程序。

在我散步的过程中，我开始自己和自己对话，把自己设想成一个项目管理人员，就像之前提到的 Kathy 一样，在我的程序中完成一些操作或者向我提出一些新的需求。我经常沉浸在这种对话中，大声的说话还做着各种奇怪的手势，让一些没意识到我存在的打球的人吓了一跳，当然这并没有打扰我，因为我发现这种类似于戏剧表演的方法，对于拆分复杂的需求非常的有帮助，能让我看到什么是必要的什么是不必要的，更重要的是能让我区分哪些功能常用的哪些功能不常用。

「 Plan*it 」最终卖给了冠群公司，并作为一个顶级产品向公众发布，这个项目取得了商业上巨大的成功。在接下来的许多年中，它是个人电脑上项目管理的主要工具，其设计模式成为了今天市场上领导产品，微软的 Project 的原型。

我使用类似的方式设计的另一个产品是一种可视化编程语言「 Ruby 」。我最终将 Ruby 销售给了 Bill Gates ，他将其 QuickBASIC 语言结合在一起，创建了 Visual Basic 。在那之后，我成为加利福尼亚的美国银行的一名 IT 经理。

在 1990 年，我并没有设计一些新的程序，而是第一次以一个顾问的身份给我的同事提供软件设计方面的经验。我很快的就发现了做咨询和企业发明有很大的区别。以前我只要做我认为是正确的事情就行，但现在我不得不说服我的客户，让他们看到我提供的方案的优点。这种沟通方式促使我将人物角色的概念正式建立起来。

1995 年，我与被成为「商业洞察」先锋的 Sagent Technologies 的三位创始人合作。我发现自己不断地进行着循环对话。我问他们用户使用他们软件的典型例子是什么，答案总会像下面这样「他们会需要一个自定义销售报表，可能包括一个图形，或者是他们的销售数据。反正它能做任何他们想要的事情」。这些聪明的富有逻辑的程序员似乎无法想象一个普通的用户如何使用他们的产品，即使它有如此丰富的功能。不幸的是，我还被要求帮他们把软件介绍给客户。

虽然当时这还是一家刚成立的公司，自己的产品还没有发布，但创始人已与三家以前的客户公司建立了良好的业务关系。Sagent 公司产品营销主管 Alice Blair 带我拜访了六个预定他们产品的客户。其中一个是一所大型大学的金融分析师，一个是软件公司的营销分析师。只有一部分人精通计算机。我通过一些开放式问题来了解他们的工作，以及他们想通过这些数据来实现什么。虽然他们之间的需求差异巨大，但是通过几次访谈之后，一些模式便慢慢的清晰了起来。用户分为三个不同的群体，他们的目标、任务和技能水平明显不同。如果像过去我自己设计软件那样，我会开始扮演起这些人。但是现在的情况导致我不得不把他们的许多特征描述给 Sagent 团队。所以我创建了Chuck，Cynthia 和 Rob 。这三个角色是第一个真正的，目标导向的人物角色。

Chuck 是一个使用现成模板和报告的分析师。Cynthia 也是一个分析师，她使用类似的现成的模板。但 Cynthia 还写了几个模板给了 Chuck 使用。Rob 是支持 Cynthia 的 IT 经理。他可以优化 Cynthia 的模板，但他自己并不会编写模板来使用。

在接下来的小组会议上，我从 Chuck ，Cynthia 和 Rob 的观点呈现了我的设计，而不是从我自己观点设计的。结果非常戏剧性，虽然对这种方法还是颇有微词，但是程序员还是可以通过这几个假设原型清晰的了解我的设计意图。从那时起，我总是使用其中一个角色介绍设计工作，最终连 Sagent 工程师都开始使用「 Cynthia 会做什么」「 Chuck 是否能理解」这样的对话模式。当产品最终上市的时候，虽然界面设计还是比较粗糙，但是它拥有一个明确的，面向三个人群的交互界面：Chuck 的界面允许他选择和使用现成的模板，建立报告; Cynthia 的界面允许她设计和发布模板; Rob 的接口允许他优化 Cynthia 的模板的性能，而不改变他们的内容或操作。该产品非常成功，它定义了一个新的产品领域。公司也成功的于四年后上市。

至此，Chuck ， Cynthia 和 Rob 作为我的设计工具，与作为开发团队沟通工具，其效果是显而易见的。于是我开始在我的所有设计项目中使用人物角色这个工具，Cooper 的设计师也是如此。在接下来的几年里，我们开发和完善了这项技术。它成为我们交互设计的秘密武器。一些人建议我不要公开人物角色这个秘密，保持我们的竞争优势。但在我看来，角色是如此简单，清晰，强大，即使我不公开，其他的从业者也会很快的发现这个秘密。当这种情况发生时，我还是会失去我的竞争优势，但如果我现在公开我所了解的人物角色，至少我还可以对行业有一些贡献。

那本书旨在提醒管理者设计非工程师使用的软件中可能存在的问题。它从来不是作为一个给交互设计师「如何去做」的书。当时的交互设计还是比较少提及，我的方法论也显得比较陌生。我觉得有必要添加一些基于目标导向方法的介绍。我的目标只是要证明我的方法是有效的：它是不同的，它是有效的，它是真实的。

我总是说，人物角色是反直觉的，更准确的说，他们是反逻辑的。我怀疑这就是为什么他们起源于实践，而不是在实验室或学术界。设想下，根据用户的指令来设计，你会倾向于浏览用户社区，收集他们的功能请求，然后为他们提供包含所有这些功能的产品。我称之为「大而全的设计」。但是有充分的经验证明，这种解决方案很有局限的。因为，虽然逻辑是一个强大和有效的编程工具，但是对于交互设计来说，它的作用非常小（因为大多数人都是没有逻辑的）

我的很多前辈都采用像创建人物角色一样的人种用户研究结构来帮助他们设计。产品营销专家多年来也使用像人物角色一样的方法来统计人口分布。但人物角色是独特的，唯一的。

角色（ Persona ），像所有强大的工具，易于上手难于精通。Cooper 的互动设计师也要花上几个星期的学习和几个月的实践，才能创造专业水平的人物角色并熟练的应用。许多设计师使用了 Inmates 上面 25 页的「角色操作方法」手册，但是关于人物角色的完整「方法」还没有被写出来。我希望有一天，Cooper 的一个非常有成就的架构师会写出这本书，因为他们已经开发了一种复杂技术，远远超出了我当时基础设计。我期待他们对人物角色做出巨大的贡献。

补记：

用户画像并不是一次定型就不需要在改变了，相反画像应该跟随业务的发展而不断地更新。下面就是我们 2018 年早期的案例，时至今日许多业务都已经发生了巨大的变化，不能再按照当时的画像来按图索骥。

另外就是许多人做用户画像的时候，会用许多统计数据来描绘一个人，比如男，三线城市，月收入 4000 等，但这是错误的。用户画像是影响用户行为和动机，而人口统计特征是结果，不能影响用户的行为。应更加关注用户如何看待、使用产品，并如何与之互动

根据俞军老师的理论，用户是需求的集合，所以用户画像不能用来概括所有的的可能性。同样一个业务部门的不同业务，可能画像截然不同，所以不是一个团队做完用户画像其他人就高枕无忧了。

当年总结了一个如何做用户画像的 PPT ，有兴趣的朋友回复「Persona」拿吧，日后有机会会再迭代几个版本。另外用研需要大量的理解用户的决策流程，这个我在产品沉思录精选里面第一部分着重强调增强自己认知的原因，点击阅读全文，查看精选集内容。