只需一步，快速开始
绝对干货|用户研究方法之可用性测试
|原作者: 陈小欢|来自: 互联网er的早读课
摘要: 可用性测试是指，让一群有代表性的用户尝试对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。
可用性测试是我认为在所有用户研究方法中能够呈现出最直接、最具有效结果的研究方法之一，掌握好可用性测试研究方法，对于产品的用户体验帮助很大。可用性测试是指，让一群有代表性的用户尝试对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。该产品可能是一个网站，软件，手机，或者其他任何产品，它可能尚未成型。测试可以是早期的纸上原型测试，也可以是后期成品的测试。拿手机来举例子吧。通常有用户体验意识的设计人员或产品经理会在产品（这里指典型模块，比如通讯录、短信、电话、设置等）初成雏形并版本运行稳定的早期向用户研究部提出可用性测试需求，以便在产品面向用户开放之前提前得到用户的使用感受及反馈，及时做出迭代优化，进一步提高产品上市后的用户体验感。我们通常建议设计人员在早期预留足够时间可以让我们对产品进行测试及迭代，这样也避免许多其他的不良状况出现，很多设计人员对产品开发流程和时间没有合理规划好，没有多余的时间让用户研究部进行目标人群的用户招募及计划有效的测试方案，又希望产品拥有良好的用户体验，通常就会把自己或公司内部员工当成目标用户，过一过用户的常用操作，然后快速迭代。但是，他们都忽略了，自己是设计该产品的专业人员，即使是同公司的其他部门的同事，作为整天浸泡在手机堆里的公司员工，你确定你能代表可能是小白的目标用户？结果很可能是，你觉得根本不是问题的问题，用户却摸不着头脑，用得苦不堪言，这对于设计人员而言，没有比这更糟糕的情况了。或许，这样的方法只能在测Bug的时候使用。所以，设计人员或PM拥有研究意识，能够尽早提出需求，保证有足够时间给予用研人员去计划及实施，这点是非常重要的。和需求方（这里指设计人员或PM）确认好需求后，项目马上展开了。整个可用性测试流程大概如下：1.项目方案项目执行前，计划好一份项目方案，包含项目目的，时间，招募用户人数，费用，输出物等；通常情况下，我们会先拟好用户招募标准给予第三方报价（为了节约时间），再撰写项目方案，但如果是用研部门自行招募用户(这里要考虑到实验室的问题，如果要设计人员一起参与，那就需要有单向透视玻璃实验室，避免测试时现场人数太多给用户造成紧张感影响测试效果)，费用可以预先大概估算；关于项目时间安排，建议和需求方进行讨论，执行时尽量让需求方参与，在旁听室里听听用户对他们设计的产品的真实反馈，冲击力非常大，我认为这比百页PPT要有效得多了。2.用户招募交给第三方市场调研公司招募用户，你一定要拟好目标用户的招募标准；首先你要清楚，你的产品是给什么人群使用的，或者是哪些人群使用你这款产品居多，这里可能包含他们所在的区域，年龄，学历，性别，使用行为等；不同产品对用户的使用经历要求也可能不一样，可能是曾经使用过你们公司产品的老用户，也可能是要新发展的潜在用户；在招募期间，你要跟踪招募进度，核实用户信息，确保有足够的备份参与者，尽量避免执行时发现各种不符合招募条件的意外情况，影响整个项目进度和质量。3.专家走查这里的“专家”当然指的是用户研究员，比起设计者开发者，用研员接触用户的机会更多，也更了解用户的行为与想法，在撰写执行方案之前，用研人员对要进行测试的功能或模块应该有一定的了解，将其进行详细全面的走查测试，找出可用性问题，这样做的优点第一可以有助于执行脚本设计，将严重级别高的问题设计在执行脚本里，探索用户对这些问题的反应及态度；第二可以增加用研员对即将要测试功能的熟悉度，避免执行时用户操作到哪个层级，可能会遇到哪些问题，甚至可能向你求助这些情况无可预判或不知所措；第三这也可以将用研员找出的可用性问题做一个吻合程度验证，考验用研员对用户使用行为的了解程度。4.撰写执行方案执行方案既是访谈脚本，内容主要根据需求方的具体需求来进行详细设计，哪些模块、功能是希望了解用户的反应及看法的，在上一段我说到专家走查的结果可以引进访谈脚本里进行设计；设计脚本时要特别注意以下几点：1）用户信息验证尽管在招募期间你会从第三方招募公司得到招募进度，里面包含了用户的基本信息及相关功能使用行为，但在你和用户未面对面接触之前，通过电话或网络沟通所得到的信息是不同的，所以在开始进行功能测试之前，第一模块先确认好在你面前的这位用户是你想要的，你能从他身上得到有效的反馈；如果实际情况不符合，那么和第三方沟通，及时停止访谈，不要觉得尴尬，这样才不会浪费彼此的时间。2）模拟场景及任务设计这是整个脚本设计的重点模块，你最好的连贯合理的场景将所有要测试的功能串起来，这样做的好处是能够让用户身临其中，想象自己在该场景下有可能做出的反应，比如通常我们测试手机的通讯模块，我们会这样设计：“故事背景：假设您刚刚购买了这个手机，我们接下来的操作都会在这个手机上进行。 任务一：今天我们是第一次见面，为了方面今后联系，请您将我的联系方式保存在手机上。“而每个任务，我们都会标注好这个任务的探寻点、观察点及控制点，哪些地方是需要在用户做出反馈后进行深挖及追问的，哪些地方是需要你观察用户的反应的，探索到哪些点可以截止追问，因为任务不同，你要侧重了解的内容也不同，”保存联系方式“我们是想了解用户的新建联系人方式，可能会涉及拨号盘，电话本，甚至是通过短信保存号码的短信功能，而当我们的重点是想了解用户对拨号盘的新设计反馈时，除了对他们本身操作习惯的了解和探索之外，我们也应该恰当地让用户尝试使用拨号盘，看看他们对这个模块的设计感受及反馈。3） 用户的使用评价通过了多个任务的使用操作后，用户对新功能的设计也有一定的主观感受和评价了，在脚本的第三部分，不妨设计一份用户的功能使用评价问卷，最好是选择题或分值题，便于统计，题目设计性质当然包括产品的易用性、提供的反馈、是否能快速帮助用户完成任务等，通过正反向的问题去设计，这样也可以验证用户的评价是否自相矛盾。4） &用户的意见与建议在用户操作任务的过程中，肯定会针对当下的操作说出他的想法或建议，在整个脚本的最后部分，可以再让用户总结回顾所有操作他认为好或不好的地方，是否需要改进，他有什么改进建议，当然，包括他对整场测试的想法，过程，也都可以提意见；最后部分属于是开放性的总结。5.预测试撰写完执行方案，并非就可以坐等执行日了，还需要找2-4位非专业人士（可以是朋友，同学、或者是公司行政、HR同事）对执行脚本进行测试，不要想着是预测试就随随便便过一轮，按照真正执行时的态度对待，这样可以测验脚本的细节，主持人（用研人员）也可以熟悉脚本，测验整场测试下来需要的时间是否在预期内，脚本是否需要修改，优化，语言是否通畅易懂等。6.测试执行经过一番辛苦的筹备，执行日终于到来了。工作人员这天请尽早抵达执行现场，检查设备是否齐全及完好，包括视听设备、录音录像设备，桌上还可以放些小零食、饮料、矿泉水等，在用户抵达之前做好这些准备工作；现场装饰最好营造轻松、自然的氛围，降低用户的紧张感。执行时，不同角色有不同的任务。主持人：拥有良好的主持仪态，注意着装大方，手机调静音，语速不紧不慢，不要紧张，你要知道，用户比你还紧张。测试开始，告知用户你们的测试目的，测试时长，现场的录音录像设备只是为了方便后续的结果分析，不会暴露个人隐私，让用户放松；在测试过程中，耐心观察用户操作，脑要比眼快，你要预测到下一步用户可能会做什么操作，你可以追问哪些问题，不要过于生硬依赖脚本，脚本只是辅助作用；你可能会遇到反应比较慢，操作比较慢，或者是不知道如何操作的用户，给予耐心，尽量鼓励对方，让对方独立完成操作，引导性的话语是在不得已的情况下才使用的。要谨记，可用性测试是为了测试产品而不是用户的能力。有时候用户的反应或说的话会很幽默，不要忘形大笑，这或许会伤害到对方。整个测试过程，要把握好每个任务的时间，不要在前面花费了过多时间，后面发现时间有点紧，就囫囵吞枣了。记录员：为了不错失一些重要的原始数据，通常的情况下，会有2个记录员在观察室进行现场记录，在测试现场所记录下的第一手资料，将比测试后观看视频、听录音的效果更加深刻、真实。记录员在记录过程中，有以下六点要注意：用户操作任务是否顺畅（遇到的阻碍）我们想从用户身上得到什么信息（例如是否使用常用短语）用户是否按照正常的操作路径去完成任务用户是否知道自己在做什么？用户遇到了什么问题？例如：1）不理解功能的命名等& & & & & 2）术语（有利于产品开发的共同性和差异化个性& & & & & 3）不知道在哪或不知道该怎么做当用户进入错误的操作区域，能否自主从错误中恢复过来（是否需要帮助完成任务）旁听人员（开发、设计、PM等）：每天泡在办公室里忙于开发迭代规划，如此近距离接触你的用户的机会可能不常用，在测试过程中，你可能会从用户嘴里听到关于对你所设计的产品的褒贬，不要激动，失望，生气，这些都属于正常现象，你来旁听的目的是为了得到用户的真实反馈，为了更有方向性地改善你的产品，在观察室这样的小黑屋里呆上一两天，可能会很烦闷，但尽量不要走神玩手机聊天，主持人和记录员比你还累，你可以认真记录下每个任务中你发现的不解问题，在测试结束时通知主持人将问题补上，几场测试下来，你一定收获良多，对你的设计方向豁然开朗。7.数据分析可用性测试完成后，需要根据记录员的记录、录像录音等资料，整理出用户在使用过程中遇到的可用性问题。1）什么是可用性问题典型的可用性问题会描述一个或多个参加者所遇到的问题并评估背后可能原因，典型的可用性问题包括：l &任何影响了任务完成的情形l &任何让用户产生某种疑惑的情形l &没有看到应当注意的内容l &任何导致错误的情形l &错误的操作行为l &不理解导航（结构）2）辨识问题非常有挑战性的工作之一就是确定哪些问题是真正的可用性问题、哪些问题只是偶尔发挥失常的结果。最明显的可用性问题通常是多数参与者都遇到过的问题，比如我们曾经测试短信功能，发现大多数用户都不理解“插入名片“的意思。但是有些问题是比较模糊、不明确的。比如，在我们的翻盖产品W100的可用性测试中，仅有一位参与者无法认知到“摩天轮”关闭和开启的方式。这类问题是看作可用性问题，还是认为属于该位参与者的个人能力问题？在这种情况，我们应更多地关注用户的行为、思路、感知或者决策是否符合逻辑。也就是说，这些行为或想法背后是否有一致的说辞或者逻辑。比如，在测试中观察到一个参与者因为没有找到功能入口而无法进行语音功能的操作。任务结束后，你可以问他是否看到“语音图标”，如果看到为什么没有尝试点击。如果用户回答说这个图标是麦克风，认为该图标是录音功能的入口。这种情况很可能就是真的可用性问题。3）整理可用性问题列表：确认问题之后，将所有的问题整理成问题列表，方便之后的整理和分析。问题整理应包括以下内容：问题位置：描述发现可用性问题所在的页面，如某些问题反复出现于多个页面，则标为“非特定单独页面”；问题描述：对可用性问题具体含义的阐述，用语需简明扼要、易于理解；分析建议：依据已制定的可用性原则，阐明目前的设计是如何违反原则的，基于该问题所提出的有针对性的解决方案，解决方案必须是直接可操作性；解决方案相对已存在的可用性问题，要更加简洁易懂，符合逻辑，参考用户的使用习惯。当研究人员对建议内容持有疑惑时，可与其他组员进行细致分析，做出合适建议。违反原则：该问题所违反的可用性原则（这里指Nilsen十大可用性原则，针对不同产品有细节修改），如：一致性、符合用户认知、易学性等；以上三项内容都是为了让研发相关人员能够快速定位问题和了解问题，让跨部门的沟通能够客观标准以及快速。因为问题列表作为可用性测试的输出物，会在交互、软件等部门流通和传递，因此“问题位置”可以让未参与测试的相关人员迅速地定位问题。“问题描述”则是对可用性问题进行简单明了的描述，快速地了解问题的具体情况。“分析建议”是用研人员从自己的专业角度和目标用户定位出发，结合违反的原则，具体地分析问题的情况，并提出可行性的意见。如果问题比较复杂，或者属于框架性问题，涉及范围比较大，可以跟交互设计的同事讨论。“违反原则”中的原则是指尼尔森提出的可用性十项原则。最初十项原则是针对网页设计的，不过随着不断的完善和改进，对于手机的交互设计也很有指导意义。以十项原则为基础，除了可以在查找问题时有依可循，有统一的标准，更可以增加问题列表的权威性，便于推动后续的改进工作。可用性十项原则具体如下：l &系统状态的可见性l &将真实世界与系统联系起来l &用户的自由与控制权l &一致性l &预防出错l &认知优于记忆l &使用的灵活和有效性l &美感及极简约主义设计l &帮助用户识别，诊断和从错误中恢复l &帮助和帮助文档4）严重等级评估不可能所有的可用性问题都是一样的，有些问题会让用户的操作无法继续进行，而有些问题让用户感觉使用起来不习惯，感觉心烦。在时间资源有限的情况下，应该集中精力解决严重的问题，因此对可用性问题的严重等级进行评估是很有必要的。可用性问题的严重等级评估的方法有很多种。Nielsen（1993）提供了一种简便易行的方法，通过综合对用户体验的影响和相关任务的使用频率这两个因素来进行严重等级评估。这个评估系统非常直观，而且便于解释。在实际的操作中，除了对用户体验的影响、使用频率这两个因素之外，加入了可克服度，从这三个因素综合评估可用性问题的严重性，评定优先等级。问题频度：是指出现此问题的参与者数量；影响程度：若一个问题直接导致用户无法完成任务，则此问题的严重程度较高，反之则低；共设三级评估系统。1：不严重，对完成任务或进入下一界面影响较小；2：较严重，对完成任务或进入下一界面有明显影响；3：非常严重，导致无法完成人物或无法进入下一界面；可克服度：是指用户克服可用性问题的难易程度；三级评估系统：1：即使首次使用也容易克服；2：需要学习或多次使用，渐渐克服；3：多次使用都无法克服；综合优先级=【严重程度分值+可克服度分值+（问题频度/参与者总人数）】/3优先级说明：2.4-3.0：问题严重，优先需要修改1.8-2.3：问题较严重，次优先修改0.1-1.7：存在改进空间，可跟进修改成本考虑修改5）问题归类在可用性问题的描述分析和严重等级评估完成之后，需要对问题进行归类。将问题归类，可以从战略的角度来分析应当着重改进哪些方面的设计。正常情况下，可将问题分为导航、内容、呈现方式和交互四大维度。架构导航：为用户提供路径引导，帮助用户了解当前所处位置及如何到达目的地。包括在多个页面、视图或者应用之间的导航、在工具和菜单之间的导航，以及信息导航。内容：提供给用户具有价值的信息点、功能和信息；交互：系统的操作方式与用户的操作习惯是否一致。当系统模型与用户的心理模型一致或接近时，用户进行操作会非常顺畅，不需要付出额外的认知和学习；呈现：系统界面的颜色、形状、大小、位置以及图标等设计；将通过可用性测试发现的问题，一一归类到以上四种维度，合计之后得到各种维度的问题数。通过问题归类，可以很清楚的了解，设计或产品在各个维度上的情况。尤其是在进行竞争产品分析的时候，通过将问题归类比较，可以很清楚地看到产品的优势和劣势，为下一步的改进提供大方向。需要说明的是，架构导航维度的问题一般都是比较严重、影响广泛的，并且在软件稳定、产品成型后，对其修改的成本是非常巨大，甚至是无法改进的。因此，在产品开发前期，对产品的架构进行合理的规划是非常重要和必要的。掌握好一场可用性测试十分不易，需要投入许多精力，考虑许多细节，愿本文能给大家带来有价值的帮助！
上一篇：下一篇：
Powered by
鸟哥笔记 沪ICP备号-1您的位置： >
测试人员必看：什么是可用性测试？
　　可用性测试(usability testing)这一术语被不加区分地指代任何评估产品或系统的技术方法。很多时候，演讲者明显是在讨论本书第一章介绍的其他方法(如启发式评估、任务走查等)，却仍称呼这些方法&可用性测试&。本书中可用性测试是指：招募有代表性的目标用户作为测试参与者，评估某产品是否符合特定可用性标准以及符合程度。可用性测试以具有代表性的真实用户为测试样本，这不同于专家评估、任务走查或其他不要求具有代表性的真实用户参与的测试方法。
　　可用性测试这一研究方法，起源于经典的实验方法学。测试范围很广：既可以是样本量较大、设计复杂的经典实验，也可以是仅有一名样本的非正式定性研究。研究目标不同，时间和资源不同，通常采用不同类的测试方法。本书重点介绍非正式的、相对不复杂的可用性测试，它们适用于工业产品发展环境中的结果快速迭代。
　　为什么测试?测试的目的
　　站在公司的立场，可用性测试是为提升产品收益而付出的巨大努力之一。进行测试的好处很多，用户最终也获益良多：从具有代表性的用户中收集数据以帮助设计决策、修复设计问题，减少或消除用户的挫败感。
　　信息化设计(Informing Design)
　　可用性测试总体目的是在产品发布前识别和修复产品(包括附加的支持材料)中的可用性缺陷，收集测试数据帮助信息化设计。目的是保证新产品：
　　是对目标用户有用且有价值的
　　是易于学习的
　　可以帮助人们有效并高效地处理事务
　　使用时令人满意(如果可能的话，甚至是令人愉悦的)
　　消除设计问题和挫败感
　　正如硬币的两面，与产品收益相对的是用户使用产品的易用度。如果产品发布前，你完美解决了产品设计的缺陷，目标用户在使用产品时挫败感最小(甚至没有)。那恭喜你，你同时也实现了如下目标：
　　为你的组织与用户建立良好关系奠定了基础
　　提前设定了预期，你的组织销售的产品不仅优质且易于使用
　　表明你的组织重视用户目标
　　用户会发现你的组织所发布的产品是有用、有效、高效且令人满意
　　提高收益
　　你的组织进行可用性测试的目的和益处：
　　创建可用性基准的历史记录，与后续版本比较。公司通过追踪测试结果，保证新产品已经提升了可用性，至少也保持了以往水平。
　　减少服务和支持呼叫的成本。一个易用的产品不需要多余的服务呼叫以及公司的其他支持。
　　增加产品销量和重复销售的可能性。有用的产品创造了愉悦的用户，他们与身边潜在的购买者(客户)或用户谈论或推荐。同时，愉悦的用户会继续使用产品的未来版本，而不会购买竞争对手的产品。
　　赢得竞争优势，可用性已成为产品在市场中的分水岭。可用性已成为用户区别某产品与竞品的主要标准。你在选择时，只要浏览最新广告并筛选出被形容为&简单&、&容易&的产品就好。不过，不幸的是，在这些产品被测试后发现对其的描述并非恰如其分。
　　降低风险。事实上，所有的公司和组织已经进行可用性测试很多年了。只不过这类测试的真名是&产品发布&， 投入市场的产品在用户试用时被&测试&。显然，这样的战略引起巨大的风险，而产品发布之前进行可用性测试可以降低发布后的产品存在严重可用性问题的风险。
　　方法学基础
　　进行可用性测试的方法学基础是实验控制的经典方法。进行基础研究的正规做法通常是：形成特定假设，在控制情境下隔离和操纵变量来检验假设。通过合理的推论统计方法严格地考察变量间的因果关系，从而接受或拒绝特定假设。真正的实验设计具有如下特征：
　　形成特定假设。假设是指在检验中你所期望发生的结果。譬如，&A格式的帮助设计相比B格式的帮助设计，提高了有经验用户的速度和错误率& 。For example, &&Help as designed in format A will improve the speed and error rate of experienced users more than help as designed in format B.&&假设必须尽可能地具体。
　　(采用非常系统的方法)随机选择参与被试并分配至不同的实验条件。你需要理解目标总体的特征，从总体中随机选择具有代表性的样本。随机抽样非常困难，尤其是在目标总体是现有客户时。
　　严格控制。实验控制非常重要，否则即便达到统计显著性，结果的有效性仍将受到质疑。在测试前或测试中，所有测试参与者的产品使用经验必须是大致相同的。另外，与测试主持人的交互程度也需要控制。
　　必须设置对照组。为了结果有效，必须设置对照组;对照组只在需要考察的某一变量上的设置与测试组有所区别。
　　(用户的)样本量必须足够大，可以在统计上检验组间显著性差异。为了测量组间统计上的差异，需要较大的样本量。样本太少可能会导致结论错误。
　　上述为经典实验的方法基础，在进行基础研究时，这不失为好的选择。但是，它不是本书所介绍的可用性方法，理由如下。
　　本书大多数读者置身于节奏快、压力大的产品开发环境中，采用上述方法进行可用性测试通常是不可能或不恰当的。出于公司制度或其他方面考量，这样的测试方法也是不可行的。进行可用性测试的目的并非是建立或检验某个假设，而是形成提高产品的设计决策。
　　富有经验的可用性或者人因学专家仍旧需要充分掌握实施经典实验研究的方法和统计知识。一名没有相应背景或缺乏训练的测试者得出的研究结果有可能是令人误解的，甚至会造成更坏的后果，这比不进行任何研究更糟糕。
　　当经常进行测试时，你通常很难践行随机分配测试参与者这一原则，你很难控制这个因素，尤其是以现存用户作为测试参与者。
　　不采用正统的实验方法的另一原因是样本量。实验研究中，结论需要推广到特定的目标总体，其必须的样本量大小是依赖于总体的现有已知信息。但通常这类总体信息又是未知的(这有时也是进行测试的原因)。由于缺乏总体信息，保险起见，每种条件需要10-12名测试参与者，考察单个因素就可能需要测试40个甚至更多的用户以达到统计上的显著结果。
　　最后并且可能是最重要的一点，经典的方法学是为了收集验证假设所需的定量证据，譬如某种设计优于另一种，而不是为了获取定量信息，以解决问题和重新设计产品。我们认为多数读者更关心后者而非前者。
　　我们推崇的方法相对非正式，是基于迭代的测试，但本质上仍遵循实验的严格性。在本书的后续章节中，你也会发现，实验严格性这一准则对任何研究来说都是必须的。
　　在产品发展的早期阶段，进行一系列快速、具有针对性的研究是大有裨益的。这也正是本书介绍这类非正式却被严格设计的测试的目的：发现产品某些可用性缺陷、识别原因并找出克服它们的方法。下节我们将描述测试的基础方法。
　　可用性测试的基本要素
　　形成研究问题或是测试目标，而不是假设。
　　选择具有代表性的用户样本，这些样本可以是不被随机选择的。
　　测试环境类似真实的工作环境。
　　观察终端用户使用或者回顾真实产品。
　　测试主持人需要控制，并且有时需要访谈和调查参与者。
　　收集定性和定量信息以及偏好数据。
　　对产品的设计提出改进建议。
　　我们将在后续的章节中详述如何进行测试。
　　测试的局限性
　　现在我们已经描绘出可用性测试可实现的目标这一宏伟蓝图，也是时候让我们浇点冷水了。测试绝不是可用性或是产品获得成功的全部或关键因素，理解测试的局限性至关重要。测试无法保证产品的成功，甚至也不能就此证明产品是有用的。即使是被最严格执行的正规测试也不可能100%的确信产品发布后是有用的，这是因为：
　　测试通常是在人为环境进行。在实验室测试，即便是在现场测试，也只不过是对真实使用环境的模拟，本身并不是真实使用环境。执行测试本身就有可能影响结果。
　　测试结果无法证明产品是可用的。即使某个产品的测试结果达到统计上显著，仍不能证明这个产品运行良好。统计上的显著性仅仅是衡量测试结果不是随机造成的这一可能性，并不能保证产品是可用的。而且测试结果与测试进行所在的环境有很大关系。
　　测试参与者不能完全代表目标用户。参与测试者仅代表了你所理解和定义的那部分目标用户。市场研究毕竟不是绝对正确的科学，而且真正的最终使用用户通常是难以识别和描述。
　　测试并不总是最好的方法。我们在第1章和第13章讨论了众多评估和提高产品的方法。例如，在某些案例中，相比可用性测试，进行专家或启发式评估在成本、时间和准确率上更为有效。尤其是在早期阶段，不成熟的产品会违背较多可用性准则。此时我们并不需要为了发现这些显而易见的问题而招募众多测试者。
　　尽管存在上述局限，作为一种以用户为中心的方法，被精确设计的可用性测试如果是基于合理的研究问题，在产品发展生命周期内的正确时间施测，它将是发现产品潜在问题并解决问题的可靠方法。它可以大大降低发布不稳定或无法学习的产品所带来的风险。在几乎任何情况下，进行测试好过不进行测试，这也是本书暗含的主旨。
　　VIA:本文译者 张晓雯
和相关的文章：
责任编辑：小P
快捷导航：不做可用性测试，你没资格说你的产品是个好产品！ - 简书
下载简书移动应用
写了5532字，被0人关注，获得了4个喜欢
不做可用性测试，你没资格说你的产品是个好产品！
一、什么是可用性测试？
1、可用性测试概念其实可用性测试并不复杂，简单概括就是观察用户使用产品。如果稍微扩展一些，我们可以将其解释为：通过观察有代表性的用户，完成产品的典型任务，而界定出可用性问题并解决这些问题。而目的呢，则是为了让产品用起来更容易。2、可用性测试指标
有效性：用户能够达成自己的目标
效率：用户不必做无用功，就能以最短的途径达成目的
主观满意度：用户在使用产品过程中所感受到的主观满意和接受程度
3、可用性测试类型形成性测试总结性测试
（形成性测试与总结性测试对比图）
形成性测试就像学生读书期间进行的阶段性测验，通过这些测验确定学生对该阶段内容的理解程度，并对自己的教学方法进行改进（形成性测验不是为了打分，而是为了改善）；总结性测试则是检验学生对这学期综合掌握程度，用分数表示成绩，然后分析得分情况。原则上来讲，总结性测试一般在开发后期使用，形成性测试一般在设计过程中反复使用。本文主要描述的是形成性测试。二、什么时候进行可用性测试？可用性测试要尽早开始，所谓越早测试，越早发现问题。适用于【概念原型阶段、产品原型阶段、产品上线前阶段】适用于解决的问题：确定测试产品的可用性水平与预期目标、与竞争对手、与老版设计相比的可用性水平比较不同方案，确定哪个方案更加可行现测试产品的可用性问题三、可用性测试流程
（可用性测试流程图）
1、确定目标可用性测试之前，需要明确这次可用性测试是为了完成什么样的目的，如果没有目标，就像一个没有方向盘的超级跑车，即时拥有最强有力的引擎，最终仍是废铁一堆，发挥不了任何作用。2、确定测试方案确定了目标后，就要考虑测试方案的设置，即如何设计测试任务。在设计任务之前，需要反复问自己的问题：“我设计的测试任务是真的反应了用户的实际目标吗？（而并不是我认为用户想要做的事情）”设计任务的方法：A 列出功能清单首先内部沟通确定一份功能点清单，一般选择产品4-6个功能点进行测试（不宜过多），这些功能点可以是用户常用功能、新增功能、关注度高的功能及先前版本中存在问题的功能。B 将功能变成场景场景是你需要读给用户听或给用户看的内容，必须包含用户的目标和动机，对用户来说，你的功能并不重要，重要的是他们的目的以及完成目的的过程。C 测试大纲测试目的介绍保密协议测试场景操作评分表（主试打分）问卷（被试打分）结束提问对被试进行简要小结D 确定任务需要的准备的资料测试账号工具（写字板、笔记本、录音、录像、软件）计时器文档：测试脚本被试安排表任务卡片记录表问卷保密协议小节撰写礼物收单3、预测试在正式测试前，需要进行预测试和修正情景与任务，可以先请一两位同事，简单的进行一下预测试，主要目的在于核对资料是否准备齐全，整个流程是否能够顺利进行，情景任务是否合理，通过预测试并及时调整这些内容，也能给自己长点信心。4、招募用户A 找什么用户？我们测试中最关注的是用户的操作行为，因此在做用户招募时，更应该关注的是产品使用经验和使用行为，而不是人口统计学特征。step1：从描述开始，尝试描述你想要什么样的用户来参与测试step2：优先关注产品使用经验和行为·与该产品相关的经验，例如相关的知识技能水平，使用基本功能的频次等·与相似产品的相关的经验·用户的网络使用经验，例如上网频率，网络应用等B 找多少用户？根据尼尔森公式“有5人参加测试，就能够发现大多数（约85%）的产品可用性问题。”不过，当任务设置数量过多，且任务的精细程度和难度多种多样时，这个前提可能就会不成立。如果在招募用户时，注重用户的代表性，那么5人就已经足够了，如果代表性不是很强的，就需要超过5个了，原则上一次测试最多不会超过12个用户。
（测试用户选择个数图）
在项目过程中也有一种迭代特快的测试方法，每轮测试3个用户，每轮测试完成后发现问题并修改，接着进行第二轮测试。通常这种测试方法能够快速帮助产品进行迭代。C 如何找用户？有这么一种说法，通过6个人你就可以认识世界上的任何一个人，也就是说我们和世界上的任何一个人都存在间接关系，充分利用你的人脉，无论是找同事、朋友、朋友的朋友，网站论坛广告等，只要快，并且在招募时，坚持要求即可。5、正式测试测试开始前，需要和所有工作人员进行一个简单的沟通：讲解测试的目的，为什么要设置这样的情景任务，需要完成那些重点，在测试的时候有哪些地方需要特别注意用户的操作，如何与用户接触，当测试进行不下去怎么办，发现用户情绪不对了如何安抚，是否需要终止任务等状况。工作人员安排：主持人：串联其整个可用性测试观察者：观察和记录助理：端茶递水加观察接下来终于到了正式测试了~主持人流程大致如下：A 欢迎自我介绍解释测试目的和时间向用户强调测试对象是系统而非用户请用户尽量“出声思维”告知测试会录像，但结果完全保密签署保密协议B 提问职业平时上网情况（每天上网时间，上什么网站）平时使用产品偏好C 测试中宣读任务不要以任何方式表现出用户正在犯错或操作太慢仔细观察，并认真聆听用户的建议识别用户的情绪，必要的适合选择停止任务用户遇到困难的时候尽量不要提供帮助，可给予适当的鼓励在用户完成一个场景时，可简单的问一下“为什么刚才要那样操作”D 提问询问在过程中想要深入询问的问题询问观察的同事关心的问题E 道别感谢用户将用户送出门口保存录像，整理记录以上为主持人流程，那么作为观察的同事，在测试过程中需要记录些什么呢？行为：用户的动作和步骤想法：用户的话问题：记录你认为严重的问题，但不急于写解决方案观察些什么？用户能执行要求的任务吗？期望的信息有没有找到？用户找到有效的途径了吗？用户理解自己正在做的事情吗？他们碰到了什么问题？他们能从错误中恢复吗？倾听和试探仔细倾听用户（如意外的感叹词“哎呀”是一个很重要的数据）注意任何犹豫不决的情况探寻以获得深层次的动机提醒他们把所想的说出来提防暗示性的问题（比如“你会如何关闭一个文件”，问题漏了答案，应该说“这个文档你已经处理完了，现在你会做什么？”）6、数据分析完成测试后，需要主持人和观察人员趁着记忆犹新的时候快速地有用的信息整理出来，可以采用便利贴，把用户相关的操作，提出的问题，和我们发现的问题迅速的写出来，但不要快速下结论。后续与产品，交互等一起进行改进。 这样就差不多完成了一次可用性测试，以上的流程也可以根据自己的实际情况再进行修改。趁着记忆犹新马上整理！1小时测试，30分钟整理如有必要当场检查录像不要评论用户或讨论设计，也不要太快下结论分析是为了马上找出要修复的问题只讨论观察到的情况重点是那些最重要的问题四、可用性测试原则1、尼尔森可用性10原则
可视性原则
不要脱离现实
用户拥有自由控制权
一致性原则
识别好多回忆（让用户选择而不是让用户回忆）
灵活且高效
美观简洁（易读性）
明确的错误信息
帮助与说明
2、施耐德曼八项黄金法则
力求一致性
允许频繁使用快捷键
提供明确的反馈
在对话中提供阶段性的成果反馈
使错误处理简单化
允许可逆操作
用户应掌握控制权
减轻用户记忆
参考资料：可用性测试-新浪UCD可用性测试的权衡快速简单的可用性测试可用性测试用户体验与可用性测试
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
打开微信“扫一扫”，打开网页后点击屏幕右上角分享按钮
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
选择支付方式：