接下来我将简要的概括10个步骤。只要责任团队明白跳过一步的因果关系，那么，使用角色的项目没必要都遵循全部10个步骤。

 

首先是掌握尽可能多的用户资料。这些用户资料来自几个途径：访谈、观察、二手信息、调查表、报告、文化研究等。在我的经验里，大公司常常拥有大量用户信息，市场报告，呼叫中心等等。这些在某种程度上可以取代与用户亲自见面，不过这样也产生了问题，诸如这些资料不能聚焦到项目涉及的主题上。这个问题在下一步感觉明显。

使用角色是以项目中产生的确定方式对用户聚焦。通常，公司都有讨论其用户的确定方式，而不会考虑用户使用网页/系统时的不同背景，在最近为丹麦政府机构所做的项目中，需要对不同政府机构的商业报告重新设计网页入口。该政府机构的传统是将丹麦商业划分成数量类和贸易类。通过在呼叫中心与政府职员访谈，和阅览了几个（网站）后，一个假设就形成了。

以前的商业划分模式在这个项目没有意义。谁跟别人做生意谁就负责填写，它象是什么事件？公司多大规模？填写报告的是公司员工还是咨询人员？就象这些问题都没啥关系。许多调查已经完成，但是没有一个调查考虑了这种划分，所以不得不从新视点重新审阅。

 

在我的经验里，角色项目中最困难的任务是“如何切蛋糕”－决定如何根据已有的数据来描述角色。这个问题占据了10个步骤中好几个步骤，涉及多个咨询团队或项目成员需要公正的移交某些描述。本步骤的重点是找到支撑角色雏形、角色描述和情景故事的数据资料。角色定义方法要求确定的一类信息，可以在角色描述时帮助产生共鸣和支撑情景故事。比如：用户喜欢什么不喜欢什么?他们的价值取向是什么？他们对于该系统\网页的态度是什么？用户在何种情况下将使用该系统\网页？当这些数据收集完成后，他们是支持还是反对最初的数据？

 

我这步的灵感和最初的步骤是从定性调查中搞清数据资料的意思。当有人能理解你的论点，也有人能得到相同结果的时候，你就知道自己是沿着正确的轨迹在前进。因此重要的是对其他团队成员、项目伙伴说明角色类别。

 

最重要的一步是角色描述要包括哪些内容，以及如何避免构建老套的角色。我常常看一些很难参与进去的角色描述，超人的或老套角色。在这个阶段，你必须知道虚拟角色的目的不是原封不动的描述用户，而是利用角色的需求作为出发点去找到解决方案。虚拟角色时必须具备对人物5个要素的描述，从中提取有用资料，不是专门提出，而是为参与者从描述中推断提供可能。身体（用一张照片或者一段话展示“这个人看上去是啥样”，创造出真人的感觉、体态和衣服，讲述关于这个人的很多事情。心理（我们对于生活和环境都有自己全面的观点，同样，生活和环境也影响了我们对待科技的方式，举例来说角色性格是内向还是外向。）背景（我们都具有影响我们能力、态度以及对这个世界看法的社会背景、教育程度和教养）对科技和设计领域的情绪和看法人物特性。这个人是狡猾的，在虚拟描述中，扁平人物和全面人物之间存在区别。扁平人物中被刻画成只有一种人物特性，这个特性被反射到角色的所有行为中，于是虚拟了一个可预测的老套角色。参与者很难对扁平人物进行分析。而全面人物具有多种特性，是不可预测的，也是很容易参与的。虚拟角色描述时，最基本的一点是要避免角色老套，而是项目成员容易参与的角色。因此明智的方法是寻找重复相同特性的资料。在我经历的一个案例中，虚拟角色喜欢一切都在掌握中的感觉，基于这一点，团队成员在文字描述时将虚拟角色的工作定义为税务机构工作，这反映了她的人生态度，她体重超重也很少朋友。对于团队成员来说，“一切都在掌握中”这条信息导致虚拟角色消极的人生态度，而且在虚拟角色所有信息中反复出现。第五步同样也是能够确保和增强大量进入一步。在我的经验里，很少部门允许团队成员成为虚拟角色描写过程中的成员，他们宁愿雇佣咨询人员或者用户研究部门完成虚拟角色的文字描述工作。角色方法更愿意被看作一个流程，每个人能知道角色描述如何得来和用来做什么。如果你让不同团队成员成为角色描述过程中的成员，那么，他们感觉角色是自己参与创造的。为确保描述和介绍时角色的一致性，虚拟角色可以被当作一个人重新描述，不过，为了在描述过程中得到更多内容，或者如同我们在项目中所做的一样，让参与者为虚拟角色挑选图片。（此处跟第八步重复了，不清楚原因）我非常清醒的认识到不是所有人都能作为流程中的一员，来了新人，一排同事可能会受影响，不过如果不能将虚拟角色传播给参与者的话那角色就毫无意义。不仅仅是需要将虚拟角色传播给每个人，还有虚拟角色得来的数据资料（如Grudin, Pruitt, Adlin所说的基础文档），以及为啥和如何使用该角色。许多项目忘了给开发人员和设计师讲授如何使用虚拟角色，如何思考情景故事或者如何使用虚拟角色。

 

如较早所提到的，虚拟角色的真实目的是从描述中创造情景故事。这一步是为情景故事做准备，描述的是哪儿？角色处于何种情形下将使用系统/网页？或者角色有何种需求？这些将引导一个使用环境。每种需求或者环境都是一个情景故事的开始。

 

为确保所有的参与者认同对虚拟角色和角色环境的描述，可以遵循两个策略：一是问每个人各自的意见，二是让他们参与其中。通常角色方法被看作用户与开发者或他人沟通的方式，不过它更多的是确保以用户为中心进行开发的流程。具有流程观点有助于尽可能多的股东能够一起发展虚拟角色，并将这些角色用于设计。

 

我非常清醒的认识到不是所有人都能作为流程中的一员，来了新人，一排同事可能会受影响，不过如果不能将虚拟角色发散给参与者的话那角色就毫无意义。不仅仅是需要将虚拟角色发散给每个人，还有虚拟角色之后的数据资料（如Grudin, Pruitt, Adlin所说的基础文档），以及为啥和如何使用该角色。许多项目忘了给开发人员和设计师讲授如何使用虚拟角色，如何思考情景故事或者如何使用虚拟角色。

 

如更早提到的一样，虚拟角色本身什么都不是，角色只有进入到场景才具有价值。一个场景就象一个故事，有一个主要人物（角色）、背景（行为发生的地方），有目的（角色想要完成何事？），有完成目标的行动（与系统/网页/设备的交互行为），而且还不够，还有妨碍完成目标的路上障碍。我曾经见到很多我称为快乐情景故事，在故事里面一个设备就能解决所有的问题。设法读读Tahira Khan夫人是如何战胜糖尿病的这段描述，你会明白我的意思。这不是一个很现实或有说服力的例子，一个65岁的老年妇女，最近到英国旅行，她有糖尿病，几乎不懂英语，母语的读写能力也很贫乏，凭借电子设备克服了糖尿病。 

 

最后，我推荐对于虚拟角色更新信息。如果用户测试突然显示新的结果或者角色环境发生某种变化，就需要做这步了。最重要的是：不是所有人都能改变信息，而是知道要去联系谁。我经常推荐要有一个角色大使，他时常要浏览角色描述。如果项目参与者发现了不当的描述后可以与他联系，还有就像Adlin 和 Pruitt在“角色生命周期”推荐的那样，当角色完成了其存在的目的之后，让角色死亡。