优界网

首页 > 产品经理 > 用研无用?——对用户研究实践的思考

用研无用?——对用户研究实践的思考

29

0

0

2016-05-23 00:01:25

金龙

分享一下,又不会怀孕!

本作品为转载作品,版权为作品原作者所有,感谢上传者的分享!

从毕业实习算起,从事可用性方面的工作到现在已经5年了。在此记录笔者的一些所见所想,和大家讨论分享一下。

用户研究在“以用户为中心”的界面设计方法中是很基础,也很关键的一个环节。但在实践中,笔者经常听到的抱怨是“用户研究投入多,耗时长,还没用”。出现这种声音的原因肯定是多方面的,在此笔者想从以下四个方面探讨。

从业人员素质低?

有人说,目前可用性从业人员素质低,所以他们做的研究不够有水准,影响了行业外对本行业的看法。这个提法笔者认同,但暂时不作讨论。目前有不少从业人员的调查报告可读,对从业人员的学历背景等有较详细的描述。举个最简单的例子, 2009年,公司高层领导发出的邮件中曾写到“所有的设计师都要写一些HTML,CSS,甚至PHP。” 西安交通大学李乐山教授也曾经说过,做人机界面设计要会写代码。而笔者自己就只会最简单的HTML,这个基本要求达不到。

用户研究的商业价值不易估量?

还有人说,用户调查的商业价值不易估量,因此用研的价值不容易体现出来。对此笔者不同意。不做用户调查,商业价值会更高吗?这是走历史回头路。过去计算机硬件和软件发展的50多年,就是在不断汲取历史教训中走到今天这一步。一些问题被解决后,人们往往感觉不到有什么进步——就像大家已经习惯了使用鼠标,感受不到和只使用键盘相比,人机交互方式发生了多大改变——如果某一个步骤让用户多花1分钟,每天几千万人使用这个软件,要浪费多少时间?使用互联网产品,要浪费多少带宽,浪费多少服务器资源?返回50年就明白是怎么一回事了。欢迎大家来谈论这个问题。其次,难以估量其创造价值的思想和方法并非只有用户调查,比如,还有企业文化,品牌建设。我们很难精确估算出企业文化能为企业创造多少价值。就算在市场研究领域,以品牌价值评估为例,就有不少模型,并且还在不断发展模型,但这“难以估计价值”的品牌建设也仍然不断在建立项目,且不断被实际应用。

敏捷开发对用研带来影响

第三个问题,是软件开发领域,笔者认为“敏捷开发”理念的提出和采用给用户研究实践带来了一些影响。

图1:敏捷开发(来源:http://wiki.mbalib.com/wiki/%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91 )

08年夏,西安交通大学李乐山教授给腾讯设计师培训的时候说:“我们前头搞用户调查,是为了建用户模型,用户模型建出来目的是帮助撰写设计指南供软件开发人员参考。从事的软件开发的很多人员他是不了解用户的,但是他要根据你写的设计指南,将所有的用户需求都涵盖在内。你如果漏了一条,他就可能漏了一个结构,一个功能。这个样子到最后,软件整个都失效了,没有用了。”

这种情况很容易发生在采用“瀑布式”开发流程的软件开发项目。从设计到制定产品特性,到开发,到测试,环环相扣,一步不慎,满盘皆输。2001年, “敏捷开发”的概念被提出来。目前在腾讯,越来越多的产品开发开始采用“迭代式”开发流程。据了解,其他互联网公司也在采用。这种“迭代式”开发的主要做法是:整个产品开发的过程是一系列不断的迭代过程;固定发布时间,发布速度快,有些互联网产品每半月发出一个版本,每次提供一些新产品特性;灰度放量,小部分用户先试用,然后搜集这部分用户反馈意见,快速修改版本,然后再大规模发布产品。

这种“敏捷开发”对用户调查和设计带来的主要影响是:产品发布速度快了,但调查从立项开始,执行分析,都需要花费大量时间,经常赶不上版本发布的节奏;通过灰度放量,可以通过用户的实际使用产品后的反馈了解用户情况,而不用依赖于前期大量分析工作预测用户使用新特性的情况;架构灵活,修改代码的成本低,允许开发出错,不依赖前期调查结果做指南。

从本质上来讲,“敏捷开发”和用户调查并不对立。在中国大力推行敏捷开发流程的咨询公司ThoughtWorks写到: “敏捷思想核心是人的交流。需求问题实际上是个交流问题。商务分析师要和客户交流搞清楚客户到底需要什么,到底为什么需要这些东西?商业价值是商务分析师关注的最终目标,有了目标指向就可以不迷失方向。和客户进行交流的最终目就是挖掘出客户商业目标。可能大家会经常有这样经验——客户说我要这个功能,我想要如何如何样,这时候要特别注意他说这些东西可能并不是真正需求,商务分析师需要详细问客户为什么,挖掘出他真正目标。”典型敏捷过程模型中的一种叫极限编程(Extreme Programming),是通过故事卡(Story Card)来管理需求。这种故事卡几乎可以说是情景分析,任务分析的另外一种表现。“敏捷开发”并不是不再关注用户,而是从不断从试错中获得用户反馈,从而改进产品,其实是“以用户为中心”的另一种表现。

图2:故事卡(来源:http://www.scissor.com/resources/teamroom/ )

由此看来,“敏捷开发”本身对于程序员来说是“以人为本”的,因为它允许程序员犯错,强调开发者之间的沟通交流,甚至鼓励程序员与用户交流,希望把机械的编程变成愉快的活动。

所以界面设计师对“敏捷开发”的态度不应该是抵触的,应该寻找解决方案。这个问题笔者所在团队正在尝试通过工具和流程来解决——

我们通过工具来缩短调查时间。用户访谈中,邀请用户、做记录和写分析报告是很花时间的。对此,笔者团队正在建立自愿接受访问的用户数据库,未来有需要时从中随时抽取用户;在调研过程中邀请项目组成员包括开发、设计师、产品经理一同来访问和观察用户,第一时间分享有用资料,减少文档写作,只写必要文档。问卷调查中,制作问题是很花时间的,公司内部专门开发了问卷制作和投放系统,从制作到投向用户最快几个小时内就能完成(不包括设计问卷)。数据分析阶段,使用SPSS分析时,将常用分析代码整理出来,下次统计分析可以继续使用,减少分析时间。通过使用工具,缩短调查本身的执行时间。最近团队中一个调查员接到需求,调查盲人对产品的意见,从接到需求到找盲人到访问到出报告,用了一周,其间还同时在进行其他项目,完成这个访谈项目只用了3个工作日。

我们通过流程来解决长时间调查与敏捷流程的矛盾:一次用户调查的结果可以写成许多“故事卡”,每次开发,只开发其中一部分“故事卡”,通过几次迭代开发周期,才完成一次调查的“故事卡”的开发,这个期间,可以继续进行新的用户调查。

此外,最终还是需要对用户使用所产生的后台数据进行分析,这仍然可以是负责设计调查的调查人进行的工作。

好“借鉴”,轻调研

第四个问题,比较本质,是由于国内企业喜欢“模仿”,或者说“借鉴”。

“借鉴”问题,会对用户调查造成很大影响。有些团队不愿意投入在调查和设计上,产品的需求说明书和设计指南按照别人的成型产品照着写就行了。想做调查的团队,有了创新,设计出产品,也有很大风险被其他团队“借鉴”去形成自己的产品。(中国的专利现状对界面设计没有实质性保护,具体表现在:首先人机界面在中国往往只能申请外观专利,是静态界面,并不真正适合保护人机界面设计;其次外观专利较难获批,因此有时申请的是技术专利,其他团体换一种技术方案实现就不会侵犯专利;再次即使侵犯专利,打官司要拖2~3年,维权困难。)

“借鉴”的往往是其他文化背景下,如国外成功运营的产品。然而文化、国情、所处阶段不同,直接“借鉴”也未必能成功,即使在腾讯,也有这样的案例。产品成功,更需要做目标用户的调查和分析。

“借鉴”绝对不是真正的捷径,并非必定能获得商业成功。

因此关于第四个问题,首先“借鉴”仍然存在的现在,还是离不开用户调查,要对不同文化、国情、阶段做出分析判断,才能帮助产品获得成功;其次“借鉴”并不是捷径,绝不会是长期存在的。当“借鉴”不能成为可靠方法,那么必定还是会回到从调查分析开始进行创新的路上来。

最后额外说一个问题。设计师与产品经理的关系一直是互联网行业里讨论比较多的。笔者的看法是,做人机界面设计,其实和产品经理的工作有重叠,所以学习人机界面设计之后两个职位都可以去应聘。已经在设计岗位上,也没有问题,不妨把自己看成特殊技能的产品经理。界面设计师刚刚到岗,经常和产品经理发生矛盾,认为对立的原因是自己是从用户角度出发,产品经理不是。其实很可能是产品经理了解的信息更多,考虑的东西更多。要让界面设计师站在产品经理的角度想问题,初入职的设计师又往往认为从用户角度考虑就是自己的全部职责,坚持从一个角度看,缺乏大局观。不妨在一开始的时候就把自己看成具有特殊技能的产品经理,这个矛盾就好解决了。

已有0人赞过

+1赞

认真评论的都成大咖了

还可输入1000个字

我要评论 我要评论
  • 刚刚
  • 登录优界网 ×