角色设计的方法

而且，角色这个方法是用来其它支持用户中心设计的方法和手段的，而不是要取代它们。我们还是需要继续进行任务分析来了解网站应提供的细节任务。网站的可用性测试还是很有价值的，并且，很多用户中心设计的方法在创建角色的时候还是要使用的，比如用户访谈和观察。

引入角色时可能遇到的障碍

第一次引入角色往往不是一帆风顺的。我们会遇到一些诸如下面的相反意见：

角色和市场定位没有什么不同

市场定位可以帮助我们来确定什么样的人群最有可能使用某个网站，并帮助了解为什么他们会使用这个网站，这一点市场用户定位很有价值。然而，市场定位并不能告诉我们网站需要如何来运行、如何设计最好等。

市场定位或许能够确定出来37%的25岁到35岁之间的女性想要通过网络来预订下一个假期的安排，并且价格因素和旅店档次也影响着她们的决定。而另一方面，一个角色，可以告诉我们27岁的莎莉想通过互联网来安排她下一次的假期旅行，但她担心她选择的旅店可能和宣传页上看到的不一样，也担心这间旅店周边可能没有餐厅和酒吧，还担心她到了该旅店后人家会不会承认她在网上的预订。莎莉还希望可以在旅行开始的60天前取消旅店预订不用交罚金。

市场定位是对角色设计的很有用的输入，可以帮助我们确定用户的类型。不过，市场定位却不能给我们提供角色需要的更丰富的资料。

有一篇文章讲述市场定位和角色制定的区别，我们可以参考一下。作者是Cooper交互设计公司的Elaine Brechin，题目是Reconciling market segments and personas 。

角色在严肃的IT世界中没有位置

角色让有一些人感到不快。对于一些人来说，用真实的姓名来谈论根本就不存在的人的名字，讨论着他们的品性行为，感觉有些怪怪的；并且角色的讲故事的本质对于一些组织或者设计队伍来说就是不适合他们的文化

如果遇到这些情况，我们也大可不必彻底放弃角色。我们可以采取一些较为温和的形式。下面是一些小技巧：

• 一开始要避免或尽量少使用角色的资料细节，包括照片。当人们对这个概念热身过之后，我们可以逐步引入角色的概念。
• 可以不使用真实的姓名来描述这个角色，而使用一些头衔或称谓。比如，本文开始介绍的鲍勃这个角色，我们就可以不用鲍勃这个名字，而是使用诸如‘高级技师’之类的名称
• 用列表或列举的形式来描述角色，而不是使用叙述的方式。用较为简短的句子列表来描述用户的目标、行为、喜欢什么、不喜欢什么。

下面是修改了的角色鲍勃的例子。尽管这个没有叙述式的角色那样有血有肉，还是会让整个团队专注于用户的需求方面。

几个角色形象怎么能代表整个用户群

当你第一次给别人解释通过寥寥几个角色就能设计出网站的时候，有一些人一定会带着怀疑的眼光看着你。仅仅两三个角色、就算是四五个角色怎么能够囊括整个用户群的需求呢？

传统的用户中心设计方法涉及对尽可能多的用户进行研究调查，并搜集他们所有的需求。这样就会产生出一个长长的，却没有优先级的用户需求列表。这种指引方向的缺乏转换为设计的典型结果就是想要涵盖所有的用户需求，最终却没能很好的满足任何一个用户的需求。

比如，你可能对对某企业里的五十个人就他们对内部网的需求进行过采访。之后你列出了一个需求列表，以及用户希望的功能等方面的想法。例如，电话本要和企业的组织结构图相关联，还要可以查看每个员工有几天的年假还没有休完。你还了解到电话支持中心的员工希望能够非常快的访问到很多信息，而接电话的响应时间不会被影响太多。最后，你还认识到分公司的销售部门很快就要在几个月内连接一个新的网络，然后他们就也可以连入使用这个内部网。

你怎么应对这些需求？你要设计一个满足电话支持中心的员工的内部网吗？毕竟，他们是有着最严格生产要求的那些人。如果是这样的，当销售人员与客户面对面时，如何获取他们需要的信息？还有，总部的员工怎么办？比如那些仅需要访问少量的独特内容的技术部门的员工。

角色突破了这些困惑。角色使我们识别不同的用户集合，进而创建出典型的用户来代表不同的群组。为角色进行设计，就能够满足具有类似目标和需求的用户群。

通过定义主要角色和次要角色，我们也可以了解先为哪一类用户设计，以及是否需要设计不止一个用户界面。如果我们设计时只考虑了其他人而不是主要角色，那么主要角色的需求就不会被满足。反之，如果我们设计时先考虑了主要角色，那么其他人的需求就可能会被满足。比如，我们刚才的例子中，我们为电话支持中心的员工设计，那么分公司的销售人员以及总部的技术人员的需求也是可能被满足的。然而，我们如果仅仅考虑总部的技术人员，那么电话支持中心或者分公司的销售他们的需求就很可能满足不了。