产品经理必备用户角色模型分析word精品文档10页.docx

产品经理必备用户角色模型分析word精品文档10页.docx

《产品经理必备用户角色模型分析word精品文档10页.docx》由会员分享，可在线阅读，更多相关《产品经理必备用户角色模型分析word精品文档10页.docx（7页珍藏版）》请在冰点文库上搜索。

产品经理必备用户角色模型分析word精品文档10页

1.3用户角色模型

   很多项目的story给人感觉好像系统只有一种用户。

所有的story都从这种用户的角度来编写。

这种简化是错误的，它会导致团队遗漏那些非系统主要用户的用户需求。

用户为中心的交互设计（UCD）和迭代设计中都讲到过在写story之前首先识别用户角色的一些好处。

所以本章，我们将看看用户角色，角色模型，用户角色图，人物以及如何从角色建模做起,做出更好的story和更好的软件。

1.3.1用户角色[1]

[1]本章大部分关于用户角色的讨论都是基于LarryConstantineandLucyLockwood的工作。

更多关于用户角色模型的信息来自他们的网站foruse或者使用的软件。

    假设我们正在建设BigMoneyJobs（发布和查找工作）站点。

这种网站包括很多不同类型的用户。

当我们谈论userstory的时候，谁是我们谈论的用户呢？

Ashish，一个拥有一份工作,但一直都想寻找一份更好工作的用户么？

Laura，一个刚毕业正在寻找他的第一份专业工作的用户么？

还是Allan，一个已经决定找一个能让它去Maui（毛伊岛）并且可以每个下午都去冲浪的用户？

或者说是Scott，一个并不讨厌他的工作，但是意识到现在应该继续进步的用户？

当然也可能是Kindra，一个6个月前被再次解雇，正在寻找一个好工作，但是在英国东北部什么都没找到的用户。

   或者我们应该考虑某个公司发布职位的用户？

也许是负责人力资源并发布空缺职位的Mario，也许是同样负责人力资源但负责评审简历的Dalaney，或者是作为一个猎头同时查找好的工作和好的求职者的Savannah?

   显然，我们不可能只通过一种观点来编写story，让他来反映所有这些用户的经验、背景和目的。

Ashish，一个会计，可能每个月只登录一次网站，以保持视野开阔。

Allan，一个服务人员，可能想创建一个过滤条件，以便可以随时都能给他关于在Maui工作的通报，但是除非我们把这个功能做的很简单易用，否则，他不会这样用。

Kindra可能每天都会花费一些时间查找工作，随着时间推移，逐步扩大他的搜索。

如果Mario和Delaney在一个拥有很多空缺职位的大公司，他们一天可能会在网站上花费4个甚至更多的时间。

   即便每一个用户的背景和目的不同，仍然可以对单个用户进行组合并且用用户模型的方式来分析他们。

用户角色是被定义的一系列属性的集合，这些属性包括用户的特征以及他们和系统交互的目的。

所以，我们可以看看前面的例子，然后按表3.1方式将其组合成用户角色

  表3.1.BigMoneyJobs项目可能的用户角色列表

角色

人员

求职者

Scott

第一次访问者

Laura

失业者

Kindra

区域搜索者

Allan

监视者（浏览者）

Ashish

工作发布人员

Mario,Savannah

简历阅读人员

Delaney,Savannah

   通常，不同的用户角色会有一些重叠。

求职者, 首次访问者, 失业者, 区域搜索者, 和监控（浏览）角色都会使用网站进行职位查询。

他们可能使用的方法和频率不同，但是他们如何使用系统是相似的。

而简历阅读者和工作发布者，这两个角色在寻找好的求职者这一目的上是重叠的。

   表3.1并非是组合BigMoneyJobs用户的唯一方法。

例如，你可以选择像这样来组合：

临时工，全日制工作人员和和合同工。

在本章接下来的部分，我们将来看看如何使用一个角色列表，以及如何定义一个有用的列表。

1.3.2用户建模步骤

  我们建议通过以下步骤来创建有用的用户角色模型：

  集体讨论一个初始的用户角色设置

  对最初的设置进行组织

  巩固角色

  精炼角色

  以下将就每个步骤进行讨论。

1.3.2.1集体讨论初始的用户角色设置

   定义用户角色，客户和尽可能多的开发人员一起开会,会议室最好能有大桌子或墙让他们录音或贴卡片。

理想的状态是项目开始的时候所有的团队成员都来定义角色模型，但是这是没必要的。

只要客户和合适的开发人员代表出席会议,我们就能拥有成功的一课。

   每个参与者从桌子中间拿一堆卡片。

（即便你想把角色进行电子存储，你也应该从把它们写在卡片上开始），每个人都在卡片上写用户角色，然后把它们放在桌子上或粘到墙上。

   每当一个新的角色卡片被放下，作者只用说出新角色的名字，其他的任何都不需要。

因为这是一个头脑风暴会议，所以没有任何关于开篇或者角色评估的讨论。

每个人尽可能多的写下她能想到的角色，这些角色没有顺序的。

你不能绕着桌子去问新的角色。

每一个参与者只写下她所想到的新角色就可以。

   头脑风暴会议，房间会被沙沙的钢笔声音所填满，偶尔会有人放置一个新的卡片并读出角色的名字。

一直持续参与者需要花费很长的时间才能想到新的角色,那么过程结束。

这时候,你可能没有做任何的角色识别,但是你已经足够接近了.做这件事情的时间很少大于15分钟.

只有一个用户的用户角色

避免定义表面上看只有一个用户的角色。

例如，BigMoneyJobs项目中，可能会临时写下这样一个story“Acompanycanpostajobopening。

（公司可以发布空缺职位）”，但是，公司是无法使用软件的，这个story如果引用一个表示人的角色的话会更好。

1.3.2.2对确定的用户角色进行组织

   一旦定义好了角色，就该组织角色了。

组织的时候，卡片在桌上或墙上被移动，以便他们的位置能够表示角色之间的关系。

重复的角色，他们的卡片也重叠着放置。

如果角色只重复一小部分，那卡片也就重叠一小部分。

如果角色完全重复，则卡片也完全重叠。

例如Figure3.1:

Figure3.1. 在一个桌子上组织用户角色.

    Figure3.1 说明应届生和非应届生在角色上是明显重叠的。

其他表示将会使用网站查询工作的人的卡片也是类似的相互重叠，但是重叠相对来说少一些。

Monitor（监控者）角色卡片跟其他的只有很少量重叠，因为这种角色表示那些目前工作比较满意，但是喜欢保持关注的人。

   Figure3.1中真正要查找工作的角色是工作发布者（JobPoster）, 招聘人员（Recruiter）, 和简历阅读人员（ResumeReader）这些角色。

这些角色是完全重叠的，因为招聘人员即要发布广告又要阅读简历。

另外,图中还显示了一个管理员角色。

这个角色表示BigMoneyJobs网站内部系统支持人员。

系统角色

尽你所能的, 保持用户角色是对人的定义和归并，而不是其他系统。

如果你觉得有帮助，那就定义一些非人的用户角色. 但是,定义用户角色的目的是保证新系统能够完全、一定让我们辛苦想出来的客户满意。

我们不需要所有系统可能的用户角色，但是我们需要能够导致系统成功或失败的客户角色。

既然其他系统很少买我们的系统，他们也很少能左右系统的成功或失败。

自然的, 也有例外，如果你觉得添加一个非人的用户角色能够帮助你的系统更好实现，那就添加吧。

1.3.2.3巩固角色

   组合完这些角色后，尝试去进行角色的巩固和精简。

从完全重叠的开始，重叠卡片的提出者阐述他们角色的意思。

简短的讨论后确定两个角色是否完全相同。

如果完全相同，合并成一个单独的角色，或者扔掉某一个最初的角色卡片。

   在Figure3.1中，毕业生和第一次工作查找者这两个角色很大部分是重合的。

团队决定丢弃毕业生这个角色，因为这个角色的所有story和第一次工作查找者的story都是一样的。

甚至第一次工作查找者、失业者、区域查找者和求职者都有很大的重叠,thegroupdecidesthateachrepresentsaconstituencythatwillbeimportanttosatisfyandtheroleswillhaveimportantbutsubtlydifferentgoalsforhowtheyusetheBigMoneyJobswebsite.

   当看Figure3.1右半部分的时候，团队发现工作发布人员和简历阅读人员是不值得区分的。

他们决定使用招聘人员完全概括这两个角色，丢弃原有的两个角色。

但是，团队决定内部招聘人员 （为某一特定公司工作） 和外部招聘人员 （为任何一家公司的职位寻找合适的求职者，译者理解为猎头）之间是有区别。

他们为内部招聘人员和外部招聘人员创建了个新的卡片，并将它作为替代招聘人员角色的一个版本。

   另外一个巩固角色所要做的就是抛弃任何对项目能否成功来说不重要的角色。

例如，监控（浏览）者角色，他可能3年都不换一次工作，BigMoneyJobs就算不关注这些人也可以做的很好。

他们认为把注意力集中到对公司成功非常重要的角色上会更好，比如求职者和招聘人员。

   团队巩固了这些卡片以后，他们在桌子上或墙上展示角色之间的关系。

Figure3.2展示了一种BigMoneyJobs的层次。

普通角色，例如求职者或者招聘人员，放置在特殊角色之上。

选择性的，卡片可以被堆放，也可以其他方式放置，团队可能会认为其他某种方式可以展示角色间的重要关系。

   Figure3.2. 经过整理的用户角色卡.

1.3.2.4精炼角色

   一旦我们已经巩固了角色并且对角色间的关系有了基本的了解，就可以通过定义每个角色的属性来模拟这些用户。

角色属性是一个事实或者一块关于角色中的用户有用信息。

任何关于用户角色的信息都可以当作区别于其他角色的属性。

准备角色模型的时候可参考下面的属性进行分析：

  用户使用软件的频率

  用户的业务经验水平

  用户在计算机和软件方面的平均水平.

  用户对开发软件的熟练程度

  用户使用软件的目的，某些用户为了方便，其他用户喜欢丰富的体验，

等等。

  除了这些你构建软件过程中需要考虑的标准属性外，你还需要看是否有其他的对描述用户有用的属性。

例如，对BigMoneyJobs来说，你可能需要考虑用户角色是否会查找兼职的或全职的工作。

  当你为角色定义了有意思的属性，把他写到卡片的背面。

完成以后，你就可以在一个团队的公共区域悬挂角色卡片好让他们提醒开发人员，Figure3.3展示了一个简单的角色卡片。

  Figure3.3. 一个简单的用户角色卡片.

 用户角色：

内部招聘人员

非深谙计算机的电脑使用者但是非常习惯使用web界面。

使用软件不是很频繁但是强烈需要。

他将需要阅读其他公司的广告，以便最好的组织他的广告语言。

易用性是很重要的，但是更重要的是她学会的东西必须在数月后还能很容易的想起来。

“用户访谈”提问指导——白鸦

#在场时完成某项任务的过程中请尽量不要打断被访者。

#尽量避免使用诱导性的问题。

如“您认为这样有用吗？

”或“这样做您还是挺喜欢的，对吧？

”

#尽量使用开放式问题。

如“能告诉我们现在您在做什么吗？

”而不是“为什么您会这么做？

”

#避免打断或试图帮助被访者。

#避免在解释某些内容时让被访者感觉他们是无知的。

如“其实您只要点一下这里就可以了。

”

#避免使用专业词汇：

请使用被访者习惯的词汇。

#请记住访问的目的：

从被访者的角度来了解沟通工具的作用。

#请记住：

你是学生，被访者才是专家。

#学会如何来解释/了解被访者的想法。

#问自己从观察中学到了什么及如何向他人解释所学习到的内容。

#向被访者学习如何来解释/阐述他们的行为，这一点也与座谈会和探访有所不同。

#访问过程可能会与你准备的问题纲要有偏差，你需要更多的准备。

#即便你能流利地使用被访者的语言来进行沟通，如果你当时有翻译在场，也请通过翻译来提问。

#这句话大部分时候需要说：

访谈的目的只是为了了解被访者的需求及该产品如何能更好的满足使用者的需求，而不是对被访者进行评估。

希望以上资料对你有所帮助，附励志名言3条：

：

1、世事忙忙如水流，休将名利挂心头。

粗茶淡饭随缘过，富贵荣华莫强求。

2、“我欲”是贫穷的标志。

事能常足，心常惬，人到无求品自高。

3、人生至恶是善谈人过；人生至愚恶闻己过。