产品设计体会(1006)可用性测试

可用性测试也是用户研究/需求采集的一个常用方法,从理念上讲就是:让产品的最终使用者(end user)尽可能多的参与到产品设计的各个环节中去,深入一点就很2.0了——“UGC,用户创造内容”(这也不是什么新概念,传统行业的宜家IKEA早在50年前就有所行动,让用户参与到产品的设计),把用户参与扩展开,还可以包括前期调研、demo评审等等。

而可用性测试是在产品成型但尚未发布的时候进行,效果往往无法量化,所以经常因为项目时间过紧被略过,好不容易2008年春有了一些空闲,正好手头产品的部分模块是给阿里内部人员使用的,所以就很低成本的执行了一次可用性测试。

最最轻量级的,表现为:一个人,半个小时,在我的座位上,结果提出了15个左右的问题,效率很高。

讲几点要注意的地方。

可用性测试开始之前,要邀请用户来做tester,不要给tester看到“可用性测试”的术语,而是说“来试用一下我们的新产品,提点意见”,一定不要让用户误以为是我们拿着新产品测试他,而是我们和他一起测试新产品。告知大概持续的时间,给一点产品的背景知识,测试内容是做哪些事情完成哪些任务,让tester心中有数。

做测试的过程中千万不要引导,而只是观察和记录,用户行为和预想的不一样的时候,提问,进行不下去的时候,给与提示。记住一切的错都是产品和我们的错,用户绝对没有错。如果真觉得用户错了,那也是你找错人了,不是这个人错了,:)

结束之后,如有可能应该送个小礼品,但这次内部的就免了呵呵。尽快的总结,发给tester,一方面让tester感到他起到了作用,另一方面也是表示感谢,建立长期和谐的“用户参与产品设计”的氛围。最重要的,这分总结要用于指导产品改进,这才是可用性测试的根本目的。

有兴趣的继续去搜搜:《进行可用性测试的8个指南》、《了解可用测试》。

------------------------------------------------------------如果你想第一时间看到最新内容, 就猛击此处订阅吧!

《产品设计体会(1006)可用性测试》有4个想法

  1. 初步看了你的用户需求篇中的1001-1006,感觉如下:
    1.在引用别人文字时,要注意版权问题,这个在国外的书籍中特别有体现,就像写论文一样,要写明出处。
    2.分析一个知识点的时候,没有讲透讲深,如“可有行测试”“需求探针”,感觉都只是点到为止。也许你自己知道来龙去脉,但是我们看了云里雾里,没有头绪也没有实际的借鉴意义。而且,在阐述时,只从自身出发,不够全面,借鉴意义就又少了几分,是否可以考虑在观察了其他人对同一件事情的看法和实践后的感触,整合进来,更加的深入。(感觉,没有厚积,火候还差了些。抱歉,讲的不是非常礼貌,完全是自己的感觉)
    3.在整文的架构以及每一个小点的架构上,还比较随意,没有形成一个提出问题/发现问题/解决问题,以及是什么/为什么/怎么做(最重要的是怎么做)这样的成熟性的框架。我前面推荐过的那本《社会心理学》,我看了的感觉就是人家的框架很到位,举例说,人家的基本框架是:1,提出问题,让你思考,2.拿出例证,让你感觉,3,分析各类观点,让你深入,4,总结陈词,让你回顾。(没有具体分析过书本的写作结构,但是很合我看书的感觉)。要“说服”人家同意你的观点,最重要的是让对方产生一种兴趣,这种兴趣是指愿意对你说的事情做出回应。所以写出来的东西要引导人家去进行思考,让其有思考的动机和能力。
    这是初步感觉,后续有什么意见,再具体分析。

    iamsujie Reply:

    @waterfisher, 非常感谢,非常认同,我还有很长的路要走,如果说我打算做这行3、40年的话,毕竟现在才走到1/10,呵呵,只要方向没错就好。
    这里的很多文章,只是我的工作周报,写的时候确实没想那么多。

  2. 看到waterfisher在09年的评论,感觉可能当时他或许之前没有做过这方面工作,因为感觉做过的都会有些许的共鸣和同感,以及自己可能在当时做的的确没有像苏杰总结的这样–想的那么深,当然也或许是自己唐突了,感觉苏杰很谦虚 [强]

发表评论

电子邮件地址不会被公开。 必填项已用*标注