UML软件工程组织

 

 

ASK ME,产品设计的评测
 

2008-03-03 作者:白鸦 来源: ucdchina.com

 

上周去北师大、北邮、北理工三所高校作了题为“我的UCD思考”的小演讲(10.1以后还可能会去北大)。在学校里和大家的交流很有收获,让我对于国内UCD行业未来的发展和良好的人才储备更加充满期望。
回顾在三所高校中同学们提到的问题,结合我最近收到的一些咨询邮件,总结几个关于“产品设计和评估”的常见问题如下:

问题一,产品设计到了什么阶段才可以开始测试?是不是最早也要到有了高保真的界面原型才能开始测试?

1、这个说法是不对的,产品设计的任何阶段都可以进行测试,只要条件允许也都应该进行测试;

2、什么时候进行测试,其实取决于你对于产品有什么样的问题,只要你有问题都应该去做;

3、具体说一个例子:你现在要设计一个IM软件,和QQ基本相似;

那么,哪怕是在你的产品设计之初,只有简单想法还没有任何具体界面设计的时候,如果你有拿不准的问题一样可以通过测试解决。

你可能会问“我什么都没有,拿什么去测?”。“拿QQ呗”;

再往后,“纸原型”、“可简单演示的低保真原型”、“可互动的高保真原型”、“beta版本”都可以去做。

4、补充一下:我说到的“测试”不局限于“找用户来作”,一样包括“访谈”和自己的“评估”。

问题二,我们现在没有完善的“可用性实验室”,没有好的环境如何客服测试的问题?测试中您认为关键的问题有那些?

1、首先,产品的测试和评估并非一定要在实验室进行。测试应该是随时随地的,作为一个设计师必须要具备随时随地观察相关用户使用过程的“习惯”,这也是一种测试。

2、不得不说很多“科学”仪器和实验室“装备”都是极其“科学”的,但是否实用?甚至说是否有用?我持反对观点。

3、我个人认为作产品测试最关键的点有5点:测试的准备、测试的方法、被测的人、测试的人、测试的环境;

所谓“测试的准备”主要指“明确测试的目的性”和“准备测试的问题”。往往我们很容易搞清楚自己“为什么测试”,目的性都不是什么大问题;

但,“测试之前没有充分准备‘问题’测试中随机应变,导致测试结果大多没有什么价值”,这是大多数“经验丰富”之人常犯的错误,所以我建议:“在整个测试项目中,用50%的时间去做准备工作”;
然后,如何准备问题也是非常重要的。比如,一个关于语音搜索的产品测试,可以“从以往用户的录音中提炼问题来测试”而不要用“给话务员培训的对答脚本”来测试;

还有,某领导往往喜欢用自己遇到的问题去测试,当我提到“这不一定是用户的问题”时,领导反倒理直气壮的告诉我“我就是用户呀”,我只能回答他:“在咱们自己的产品面前您只能是领导,不是用户”…

关于“测试的方法”这个其实很简单,相信大多数科班出身的人都能很好的掌握。我只想不中听的提醒纯“心理学”专业的同学:站在“产品设计”的角度测试,而非纯粹的“心里测试”角度测试。
这么说只是因为我遇到不少“心理学”专业的朋友,他们给了我这种感觉,导致一些测试结果对于“产品”本身的直接意义很小。(并非说完全没有作用)

被测的人”指“如何明确自己产品的针对性用户群,如何找到准确的典型用户”。这些都是我们成天提到的东西,无需我来讲;

往往“如何让被测者很好的与系统和测试者进行交互”其实是最大的课题,当你遇到一个“死活不说话、测试过程紧张无比”怎么都无法从他那里得到有效信息的被测者时,“暂时把话题扯开谈谈轻松的事情、聊聊家长、说说他喜欢的话题、甚至讲讲小笑话”都会是不错的做法。。。

测试的人”我就不说了,只有一个建议:测试的人和总结测试报告的人要是同一人。

测试的环境”是我最想强调的,这也是我个人一直不支持“在实验室”里测试的主要原因之一;我见过很多实验室设计的太“不自然”了(设计合理的实验室倒还好),用户在测试中根本没有平时使用的感觉;
我个人一般比较支持“低成本”的更加自然的测试环境,尽量不要改变用户平时用户的环境,只作为一个让他没有感觉到的“旁观者”或者“偷窥者”更合适。

还比如,测试一个语音搜索产品的话务员操作系统,“把话务员“关”到严肃的实验室用个大摄像头对着他,自己龟缩在单面玻璃后面”的“科学”方式,还不如“去话务员工作的地方,把话务员的显示器切为双屏显示,通过另外的耳机旁听话务员正常工作”效果更好。

问题三,在应用用户测试的结果上能不能给我们一些建议?

wow!这个问题比较大,很多理论性的做法已经很多地方可以看到相关资料了。我想说点主要的:

1、首先,再强调一下“测试和评估之前的准备工作十分重要”,往往我们的测试可能有两种情况──

第一种:你设计了两个杯子,你认为第一个设计比第二个设计好,你需要通过测试来验证你的观点;

第二种:你设计了两个杯子,你不知道那一个更好,你需要通过测试来得到答案;

如果你明确了你的目的,然后又做了充分的准备,我想“提炼结果”应该不是大问题。

2、不是所有用户说的都是对的,以用户为中心不等于“用户怎么说就怎么作”。

我见过一个人,测试中用户说“我觉得这个地方全部展开不好,太占空间了,应该收缩到下拉菜单里”,用户一走他马上就心花怒放的去改了。问他为什么?他告诉我:“这是用户说的”!

第二天又测试了一个用户,这个用户说“这个地方其实很重要,收缩起来可能找不到,你应该给展开”。他晕了,问我“怎么办?”,我回答他:“我不是用户,”。

3、其实我想说:“把用户的测试当作意见来源,而非指示来源。

既然是意见就需要‘筛选’”,“提炼用户研究的结果最关键还是你自己的思考和辨别能力”,这种能力只能靠“你比任何人都更深入理解产品和用户”。同我回答“如何做好搜索引擎的用户研究?”一样:最基础的还是“至少每天搜索200个字以上”。

问题四,“专家评估”是不是就是站在产品专家的角度去使用产品,然后总结出来设计的问题?

和我们作启发式评估不同,启发式评估往往完全可以对产品没有任何了解,就只是用户的角度去作即可;但专家评估往往是站在专家的角度“用用户的模式思考”。

我个人一直比较主张:“专家评估”之前一定要熟悉“产品架构和业务流程”,因为你提出的不应该只是“用户的问题”,还得包含“产品的因素”,这样才能很好的直接应用。

专家评估的问题总结需要有技巧性,尽量要让问题的表现更加明了而且要出来修正的办法。我自己往往会用PPT的方式,先把问题分类然后再展示问题表现、问题分析、危险程度、修正办法等

问题五,当数据统计和用户访谈结果出现不一致时,应该怎么选择?

呵呵,这个问题听起来比较棘手;

1、首先我建议你去找一找数据统计或用户访谈在什么地方出错了;

2、我向来认为“数据”和“用户”是两个互相依赖的部分,数据是支撑用户结果的依据,用户可以找到数据现象发生的缘由;

3、往往我们只看数据不知道“这是为什么”,这个时候我们需要通过和用户的接触去了解数据现象背后的原因;如果只靠数据就下一个背后原因的结论,大多数时候是很危险的;

4、往往我们只根据用户反应的情况,就去作一个大改动也是不合适的,因为他可能是片面的,这个时候我们需要用数据去论证他。

最后,总结一下:

1、产品的任何阶段都可以进行测试,无需等待完整的设计完成之后;

2、测试和评估是随时随地的;

3、不一定在实验室的测试和评估就更好,我个人比较排斥那种“不自然”的方式;

4、把“数据”和“用户”相结合很重要;

5、作专门测试项目时,拿出50%的时间作准备工作;

6、测试的目的:验证观点或者得到观点;

7、读懂数据和提炼用户测试结果的基础是:深入理解自己的产品和用户。

 

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

京公海网安备110108001071号