第三章

用户角色建模

在许多项目中，似乎只存在一种用户类型，所有故事都是从该用户类型的角度来编写的。这种简化处理是一种谬误，会导致团队漏掉那些系统主要用户类型之外其他类型用户的故事。以用户为中心的设计学科（Constantine and Lockwood 1999）和交互设计（Cooper 1999）教我们懂得在编写故事之前识别用户角色[1]和用户画像的好处。在本章中，我们将介绍用户角色、角色建模、用户角色地图和用户画像，并展示如何使用这些初始步骤来编写更好的故事，开发更好的软件。

用户角色

假设我们正在建设BigMoneyJobs职位发布和搜索网站。这种类型的网站有许多不同类型的用户。当我们讨论用户故事时，我们所讨论的用户都有谁？我们是在讨论一个叫Ashish的人，他有一个工作，但总是在关注寻找更好的职位机会？我们是在讨论一个叫Laura的人，一个刚毕业的大学生，正在寻找她的第一份工作？我们是在谈论一个叫Allan的人，允许他每天下午都可以在毛伊岛风帆冲浪的任何工作机会，他都能够接受？或者我们是在讨论一个叫Scott的人，他并不讨厌他的工作，但他意识到是时候该换份新工作了？也许我们是在谈论一个叫Kindra的人，她六个月前被解雇了，现在她准备在美国东北部寻找工作机会。

或者，我们是否应该把为公司发布职位招聘的人也视为用户？也许用户是Mario，他在人力资源部门工作，由他发布新的职位空缺。也许用户是Delaney，他也在人力资源部门工作，但他负责审查简历。或者也许用户是Savannah，他是一个独立的招聘人员，同时关注好的工作机会和优秀的人才。

很明显，我们不能从单一用户的角度来编写故事，让这些故事来反映所有用户的经历、背景和目标是不可能的。Ashish是一个会计师，可能每个月只会看一次网站，只是为了让他的简历设置保持开放状态。Allan是一个服务生，他可能需要创建一个过滤器，当网站上任何时候有夏威夷毛伊岛上的任何工作机会发布时，就要马上通知到他，但是除非我们让功能变得简单，否则他是不会使用的。Kindra可能每天都要花几个小时寻找工作，随着时间的推移，她的职位搜索范围可能会扩大。如果Mario和Delaney在一家有很多空缺职位的大公司工作，他们可能会在网站上花上4个小时或者更多的时间。

虽然系统中的每个用户都有不同的背景和不同的目标，但我们可以使用术语“用户角色（User Roles）”来聚合单个用户。用户角色是属性的集合表征，属性包括用户群体的特征和该群体与系统的交互。因此，我们可以在前面的示例中查看用户，并将它们聚合为用户角色，如表3.1所示。

表3.1  BigMoneyJobs项目中一个可能的角色列表

当然，在不同的用户角色之间会有一些重叠。求职者、初次求职者、被解雇的受害者、工作地点搜索者和监视者都将使用该网站的工作搜索功能。他们可能以不同的方式和不同的频率来使用工作搜索功能，但是他们使用这个系统的方式将会是大体相似的。简历浏览者和职位发布者的角色可能也会有重叠，因为这些角色都有追求寻找优秀候选人的相同目标。

表3.1并不是将BigMoney-Jobs的用户们定义成角色的唯一可能方式。例如，我们可以选择诸如包括兼职、全职和合同工这样的角色。在本章的其余部分中，我们将讨论如何生成一个角色列表以及如何改进该列表，使其更有效用。