一文讲清楚构建用户原型/角色的规范操作

在《CX、UX、PX，产品经理必须要搞清楚的3个X是什么》这篇文章中介绍UX的时候，我说：UX主要是由UX团队来负责，产品经理提供必要的数据。

不得不说真有细心的朋友，有朋友就问我，这个必要的数据是什么？

这个问题确实问的有水平，有高度，为什么呢，因为产品经理的工作有一个明显的特征，就是不但要分析各种各样的数据，更为重要的是要把分析的结果尽可能具象的呈现出来，毕竟要做出最终决策的那帮人喜欢的是直观的感受，而不是抽象的表示。

既然UED团队要去设计UX，同样的道理，我们作为产品经理，自然要提供一个形象的说明作为UX设计的输入，这个形象的说明是什么呢？

就是：用户原型/角色，User Persona。

原因其实很简单，我们想了，如果我们向UED团队提供的是一堆和用户有关的各种结构化或非结构化的数据，那UED团队的伙计们非的拿板砖拍死我们，毕竟他们的大脑更擅长“设计”，而非“数据”。

因此，产品经理必须得基于获得的数据来形成一个直观的用户形象交付给UED团队，让他们在设计之初，脑袋中就存在一个很清晰的用户样子。

所以，我这里找补一下，把那句话再说的准确一些：

UX主要是由UED团队来负责，产品经理提供基于必要数据的用户原型。

废话不多说，正文开始。

1、什么是用户原型/角色

到底什么是用户原型/角色呢？定义如下：

A User Persona is a fact-based visual representation of a set of users that helps design teams visualize, understand, and build relevant connections with the target users.

用户角色是一组用户的基于事实的可视化表示，它帮助设计团队可视化、理解并建立与目标用户的相关联系。

定义很简单，我重点想说的是这个定义很明确的指明了产品经理和设计团队之间的关系，看定义，是不是有“目标用户”四个字，这个不用多解释吧，“确定目标用户”的工作肯定是产品经理的，而如何基于“目标用户”的特征，把他们和产品之间的“交互关系”设计出来，那肯定就是设计师们的事了。

当然，其中的“可视化”、“理解”、“建立”这些就是我开篇说到的，产品经理要把和用户有关的抽象的数据形成具体的形象，从而有助于设计团队理解。

2、用户原型/角色分几类？

原型还有分类？

很多产品经理可能会有这样的疑问，原型不就是原型吗，还有什么分类呢？

还真有，因为这个知识点不是本文的重点，因此，大家先了解一下就可以了，有时间的话，我再补上这个知识点的讲解。

原型分为三类，大家看下图：

1）轻量化原型：Lightweight Persona，也被称为是“Proto Persona”，正如上图中释义所示，这种原型是一种基于已有研究而做出的一种假设性质的原型；

2）定性原型：Qualitative Persona，是一种基于新的研究的小样本，小范围的原型，通常的研究方法有访谈，焦点小组，可用性测试等；

3）统计学原型：Statistical Persona，是一种基于大量定性研究，并通过统计学分析形成的原型，可以简单的认为这种原型是定性原型的扩展。

3、构建用户原型的规范操作是什么？

我们先来看一个用户原型构建完的呈现形式是什么，大家看下图：

或许有些朋友会把注意力放到原型呈现的形式上，第一张是PMManager制作的，第二张是PPT制作的，第三张是Excel制作的。

但我要说的是，原型用什么形式呈现并不重要，重要的是我们得从这三张图中看到我们都需要呈现原型的哪些信息。

第一步：确定想要呈现的用户原型信息

大致说来，原型有两类信息，一类是“描述性变量”，另一类是“行为变量”，前者主要包括工作，年龄，性别，收入，教育等，后者主要包括行为，目标，挑战等。

这两者之间的逻辑关系大致是：

因为【描述性变量】的特征，在某个场景中，产生了什么样的【行为变量】。

这个逻辑关系其实就是我们发现用户问题的关键来源，这个还是有机会了再细讲。

一旦我们确定了想要呈现的用户原型信息，那么，我们就对构建用户原型有了一个较为清晰的方向。

第二步：基于用户原型信息的详细研究

如果我们把第一步中的“描述性变量”和“行为变量”所涉及到的用户原型信息比作是数据库中的类别的话，那么，在第二步中，我们就需要基于这些确定的类别做详细的研究来丰富我们的用户原型“数据库”。

具体研究的方法那就多了，我们常见的市调就是一大类，当然，还有现在我正在连载的《企业如何构建产品探索框架》这个系列，但是，无论是采用什么样的方法，对于产品经理而言，深入，深入，再深入是我们做好用户原型构建的基础要求，尽可能的在类别中添加更多的和真实用户有关的信息，将会让你最终构建出来的用户原型更为真实。

第三步：研究用户原型真实的场景

我们一定要记住一点：

环境产生行为，行为产生挑战，挑战产生问题，问题产生需求。

也就是说，任何一个真实的用户对产品有诉求，根本原因还是TA在特定的空间时间内因为某些事物对TA形成了挑战，而自己又无法解决才有这样和那样的诉求。

我们把这种情况称之为“场景”。

因此，在构建用户原型的时候，不是只知道我们要服务哪些人就可以了，而是要知道他们在什么样的环境中有什么样特定的行为模式，即使是同类原型，他们之间的共性和差异都是什么，这样有助于让我们基于“场景”的差异而划分出不同类型的用户原型。

第四步：对信息进行组织

通过第二步和第三步，事实上我们获得的是“描述性变量”和“行为变量”的相关信息，假设我们已经获得了足够多的信息，那么，接下来我们就要对这些进行组织和分类了。

对信息的组织和分类，注意一点就可以：

我们一定是基于典型的用户来构建用户原型。

何为典型？

如果其中有15个产品经理，有1个项目经理，那么，放弃掉这个项目经理；

如果其中大部分的用户是30岁以下，那么，放弃掉30岁以上的用户；

如果大部分用户更关心产品带来的价值（比方说明显的效率提升）而不是价格，那么，可以考虑把价格定的高一些或以高级版为主。

也就是说，我们对用户原型信息的组织，事实上就是一个不断去除非目标用户群体的过程，因为只有这样才能有效率，也才能促进我们设计出最佳的解决方案。

第五步：分享你的构建结果

只存在于产品经理“头脑”中的用户原型是没有任何意义的，我们必须确保我们的设计团队能够清晰的知道他们接下来将要向哪些用户提供各种体验。

因为只有这样，他们才能时刻在头脑中知道他们所做的所有工作都是“为了谁”，以及在和你探讨需求和设计的时候，能够始终和你在一个用户频道上。

即使是和早期的设计团队交付用户原型，也并非一件太容易的事，大家看下图：

毕竟每个角色的工作重点不一样，而你必须得向每个角色说清楚“用户”期望什么样的体验。

当然了，如果你现在很不幸的扮演着五合一的角色，那，沟通的问题就没有了，剩下的就是纯体力活了。

关于用户原型构建的规范操作我觉得讲这么多就差不多了，其它的就是些有时间丰富一下的知识。

回到开篇，之所以写这篇文章是因为有朋友问了问题，我呢，也想了想，确实是，三个X的那篇文章我的初衷就是总结性质的，确实没想到会引起一些朋友的深入探讨，这样吧，我也别等着朋友们再问了，我主动点，下篇文章，我就聊聊如何设计良好的产品体验。