Archive for the ‘用户体验研究’ Category

报告撰写 可用性问题的描述格式：用户的具体操作（现象）、用户这样做的理由（测试现场对用户的追问+事后分析）、导致的结果 注意可用性问题的归纳，不只是把原始数据搬过来就算了（因为有些问题可能是源于同一个的原因）。同时，看看哪些量化的数据可以支撑这些可用性问题。 仅仅是罗列问题是不够的。作为用研的人员，我们大部分是过程导向，巴不得把所有做过的东西、流程写上去（就像在学校里写论文一样）；但对于产品的开发者来说，他们更倾向于结果导向。例如向我所外派的单位，他们希望听到说：他们需要做什么，为什么要这么做，怎么做(what, why, how)。在可用性报告里，我们可能把发现的问题罗列出来，但个人觉得这种形式不好。看报告的人看了一堆的问题，不好修改。如果以建议点为中心，紧跟着为什么要这样改的理由，对于一些问题不算很大、不知道是否有修改的必要的问题另外列出来，与之前的建议点区分开。   以下是大前研一在《思考的技术》里提到的 1、把现象当结论（缺乏现场追问和事后分析） 2、金字塔：你最有信心的结论位于金字塔顶端，而结论下方都是支持这个结论的，支持的论据少一个都不行（就像类积木那样） 3、如何提建议：最典型的错误就是，把所发现的问题反过来表述，就当做是给客户的建议，e.g.  业务员没有精神，所以应该把业务员打起精神 4、做报告的顺序：不是自己想说的顺序，而是对方理解的顺序 5、用5分钟把45分钟的内容讲出来  

测试中我们主要记录以下2种数据： 客观指标：行为 （e.g. 完成率、完成时间、错误次数、请求次数、操作的路径） 主观指标：动机—>需求–>态度—>价值观 （e.g. 满意度、向别人推荐的意愿） （这些又分为意识vs潜意识） 如果是意识层面的，可以直接问，但需要技巧；潜意识的动机、需要、态度，不一定能直接问到，可能需要投射技术。   总则：        可用性测试侧重的是用户的操作、是行为，只不过有些时候我们不知道用户为什么进行某个操作的时候，而行为本身不能说话（当然用think aloud的方法能部分弥补），所以我们需要去询问这些操作背后的原因。例如，你想了解用户对这个页面上的某些内容感兴趣，你可以让用户点击浏览他感兴趣的内容，而不是问他：你对上面那些内容感兴趣？所以，如果你要测的产品（e.g.网站）能记录用户的操作行为，比找几个用户过来直接问要准确。   测试过程 当用户出现值得关注的操作和行为时，尽量在每个任务结束后，当场询问他刚才在这个操作时，是怎么想的，避免事后根据自己的理解来推测用户当时的心理活动。而且尽量记录用户原话。 虽然我们力图将测试脚本写得比较完善，但对于用户出现了脚本上没有测试的行为时，可以把这个操作记录下，并当场询问用户。 测试完之后，主持人立刻检查有没有有一些测试题目是没有记录的。如果有的话，当场询问用户。（因为我们这次有部分题目是漏写了的） 记录员与观察员之间分开记录，或者在制作脚本时制作2个版本。持人的主要精力应放在观察操作，记录需要进一步澄清的问题和用户不同寻常的问题点，一些脚本上既定的步骤与评价可以让观察记录员来完成。 用户在输入密码的地方不要录制。 用户在填写SUS量表的时候，主持人尽量不要在场，避免用户因为我们的在场而不敢打低分。如果测试的产品涉及多个版本，可以考虑让用户对几个版本分别评分。   询问技巧 避免措辞里对用户的引导。例如，不要给用户选择A还是B。 区分主持人评估与测试后问题。例如，像 “是否理解热点的意思”这类问题，可以让用户来解释这些用语，把用户的原话记录下来后，再根据它来判断是否理解。而不是直接问用户，“你理解这个词的意思吗？”，因为他们很可能会回答是，但其实是没有理解的。 如果你问用户“你平常会不会和朋友分享应用？”或者“你平常用过语音输入法吗”，他会回答“很少 ”；当你再问你在过去有没有真的，他可能回答没有。 有些人认为把用户的所有原话记录下来就是最好的。但我个人认为真实、原本≠好   —————————— 以下是其他人总结的经验

脚本撰写 预演和预测试：测试脚本的初稿写好后，得把全部过程预演3遍左右；能找到用户预测试就更好了。这可以避免在施测了2、3个用户后才发现脚本有问题。 制作测试脚本前，需要将测试产品的所有功能都尝试一次（尤其是开通、取消、查询套餐、搜索等），不能以为不会出现问题，就省略了这个步骤。例如，有一次我们使用了同一个测试手机的号码来完成办理业务，当用户直接点击办理套餐时，只有第一个用户收到的短信才会提示用户，后续的用户都出现的提示语则不是这一条。 凡是涉及到呈现次序时（e.g.测试多个竞品或方案），必须考虑顺序效应。 十分仔细地检查上一个任务对下一个任务的影响，看看上一个任务结束时的页面对下一个完成时的页面，是否要求任务开始时页面处于什么状态（脚本里注明初始和结束状态），尤其是那种流程类的任务（例如上一个任务是提交信息，下一个任务是修改信息）。 第一次使用测试产品时，必须记下自己的任务不适应的、不是很理解地方，哪怕它只是个小问题。因为这些不适应的地方，不算很强烈（但它们很可能就是可用性问题），它们会在你逐渐熟悉这个产品之后而“消失”，你很快就容忍了这些细节的小问题。 如果任务涉及到评分，我个人觉得在用户操作完这个任务之后，立刻评分。Yale心理学公开课里提到的一个例子就是当要求被试列举出某个人的3个优点或10个优点时，发现被试会对列举3个优点时评分更高。因为要列出10个优点比较难，很多人列不出来，于是人们对这个人的好感降低。这类研究有很多。  

常用的用户分类： 活跃，非活跃，新手（全新） 本产品，流失，竞品     （以下是针对可用性测试而言）   维度1：是否用过本产品？ 1、本产品（待思考） 2、同类产品（这种用户会学习和适应所测试的产品会稍快，他们延续其他产品的操作行为来使用和评价测试的对象；对于他们提出来的可用性意见如何采纳？） 3、都没使用过 （这种新手因为不熟悉这类产品的操作，所以可能会“发现”更多的可用性问题）     其他维度：性别？年龄？职业？还是….？      《采铜学心录》的作者认为，大家习惯性地从性别、年龄、职业、学历等人口统计学的维度来进行划分和筛选用户（例如招募的比例是男vs女1：1，学生vs工作1:1），通常是没有必要的。大家之所以这么做，估计也是习惯了社会学调查、市场调查的做法。       那具体要不要这么划分呢？       先问自己：我们为什么想要这样划分？是预期不同性别、年龄、职业、学历之间的人，在使用测试产品时存在差异，以便我们发现的可用性问题能代表广大人民群众的使用习惯和想法，是吗？如果是的话，为什么这几个属性会导致了这种差异呢？原因可能会是：年纪大的人不熟悉手机、电脑操作，学习能力差一点，那我们为什么不直接用“使用手机的时间”、“操作手机的熟练程度”来直接划分用户，而采用年龄这个间接属性来划分呢？（不过话说回来，年龄、职业这些属性很容易获取，而类似操作手机的熟练程度这类属性，如果没有现成的量表，还得自己设计几个问题来测量才行，其信效度又可能被质疑）      《设计心理学》的作者Donald Norman 之前写过一篇文章说，以人为中心的设计（Human-Centered Design）的理念是如此的深入人心，以至于可能大家在理解的时候会出现一个偏差，于是他提出以活动为中心的设计（Activity-Centered Design）。对于可用性测试而言，我们注重的是用户在完成给定的任务时，他们与界面之间的交互行为，以及这些行为背后所反映的认知模式、体验、态度、需求等。      《采铜学心录》的作者认为，他并不反对给用户进行分类，但是这一分类必须是在用户研究完成之后，而不是之前（不然研究还没做，你凭什么知道你的分类是合适的？）；必须是基于用户与目标产品交互的行为模式和特点，而非仅是用户自身的一些属性。   插曲：      同人于野兄写过一篇文章《从Web 2.0到推荐引擎2.0》，里面介绍了2种推荐的机制：一种是像Pandora那样，通过分析歌曲本身的特点，推荐曲风相同的歌曲；另外一种是像Hunch那样，它直接分析人的喜好。（个人觉得，分析歌曲相对容易，容易推荐到你喜欢的曲风相似的歌，但一个人可能会喜欢多种风格的歌曲；直接分析人的话，相对复杂）

领了2次工资，写点东西小结一下吧….   作为心理系的学生，第一次接触可用性测试的时候，我感觉： 1）“脚本”这个词很怪 2）人真的是千奇百怪，面对同样一样东西，人与人的反应差异很大（所以哪怕在测试前我好像已经发现很多可用性问题了，但你总能从用户口中听到很多你没想过的） 3）为什么在测试时，实验的主试会坐在用户旁边一对一地交流，而不像很多心理学的实验那样，直接让被试对着屏幕来完成，减少主试对被试的干预。由于我们经常要计算用户完成任务的时间、成功率，而用户在完成这些任务时会询问主试问题等，这使得计算任务完成的时间存在困难，而且由于主试在场的话，被试是否会存在依赖心理，凡是遇到不太理解的地方都会问主试，这样可能也会降低任务的成功率和独立性的评分。 4）为什么被试数目这么少？12-30个真的够吗？虽说找被试很贵，但调研公司做个普通的调查需要几百个样本，岂不是更贵？而且“5个用户可以发现85%以上的可用性”，这个85%也是基于每个用户可能发现所有问题的30%而计算出来的（关于这个问题的讨论详看这里）。 5）企业内部的用研部门 vs 请外面的用研咨询公司  

大家都知道那个”神奇的数字5“，因为Nielsen的研究发现，5个用户可以发现80%以上的可用性问题，他是假设平均每个用户可以发现30%的可用性问题，而且假设所有问题都有同等被发现的概率。 过去的研究已经对测试的样本大小进行过不少探讨，例如： Benefits of increased sample sizes in usability testing (2003) Why you only need to test with 5 users (2000) Five users is nowhere near enough (2001) Refining the test phase of usability evaluation: How many subjects is enough? (1992)   Lindgaard和Chattratichart（2007）的研究发现，可用性测试的用户数量与被发现的可用性问题比例、被发现的新可用性问题比例均不存在显著的相关关系。但是用户的差异化、任务的个数则与被发现的可用性问题显著相关。（详见下面的PPT）   Lindgaard和Chattratichart说，HCI在过去15年花了较多的时间去探讨用户的数量，而忽略了如何设计可用性测试中的任务         Take-home Message： 尽量选取有代表性的用户，而且用户不要太同质化（如果我没记错的话，统计上也是如此，用户内部的差异越大，才容易检测出显著） 与用户的个数一样，不是单纯地讨论设置的任务个数，而是要看这些任务所涵盖的范围（这些任务具体涉及到了产品的哪些功能点）。转载一段话：”如果产品处在设计的初期，我们需要关注一些宏大的问题（如：网站的整体架构、导航和分类的合理性、页面的逻辑关系），此时就需要通过宽泛而有弹性的任务，来查找宏观层面的问题。如果产品的设计已经非常完善，开始进行细节的修改迭代，此时就需要通过设置相对具体的任务来查找特定的细节问题（如：对某个命名的理解、按钮的使用、链接的点击、表单的填写）。“  （摘自网易用研）   [...]

可用性量表很多（见下图），SUS只是其中一个。  SUS简介： 量表作者：John Brooke  (Digital Equipment Corporation, UK, 1986) 问卷组成：10个问题，在5点量表上打分 量表中文版以及计分方式：查看这里 信度：0.85  （见上图）   优点： 问卷短，省时 最后会得出一个分数，直观 免费 对于小样本（ n<14），SUS的优势更明显（见下图），图中的意思：随即抽取14名被试的SUS问卷均能判断网站1比网站2要好，而抽取的CSUQ问卷只有90%能做出这个正确的判断，详见这个PPT或原论文）