UML软件工程组织

 

 

我要如何了解“她”
 
2008-03-07 作者:Angela 来源:ucdchina.com
 

上回我们讨论UE在团队中的作用,有一点大家已经达成共识,那就是用户是所有体验的基础,如果用户的要求没被满足,良好的体验自然也无从说起。那么,我们怎样才能了解用户需求呢?

大家都知道可用性测试、调查问卷之类与用户进行沟通的途径,这些方法各有各的利弊,如果逐一分析的话,恐怕至少要分成三本书来写。现在我们先把它们放在一边,从另一个角度来看看这个问题:用户的需求会通过什么途径来表达呢?

举个小小的例子,某位小朋友饿了,他可能会说“我要吃点东西”,然后你就知道应该给他找点吃的;如果他什么都不说,抓起某样食物就狂吃,这很明显——他饿了;要是他说“我想吃火锅”,而你没有火锅只有馒头呢?我们稍后再说明这个问题。

不过你至少可以看出,用户的需求通过这样三种形式来传达——目标、行为、说法。

在这个例子中,用户最根本的需求是饥饿(我们通常不需要了解用户最根本的需求),目标是找东西吃下去,行为显示了这个目标,他自己认为火锅能解决这个问题。我们要做的,就是根据这些资料提供给他适合的食物。这里我们提供的是馒头,小朋友看到馒头的时候,有两种可能,一种是什么也不说,抓过来就狂啃;另一种是一边狂啃一边生气。第一种情况说明,你提供给他的选择比他想象的更实用。同时说明:用户所说的其实不一定就是他们真正的需求,行为才是最真实的。第二种情况说明,你对用户的需求了解得不够,需要再收集更多的数据,比如他爱吃米饭还是面食,喜欢甜还是辣等。

当然大多数研究比这个例子要复杂得多,但总的说来,我们除了要知道用户有什么行为,还必须知道为什么会出现这样的行为。所以必须要将各种方法综合起来使用,然后描述出一个完整的用户形象。

用户需求的组成就如下面这个图形所示。为什么“行为”占了一半的比重呢?我个人认为,受中国文化的含蓄和中庸哲学影响,国内用户恐怕很少能真诚、准确地说出自己的想法,所以应该在行为研究上有所偏重。
User’s needs

我们先不考虑如何分析数据,现在只需要想:有哪些方法可以收集到这些数据呢?看下面这个图:
User’s needs

正如你看到的,网站流量和日志文件,以及被大家交口称赞的眼动实验用于了解用户做了什么(行为),而用户访谈和调查问卷用于了解用户为什么这么做(目标和说法),情景调查、可用性测试和CRM统计则介于目标和行为之间。

首先说一下用户访谈和调查问卷。

这两者看起来很相似,都是提出一堆问题让用户来回答。但它们之间有个关键的差异:数量。用户访谈是抽样调查,数量少(每种类型的用户不超过10个),而调查问卷则是一种大范围内的普查。数量的不同决定了两种方法的性质,一种是定性的研究方式,另一种则是定量的研究方式。不过它们用于发现用户的观点是非常有用的,你往往会在用户的答复中,发现你之前根本就没考虑过的新想法,这也许就会改变你的产品的思路。

两者在运作的形式上也有所差异。用户访谈的形式是一种更加随意的谈话方式,而且要注意尽量不要提“是非题”(即“是”或“否”的问题),让用户自由表达。你可以事先有一个大纲,但一定不要照本宣科。在时间上也要保持一定的弹性,一般你会告诉用户需要1个小时,不过要是遇上一个善谈的用户,滔滔不绝讲1个半小时也是有可能的,你要做的,就是尽量别让他跑得太远:)。调查问卷则更严谨一点,不管是在网上还是线下进行的调查,大部分都应该是量级选择题,我们通常看到的“你是否同意这个说法,5分非常同意,0分完全不同意”,就属于这种问题,用户可以通过点击和画勾来回答。调查问卷同样也要避免“是非题”,同时为了保证用户不会因为耗时太长而放弃,最好自己测试一下答题时间,一般不能超过15分钟(我回答过超过20分钟的问题,不过那是几个心理测试)。

这里我只想强调一点,不管哪种方法,提问的技巧和问题的顺序相当的重要。如果你在一开始就告诉用户,你们准备开发几个新功能,后面又问到用户对现有产品的想法,这就是一种典型自我否定,势必会影响到用户对后一个问题的看法。我想这就是需要心理专家发挥作用的环节。挖掘人类心底的想法,从来都是一件斗智斗勇的事。在某种程度上这种沟通过程更像是你和你身边那个女孩相处的情形。你一直想弄明白她为什么不高兴,但是又不能直接问,因为你知道,她永远不会直接回答。你唯一能做的就是长叹一声“我要如何了解她?!”。可能她只是因为你没有穿她送的那件衬衣而生气,但她只会说:“你今天打扮得真没品味。”表现出来的行为就是不跟你去任何公众场合,目标就是⋯⋯你自己分析吧。

网站流量统计、日志文件用于了解用户做了什么,但通常不能解释他们为什么这么做,与之相似的还有CRM数据。所以这三者最好是能和调查问卷结合起来使用。 把某个用户的点击流(clickstream)与他完成的调查问卷放到一起分析,你就能了解这个行为背后的原因。当然,前提是您可以捕获某个特定用户的日志记录,并在调查问卷中找到同一个人的回复。大部分的网页里都埋有统计程序的种子,作用和我们今天的主题一样,只管尽可能多地收集数据。而在统计背后的数据挖掘,更是一场艰苦而长期的工作。

可用性测试和眼动实验本质上相同的,它们的局限很明显,只能用于发现已有产品的缺陷和障碍,而这同样可以用其它途径得到。所以在国内炒得沸沸扬扬的可用性测试,我个人认为对互联网产品似乎并不能产生太大的影响。这一节就跳过。

情景调查很有意思,组合了用户访谈和可用性测试两者的方式。简单说就是你跑到用户那儿去,看看他们在熟悉的环境下如何进行操作的,这样你得到的数据就比在实验室要真实得多,对于某些和环境有关的产品而言,进行实地考察是非常重要的。进行情景调查你可以突然袭击(偷窥)或者提前和用户说好。不过一般来讲,在用户不知情的情况下你能看到更多的东西,虽然听起来似乎有点不够君子。调查一开始,你一边观察用户的行为,一边记下有疑问的地方,这算是改良版的可用性测试。等用户完成他的日常工作,你就可以现身出来,邀请用户进行一次简短的访问,把你刚才的疑问一一提出,这又是一次简化版的用户访谈。这个方法的风险就是用户可能不愿意,或者没有时间接受你的采访。

以上就是常用的一些用户研究方法,有部分例子参考了我有史以来读得最认真的一本书《The User is Always Right》(就像你的女朋友总是对的一样),而“用户总是对的”正是UCD(以用户为中心的设计)所倡导并坚持的。

 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号