丁宇 | DING Yu

User Friendly 2008第二、三天印象

第一天的印象和笔记见这里

量化和评估用户体验

在这次的UF2008大会上,我不止一次听到了有人提到量化用户体验的重要性,如黄峰在他的主题演讲中,强调在每一个版本发布前后,要通过数据对结果进行对比衡量;再如Sarah在其“如何将用户体验带入一个IT企业”的工作坊中,指出“UI设计是主观、不可衡量”是“一些管理人员常见的错误认识”。这些实际上是和我的观点相一致的,在我总结整理的用户体验框架中,清晰、明确、可衡量的目标是重中之重,也是后续所有工作的目标和基础。

借着这次大会的机会,我把我的用户体验框架和一些朋友做了分享,正面和负面的评价都有,我自己收获也不少,这里不妨简要介绍一下:

这个框架的想法来源于两个方面,一是用户体验设计在目前并没有一套通用的方法和流程,一些人有自己的一套做法,另外一些人则尚在摸索。即使是同一个公司内,每个人的做事方式可能也不同,这样的现状不仅给刚入行的设计师带来困惑,使他们不知从何入手,也造成其他设计师之间口径的不一致,以致提高了沟通成本。另一方面,是与用户体验设计一墙之隔的程序开发,却有着非常成熟的流程、方法和工具,在程序设计中,框架的使用可以极大地提高工作效率,减少各种成本,并提供了非次高的统一性和扩展性,那为什么不把这种框架的思想引入到用户体验设计中来呢?

正是基于上述两点考虑,我才于年初提出了“用户体验架构”的概念,经过差不多一年的发展,我将“用户体验架构”一分为二:

1. 框架。用于给单个设计师提供一个类似于程序开发中的、标准化的流程和工具,设计师可以按照框架中定义的流程、使用其中的方法来进行工作。这一框架包括1)定义清晰、明确并可量化的商业需求;2)实施用户研究;3)定义清晰、明确并可量化的用户体验需求;4)编写设计规范,提供设计工具;5)实施TDD(测试驱动设计);6)用户体验评估等六个部分。具体内容不在这里展开,不过我相信标题已经有很大的自明性了。从朋友们初步的反馈来看,这个框架还算不错,达到了我的预期。

2. 分工。我明确反对过细的分工,这个提过好几次了,这里不再赘述。

第二天下午

用户研究的价值

“以用户为中心”就要去做用户研究,搞明白用户及其需求,才是做出好设计的一个基础。很多时候,用户研究做好了,解决问题的办法自然而然也就出来了。UF2008大会上有好多场主题演讲都是关于用户研究的,虽然内容都不是很深入,但非常好地强调了研究的重要性。

回想一下自己写过的几篇相关文章,有讲虚拟社区中用户行为的“An Automated Tool for Managing Interactions in Virtual Communities”有讲问卷设计的“可用性测试中常用的问卷量表”,有用于信息架构的“卡片分类测试实施攻略”,有关于用户访谈的“绝望主持人”系列(第一季第二季第三季)等等。

我在酒店

亚洲(东亚、南亚)用户的特点

来自印度埃森哲的Sushmita Munshi给我们做了一次非常精彩的演讲,题目为“ 亚洲青年:重新定义用户研究和设计去满足亚洲最大的目标用户群即青年正在不断改变的习惯和期望”。嗯,她的题目能把读者憋死,但侥幸活下来的话,就能听到非常有趣的内容。我听下来她的演讲主要包含了两个部分,一是亚洲青年用户的特点,她所谓的青年指的是1980年至1989年出生的这一代人,Sushmita精辟地总结了这一代人所拥有的一些特点,如独生子女、大量受到美国文化的影响等等;二是如何如何针对这些用户的特点作研究。

期间她提到说如果用户为年轻的女性,那么采用男性主持人是不合适的做法,可她没有解释原因。于是我脱口而出:“why(为什么)”?坐我旁边的是Infosys的设计副总裁Sridhar Marri,他听到后大笑不止,说:“they will love him(怕她们爱上他)”,果然猥琐。

UPA举行的晚宴

在企业文化基础上推广和实施用户体验活动

这是听Sarah Bloomer的那场“如何将用户体验带入一个IT企业”学到的内容。她的意思是,你得判断所在企业的风格和文化是什么,是技术型?设计型?还是市场型?对于市场型公司来说,设计师的专业能力并不是首当其冲要考虑的,而能否和市场及销售部门有效沟通、能否使这些业务部门相信甚至理解可用性才是最重要的。我对此深表赞同。国内成功的技术型互联网公司很少,而在大部分的市场型公司中,可用性的推广和地位又多少成问题,Sarah的观点对此很有借鉴意义。

敏捷方法

敏捷开发越来越流行和普遍,在这种情况下实施用户体验设计和以往有什么不同,是个值得引起注意的问题。在Sarah的讲座中,她花了相当大的篇幅来讨论敏捷,可惜我敏捷的实践经验少得可怜,只记得她采取换人的方式来避免精疲力尽(burnout)比较有意思。

此外,我当时问了个关于敏捷开发中UI规范的问题,她的答复有些自相矛盾,她说应成立一个单独的小组用于制定各种规范和工具,但另一方面她自己也提到说敏捷的一大特点就是没有文档,因此这两种做法实际上是冲突的。

 

已经是深夜了,先写这么多吧。


  1. taine @ 2008-10-30 00:56:39 +0800:

    第一天下午吧。

  2. 丁宇 @ 2008-10-30 06:44:37 +0800:

    @taine: 果然是你看得仔细,已修改 :)

  3. Ami @ 2008-10-30 18:39:09 +0800:

    同在上海从事用户体验相关工作,几次UPA也都去了,但貌似一直没有和心弦见面和交流过。欢迎有空来参加上海的UCD书友会,同行多交流:)

  4. 百纯 @ 2009-03-04 21:46:05 +0800:

    敏捷并非不需要文档,而是只写必要的文档。

    敏捷,在小团队内强调面对面的沟通,降低文档在沟通方面的作用,减少文档编写的工作量。