可用性研究

文章为我们梳理了一下用户体验和可用性之间的差异，一起来看看！近年来，用户体验设计作为最重要的设计流程，广为人所知。 而“可用性”这个术语在改善用户体验方面也起着重要的作用，甚至在欧美还出现了“可用性工程师”这一新兴职位。但是术语提到的次数越多，人们对其概念的清晰度理解的就越模糊，尤其是可用性和用户体验这两个极为相近的概念，经常被设计师们弄混淆。虽然厘清两个概念的帖子已经有很多了，但是给予我多年的用户体验设计和产品可用性研究的经验，我觉得仍然有必要再次重新梳理一下用户体验和可用性之间的差异。1、概念界定用户体验是指一个人对使用特定产品的主观感受和态度，它包括功能、品牌、心理预期和实际体验的情感感受，这些都是用户体验中不可或缺的部分。可用性是交互式IT产品/系统的重要质量指标，是指产品的有效、易用、易学、高效、错误少、让用户满意的程度，可用性主要是针对产品的功能来进行的。总之，“别让我思考（Don’t make me think）”。千万记住“可用性错误”犯不得，它很有可能直接摧毁你的网站。【以用户为中心的设计环境中的典型可用性问题有】评估产品的总体有效性和效率，并将其作为设计目标；评估用户的舒适度和满意度，并将其作为设计目标；设计产品使其易于使用，并可评估可用性问题。【以用户为中心的设计环境中的典型用户体验问题有】设计和评估用户从使用开始到结束期间与产品发生的交互行为；最大限度地实现刺激、识别和激发用户情感共鸣。2、可用性的四要素功能：这个产品能否正常工作？易学性：这个产品是否可以在没有额外学习成本的情况下使用？灵活性：除了完成主要任务之外，这个产品可以做更多额外的事吗？工业设计：这个产品够漂亮吗？3、用户体验的四要素可用性：使用这个产品很容易吗？适应性：人们会乐于使用这个产品吗？可取性：这个产品的体验是否有趣有吸引力？价值：这个产品是否为用户提供价值？4、二者的不同目标对于一个网站来说，唯一的可用性目标是“易于使用”，而用户体验的目标是用户在使用网站之前、之中和之后获得的整体感觉。因此，可用性与用户在使用网站时达成既定目标的容易程度有关，而用户体验是关注用户对网站与其交互的感知。 5、可用性在用户体验设计中发挥着重要作用良好的可用性产品使得用户在使用产品时更少的出现错误操作，在产品使用后后感觉有了它，生活变得更方便，快捷，舒适。很显然，良好的可用性会唤起用户良好的情感体验，让用户感到快乐和愉快，从而改善产品的用户体验设计。举个例子来看，想像一下在屋子里有两个盒子——一个大盒子一个小盒子。大盒子很重，想要打开它也很费劲，那么这个大盒子就是一个可用性很差的产品，用户不乐意使用这个大盒子，用户体验很差。相反的，小盒子开合很容易，携带很轻便，那么它就是一个可用性强的产品，用户体验非常好。6、网站可用性和可访问性的区别可访问性是指这个网站能够无障碍地被所有人访问，不单正常人可以访问，残障人士也可以访问。那么在做辅助功能测试的时候要着重于测试残障人士是否能够无障碍的访问网站，同时能够使用网站提供的各种功能。可用性意味着网站网站在被使用的时候是否是简单直观的。如果用户可以在没有任何指示的情况下使用网站，我们会认为这个网站是高度可用的。可用性测试一般侧重于衡量网站的易用性，看看它是否对用户很友好。另外要记住，应该在设计之前进行可用性评估。【结论】可用性涉及有效性、使用效率和满意度，用户可以尽可能简单地完成某些任务；用户体验则涵盖了用户与网站交互的更广泛的内容。希望通过以上的描述，能够帮你清楚地理解用户体验和可用性之间的区别。作者：linda译者：Max小姐原文链接：https://medium.muz.li/the-ultimate-guide-difference-between-usability-and-user-experience-afb757ded1c4本文系人人都是产品经理翻译团队@Max小姐 翻译发布，未经本站允许，禁止转载。题图来自unsplash，基于CC0协议

工作中在遇到大的产品改版，或者对某个设计拿捏不准的时候，经常会使用到可用性测试。在网上搜索可用性测试相关的文章，大多都描述的非常专业，很容易让初学者望而生畏，尤其是让很多初级产品经理或者小型初创公司觉得太专业没有资源，所以干脆不做。而笔者的看法是这样的：要做到完全符合流程和标准的可用性测试，确实有一定难度，需要的成本也很大，但是，需要注意的是：我们做可用性测试的目的不是“做可用性测试”，而是“发现用户真实使用情况中遇到的问题，来提升产品的可用性”，所以，目的最重要，只要能达到这个目的，流程完全不必如此复杂，有些可以省的步骤当然可以省，只要最重要的核心流程和注意点我们把握好即可。另外，可用性测试一定要做，从原型设计到产品发布，任何阶段都可以做，有什么样的资源就做到什么样的程度。可用性测试是一种定性研究方法，有研究称，只要5个人就可以发现大部分共性问题，而这大部分共性问题，在版本发布前发现并解决掉，是一种非常节省资源，规避风险的方法，甚至有时候可以救产品一命。脑补一下，某个产品进行了一次大的改版，产品经理们觉得这次改版非常棒，老板也觉得很满意，然后释放给用户，用户反馈和数据都非常糟糕，那么这个时候，想要再补救，需要投入的成本就会非常大，最重要的是，用户很容易产生晕轮效应，使得产品其他优秀的点也会被牵连，这对于导入期和成长期的产品来说非常不利，很可能会导致用户的流失。原因很简单，产品经理往往对自己的产品太熟悉了，就会发生太多的想当然。怎么做下面，笔者将会走一遍标准的可用性测试流程，阐述一下那些必须做到的点，和那些大可不必较真的流程。第一步：资源准备资源准备包括测试环境和工具，包括办公室、观察间、网络、测试设备（手机、电脑等）、麦克风、录屏软件、屏幕共享软件、摄像机、眼动仪等。这些资源里：办公室可以用会议室代替；测试人员和用户可以坐在一起，所以观察间可以不要；只要测试的功能不牵扯到网络使用，网络可以没有；屏幕共享软件和麦克风主要用于测试人员在观察室进行观察，也可以不要；眼动仪主要用于跟踪眼球运动，可以省略；录屏软件用于将屏幕记录下来，也可以省略，但是免费的录屏软件非常多，建议还是安装一个。那么剩下的，就是测试设备，测试设备当然是不能省略的了，因为这是测试的基础，用户总得有可操作的东西才可以进行测试。可以看到，资源准备的时候，在最简陋的情况下，我们只要准备测试设备，和一个会议室就可以了，当然，测试人员需要准备纸笔做好记录。第二步：任务设计任务设计就是准备你要用户去做的事情，这一步当然是不可避免，而且必须去做好准备的，这样才能将每一次测试的收益最大化。准备任务的时候，产品经理首先要明确一个问题：此次测试的目的是什么？是测试整个改版后的产品？还是测试某个功能的可用性？或者只是测试某个功能的视觉效果？目的很重要，目的不同，我们设计任务的时候，问题的维度和场景就会有区别。接下来根据我们的目的，来设计测试任务，这里有几个需要注意的点：（1）一定要站在真实的用户场景来描述问题比如：使用下XX产品的录音功能，这样可能看起来没什么问题，但是笔者在以前做可用性测试的时候，发现这种问题会使得用户操作起来没有明确的目的性，那么他们面对这种问题的时候，大部分用户都是瞎点击，随便点点就返回。如果我们这么问：假设你想用XX录音软件，录制一段歌声给你的男/女朋友表白；假设之前开会的时候，你通过录音机记录了会议过程，你现在想找到它并听会议内容。这两个问题就是有明确的用户场景，那么用户在操作的时候，我们观察到的也就是用户在真实生活中的实际可能的操作步骤，发现的问题也就是用户实实在在会遇到的问题。（2）在问题描述的时候，千万不能有任何引导性语言比如刚才这个寻找录音文件的例子，如果我们这样提问：假设之前开会的时候，你通过录音机记录了会议过程，请你现在进入录音列表，通过快速滚动条滑动找到它，然后点击听会议内容。这个问题就明确地引导用户怎么去操作，但是用户真实使用中，一定会这么做吗？也许用户根本不会用到快速滚动条？如果这么描述的目的是为了看用户使用快速滚动条的情况，那么最应该的做法是，不告诉用户滚动条的事情，让用户自己操作，看用户是否会发现快速滚动条，发现后是怎么操作。笔直之前做的一个可用性测试即是想看到用户对快速滚动条的使用情况，结果非常吃惊，大部分用户没有发现这个滚动条的存在，而发现的用户居然不会使用，或者不知道是快速滚动条。我想如果在测试前告诉了用户滚动条的事情，那么也就无法发现这些问题了。第三步：用户招募一般情况下，需要寻找产品的目标用户做可用性测试，我们可能需要在网上公开招募，或者通过公司的资料库联系用户等方法来寻找测试用户，但是很多情况下，我们无法快速寻找到合适的测试用户，这个时候其实不用那么死板，可以稍微转下脑筋，就近考虑，是不是前台小妹或者楼下保安也可以做为测试用户呢？再简单一点，隔壁产品组里，对我们产品不怎么了解的工程师是不是也可以呢？用户招募只是其中一环，我看到有些同事为了招募用户耽误了大量的时间，其实是得不偿失的，尽快进行测试的重要性更高，因为项目排期和交付日期可不会因为用户招募需要时间就延迟的，而如果因为用户招募导致没来得及做可用性测试，那真的是非常可惜了。有数据称一般情况下，只需要五个用户即可发现大部分共性问题，但是如果找不到，根据经验三个用户也是可以发现大部分的严重问题，所以在用户招募方面，不要太严格和死板很重要。第四步：测试执行执行测试过程的时候，有观察室、录像机、屏幕共享软件等完备的测试环境当然最好，不过这里只描述最简单的情况：不需要主持人，产品经理做测试人员，一个会议室和一个测试设备。首先，我们要向用户说清楚此次测试的目的，并记录下用户的基本情况，尽量以聊天的方式进行，让用户尽量放松，不要感到压力。如果用户很紧张，那么测试结果可能会大打折扣。另外，不要用太专业的术语和用户沟通。接下来我们就可以让用户按照之前准备好的测试任务进行操作，这个时候，测试人员需要在一旁用纸笔做好记录。测试过程中，有一些点是测试人员一定要严格注意的：（1）测试过程中，不要去打扰用户，也不要给用户任何提示，所有的问题都等到测试结束再进行询问和沟通有时候在测试的时候，测试人员看见用户遇到了障碍便去进行提醒或者提问，这是不可取的方式，因为真实用户场景中，不会有人去提醒用户，而测试中所做的任何提示，都有可能导致问题无法暴露，这个时候应该做的事情是用纸笔记录下来，并在测试完成后，和用户进行沟通，询问用户当时在这里出现障碍是遇到了什么问题，当时自己是怎么想的。另外还存在一种情况，就是用户遇到问题的时候，会主动问测试人员，这个时候笔者给的建议是，直接回答用户：我也不知道。当然有一种极端的情况，用户实在是操作不下去了，那这个时候就必须给用户一点提示了，否则也许测试过程没法继续进行了，这个度需要测试人员自己做好权衡。（2）测试人员要随时观察用户的表情一般情况下，测试人员只会注意到用户操作过程中的操作手法，而不怎么注意用户表情。而很多情况下，用户可能遇到一些小的问题后，直接放弃操作去做其他事情，这个时候如果只看用户操作，可能会忽略掉这种问题，但是如果观察用户表情，可能会发现用户出现皱眉或者微笑等一些明显的表情变化，这个时候将用户表情和当时在进行的操作进行联系，测试完成后和用户进行询问沟通，往往可以发现一些问题或者一些惊喜。（3）要求用户进行测试的时候，使用“发声思维”很多时候，用户说的和做的是不一样的，而且在测试完成后，和用户再进行沟通，用户可能已经忘记了，那么他们这个时候的描述和当时的操作可能就会存在差异。而“发声思维”可以很大程度解决这个问题，即用户在操作的时候，让用户同时说出来，说出自己的思考过程，比如：自己要做什么事，先做什么，再做什么，为什么要这么做等。这个时候，一旁的测试人员只需要做好记录和观察即可。第五步：报告呈现报告尽量简短，形式不重要，重要的是内容和可读性，一般要包括测试对象的基本信息、测试的任务清单和测试结果、用户反馈以及问题整理整理和改进建议。另外，笔者建议测试报告尽量包括测试过程的简单描述，对以后回顾问题的时候会有比较大的帮助，当然这部分可以不放到测试测试报告的正文里，如果用xls整理报告，可以在其他表单里记录。最后一步：问题解决这一步才是可用性测试最终实现它价值的地方。经过前面四步，我们已经得到了测试的结果，那么接下来就需要产品经理将这些问题进行归类，并进行需求分析和优先级评估，确定出需要修改的问题，进行排期，这就是产品经理的日常工作了。最后的最后：其他需要注意的点（1）针对某次发版的可用性测试一般建议不能做太晚，如果等到产品快上线了，才做可用性测试，并且发现了很严重的问题，那么这个时候就有点于事无补了。所以，在做可用性测试的时候，有产品就用产品测，有Demo就用Demo测，有原型就用原型测，什么都没有，也可用用竞品做测试，这样避免我们去 踩竞品的坑。（2）可用性测试什么时候都可以做，要贯穿到整个产品的设计过程中，作为产品经理的一项基础日常工作，想想看，如果我们可以用上述的“简版”可用性测试方法，性价比还是很高的，比如笔者曾经做过一个可用性测试，用户招募就是简单的从公司里找了一些小白，测试的功能是通过带有时间的快速滚动条来快速定位图片（测试之前，快速滚动条的样式是半黑透明，上下端是两个小箭头，点击该滚动条出现时间，用户可以开始滑动，停止点击几秒后，时间消失）但是通过下面的测试结果看到，如果没有这次的可用性测试，那么这个功能释放给用户后的结果将是：无人使用。而这整个测试过程，当时只花费了2个小时。所以“简版”的可用性测试的性价比真的非常的高。（3）针对来测试的用户，在测试完成后，给用户一些实际的奖励，比如可以准备一些奖品或者纪念品给用户，也可以奖励用户一些产品的虚拟货币或者积分、虚拟宠物之类的，并且和用户进行友好的沟通，询问用户是否愿意接受以后的测试。这些都会更方便以后做可用性测试招募用户。总结如标题，可用性测试真的很难吗？我想看过这篇文章后，读者会有自己的见解。笔者在这里只需要强调一次前面已经说过的话：可用性测试一定要做，从原型设计到产品发布，任何阶段都可以做，有什么样的资源就做到什么样的程度。本文由 @Monica 原创发布于人人都是产品经理。未经许可，禁止转载。题图来自 Unsplash，基于 CC0 协议

本文聚焦Airbnb产品，描述10大可用性原则的应用场景，希望能够帮助你更系统地理解10大可用性原则。一、系统状态的可见性Visibility of system status“The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.”by Nielson系统应该在合理的时间内通过适当的反馈，始终让用户了解正在发生的事情。这项原则通常被遵循并使用在如下几个场景：系统导航、面包屑。让用户明确知道“我在哪”；按钮、图片等元素可被交互的表达与反馈。通过视觉、与空间上的反馈，向用户传达页面元素是可以被交互的，引导用户前往下一站；用户完成交互动作和系统操作后，系统需要给予用户对应的反馈。比如操作成功、完成注册等…；…Airbnb的房源详情页顶部导航，可以通过点击快速定位到房源的某类信息，让用户清晰地知道“我在哪？我还能去哪？”在发布房源时，系统顶部模拟了进度条，显示出了当前步骤，以及当前的发布进度。二、贴近用户的真实环境Match between system and the real world“The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.”——Nielson 系统应该说用户的语言，用户熟悉的单词，短语和概念，而不是系统导向的术语。遵循现实世界的约定，使信息以自然和合乎逻辑的顺序出现。这项原则说的直白一些，就是：“说人话”。产品简单到傻瓜也能操作，是乔布斯和张小龙做产品的核心理念。坐拥10亿用户的微信之父张小龙说过，做产品要有傻瓜心态。不要炫耀自己的智商，不要让用户觉得自己是白痴，请用最简单直白的语言描述状况；就好比自然世界里，你和他人说话的时候必然使用简单的白话文进行直白的沟通以保证交流顺畅。在房源的详情页、Airbnb PLUS介绍页，系统用了大量高质量的摄影图片传达一种空间氛围感。同时，在介绍文案的措辞方面，简洁易懂，语言逻辑清晰。三、用户有控制和来去自由的权利User control and freedom“Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.”——Nielson用户通常会错误地选择了系统的某个功能，并且需要一个明确标记的”紧急出口“来离开不想要的状态，而不必进行扩展对话。支持撤消和重做。用户拥有自由使用和控制系统的权利，最为常见的就是系统会为用户提供“撤销、重做、返回”的入口。在故事专栏，当用户在浏览器当前标签页进入下一级页面时，系统都为用户提供了返回按钮，一方面方便用户来去自由，另一方营造出了一定的沉浸式浏览体验。四、系统的一致性Consistency and standards“Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.” ——Nielson用户不应该怀疑不同的话语、情况或行为是否在表达同样的一件事情。系统设计需遵循平台惯例。移动端APP内的返回按钮位置通常会被放在左上角，当然有些APP会将返回按钮统一放在左下角，虽然返回按钮的位置不同于大多数APP，但对于此APP的返回交互来说，其实还是一致的；除常用按钮位置需要符合一致性原则外，icon的视觉设计也要遵循一致性原则，一个对象对应一个icon.在房源、故事集列表页，系统统一用了卡片式的视觉风格，并且每个卡片里的文字与背景图片的层次也都保持一致。在房源详情页，系统使用了统一的iocn风格和文字风格，传达房源的设施属性。五、防止错误Error prevention“Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.”——Nielson比良好的错误提示信息更好的方法是：一个走心的设计可以提前防止错误的发生。系统要么消除容易出错的情况，要么检查它们，并在用户采取行动之前向用户提供确认选项。比如某些操作不能进行，那就置灰或隐藏，不要在用户点击后才提醒不能操作。如果有某些内容不能选择，就置灰或者隐藏，不要等用户点击完成时才告知不能使用；同样，在用户容易出现错误操作的场景下，需要给出二次确认，如：删除和取消重要信息的操作。如果房源在某天或多天已被预定或暂时不开放，则日历里将这些不可预定的日期置灰。用户在修改个人重要信息后，系统会让用户输入密码二次确认。六、系统识别胜过用户记忆Recognition rather than recall“Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.”——Nielson通过使用对象，动作和选项的可视化表达，最大限度地减轻用户的记忆负担。用户不应该记住从对话的一部分到另一部分的信息。为用户保留查看和搜索历史是一个很常见的系统识别的例子；用户在填写一个长页面表单时，系统可以根据实际情况提供一个实时预览的功能，避免出现用户填了下面忘了上面的情况；用户在填写完表单（比如订单页面）后，系统可以再次向用户展示所填信息，以最终确认；用户为了完成一项目标任务，从一个页面跳转到另一个页面后，系统可以再次展示上一个页面内与目标任务相关的核心信息，以减轻用户的记忆负担。系统会在首页第一屏为用户展示浏览历史（登录后）。搜索框也会保留最近5次的搜索历史七、灵活易用的使用体验Flexibility and efficiency of use“Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.”——Nielson一些被精心设计的体验也许会被专家用户察觉到，使系统需要能够满足无经验和有经验的用户。允许用户进行频繁的操作。当用户在滚动屏幕浏览房源详细信息时，系统将预定的基本信息（如：价格、日期、人数等）固定在浏览器的右侧，方便用户在浏览过程中随时开始预定步骤。八、美观和简约的设计Aesthetic and minimalist design“Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.”——Nielson对话中不应该包含无关紧要或很少需要的信息。在对话中每增加一个相对重要的信息，就意味着需要弱化其他信息。高颜值不需要理由。九、帮助用户识别、诊断，并从错误中恢复Help users recognize, diagnose,and recover from errors“Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.”——Nielson错误信息应该用通俗易懂的语言表达（不要用代码），较准确的反应问题，并且提出解决方案。实在无法避免的报错时，不要单纯只是报错，要提供解决方案。就好比小时候犯错，你绝不能光说：“啊，我错了。”老师或家长必然会：“错哪儿啦？”你要是说不出缘由，则必定被认为认错不诚恳不真心。当用户填写错误时，系统会及时给出提示以及解决方法十、帮助文档Help and documentation“Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.”——Nielson 如果系统能让用户不需要阅读文档就会使用那是最好的，但通常情况下还是需要帮助文档的。任何信息应该容易被搜索，且专注于用户的目标任务，并列出具体的步骤来告知用户。对于一些可以用一句话说清楚的帮助，可以直接在对象旁边提供鼠标悬停出发的tips，或者简明的辅助说明；对于较复杂的，一两句话说不清楚的帮助，则需要跳转至对应的帮助页面；系统需要有一个帮助中心，为用户提供模糊搜索、分类搜索，来为用户提供更全面的帮助。在个人资料页面，对于用户关心的隐私信息，系统会给出非常有亲和力的解释文案。此外，在系统很多页面都有对应功能的帮助链接以跳转至帮助中心。系统的帮助中心，提供了搜索和问题分类引导，方便用户快速定位问题。总结号称以设计驱动的Airbnb公司，的确在产品设计、用户研究、UX设计方面展现出了较高的功力。网站甚至移动端APP的框架层、范围层、视觉层的设计都体现出了高度的用户体验一致性和品牌感。可以看出，Airbnb对design system的重视一级高度的执行力。什么是好的产品品牌认知和识别，我可以简单的理解为：“脱掉”Logo，用户照样认识你。感谢你的阅读，我们下期再见…（本文图片版权归Airbnb所有）作者：王晗陵，微信公众号“从你的视界路过（ID：wanghlnj1）”本文由 @王晗陵 原创发布于人人都是产品经理，未经作者许可，禁止转载。题图来源于网络

编辑导读：可用性测试，能够让产品经理借助用户，更加客观理性地理解产品功能以及交互，并结合测试结果予以改进。本文作者从远程可用性测试的概念出发，结合案例分享了创建一个有效的远程可用性测试的具体流程和相关技巧，供大家一起参考和学习。现在大部分用研的小伙伴，每一次做可用性测试都需要邀请参与者在现场完成任务，观察并注意他们的行为，然后总结得出结论。没有远程进行可用性测试，因为在底层认知内是必须在同一个房间做任何类型的用户体验研究才能获得数据。现在国外和国内大厂的远程可用性测试就是很普遍化了。那么我们该怎么找到适合现状的远程可用性测试呢。一、什么是远程可用性测试？远程可用性测试是指参与者和研究人员在不同地点进行的测试。随着技术创新的推进，远程测试在实践中有所增加，在线工具也为远程测试提供了便利。会话通常通过可用性测试平台进行（不打广告，自行百度），它记录完成测试的人员，收集数据，并生成报告。远程可用性测试的好处：可以更好地找到参与者，因为他们可以不用坐着公交来到公司进行参与，参与者可以在任何他们想要的时间以及他们想要的地方进行测试。有足够的定量数据支撑创建测试和获得结果之间的时间要短得多，可以非常快速地获得数据驱动。开销-为公司节约成本。不需要包路费或者足够的送礼品。远程发个红包，也能表达感谢之情。远程可用性测试的缺点：总体测试环境和过程的控制较少。例如，如果任务不清楚，就不能在那里更详细地解释它，并将其引导正确的方向。解决方案：为了最小化这些风险，在测试开始时介绍性的讲述缘由，以便参与者知道将要发生什么，也请告知参与者测试的目标，并确保他们掌握了所有必要的信息来理解所参与的内容。远程测试进行试验需要确保编写任务的方式非常清晰。远程可用性测试并不比面对面的测试工作量少。它通常需要更多的计划和更多的交流。因此，要做好相应的计划，确保你要使用的工具和设备工作正常。需要给某些可用性测试平台付费彩蛋：共享屏幕的进行操作，然后你录屏。嘿嘿，曾经我就是这么做的。后来我们公司，受不了大型的视频文件了，决定自己开发一个系统。二、进行远程可用性测试的最佳时间是什么时候?是在设计过程中的任何时候。只要第一步任务的编写完成了，那么远程测试比现场测试进行起来更快更容易，因为可以无限的复用。对于，某些公司缺少启动资金，又想做的专业，那你就需要试试我的建议了。可以确保您的迭代始终得到数据的支持。或者不甘于在做画图仔的小伙伴，可以试着推动一下。你只需要做到编写任务，确保任务流程非常清晰后。召集你的调研对象发送链接（怎么让用户点击产生时间不用我说了吧）完成录屏分析记录的数据以及谢场三、创建一个有效的远程可用性测试的5个技巧要真正看到远程可用性测试的好处，您必须以一种能够获得可操作结果的方式来设置您的测试。远程测试并不意味着更少的准备或计划。相反，它要求以最好的方式设置测试，以获得有效的结果，从而帮助您学习并根据收集到的数据采取行动。1. 选择正确的测试类型远程可用性测试有两种类型:中度测试和非中度测试。除了主持人和用户不在一个房间之外，主持测试的工作原理与传统的现场可用性测试基本相同。主持人需要用到腾讯会议这样的软件去观察视频通话中的用户。这样做的好处是：仍然可以向用户询问尽可能多的后续问题，此外，用户也不需要长途跋涉到公司参与。（像我们公司做B端产品的，运营分布上海、重庆、合肥。你说香不香。）缺点是：它仍然需要参与者在一定程度上的投入——他们必须在特定的时间使用特定的设置来完成测试，而额外的交流使得整个测试过程更加耗时。所以就看你在开局时能不能编写好剧本了。要点：对于更传统的可用性测试过程，可以使用温和的远程测试；对于资金不足的、想专业性的、定量的、节省时间的方法，可以采纳远程可用性测试。2. 缩小你的范围测试的范围可以决定它成功的机会，也可以决定它失败的机会。很显然，我们大家都需要在某个时候对产品的每一处的功能都要进行测试。但是对于远程测试，最好采用测试特定的流程，而不是把所有东西都放在一个大型测试中。这有几个原因：首先，把你的测试集中在几个假设上，不管怎样都会使你的结果更加清晰。一次测试的设计越多，测试的时间就越长，结果也就越模糊。耐心嘛，总归是有限的。我们应该给参与者更少的选择，这样可以精确地确定设计决策并更严格地测试它们。第二，测试越短，用户越有可能完成它。还是那句话，注意力也是有限的。因为我们无法在现场指导他们的方向（远程沟通的弊端）。如果他们不能坚持到最后，你将会得到扭曲的结果。我的建议：是将任务分成七到八个小任务的远程可用性测试。好的方面是：可以更频繁地运行小型测试。弊端就是：你需要做的复杂一点了。中度测试：可能稍微复杂一点，因为你可以就参与者发现的问题进行完整的对话，并对他们是如何陷入困境的来做笔记。由于这些测试需要更多的时间来安排，你可能需要更深入地挖掘以最大限度地利用每一个测试。（在远程可用性测试方面，我不大推荐这么做。）要点：为了获得更清晰的数据模式、也为了确保人们完成。远程测试不应该超过七到八个子任务。非中度远程测试可能没有那么集中，但同样的原则也适用。3. 尽快开始寻找参与者为什么说到尽快呢？因为最根本的就是防止自己出错！及时止损！请记住，远程可用性测试的主要好处之一是能够使用大样本进行测试。所以你能找到的用户越多越好。（建议：寻找具有特定背景或职位的用户）因为远程测试是属于定量的。（现场可用性测试的话会更加偏向于定性）别再搞混了，在搞混直接打死！如何找：C端，很常见的就是从运营手里找用户，或者从反馈问题的页面找到联系人。C端找人太简单了。我就很喜欢去反馈。B端，这个就要分业务场景了，是包装后准备售卖还是以代运营的方式。自己公司就好说，代运营得从业务部门沟通开始安排时间。搭建访谈记录池要点：准备充分！及时止损！寻找特定背景/职位用户！4. 创建任务当您为远程可用性测试创建任务时，清晰是非常重要的。写得好的和结构化的可用性任务会给你带来更准确的结果。要点：确保目标的一致性：你想到的产品使用目标和用户在使用你的产品时所想到的目标是一样的。提供产品背景：提前告诉参与者这个测试——它是针对什么项目的，你想要的数据类型以及设计，而不是他们自己。这会帮助他们理解你要求他们做的事情。从简单的开始：通过简单的开始任务给人们一个机会来适应测试过程和产品。使用简洁的语言：避免使用内部术语或技术术语，因为它们可能会使人困惑。找个文化水平好一点的大师，让他们教教你。哈哈哈，我经常被吐槽。专注于一件事：想让用户在完成一件事之前一定要专注现在的事情。这将防止他们不知所措，并帮助您精确定位数据中的设计缺陷。遵循流程：请按照产品中的常见、常规的操作流程去进行测试，这样测试数据就更加真实。不要透露答案：给人们情景，而不是方向。“你找到这个列表，点击这个编辑，然后填写数据，最后点击完成”兄弟们千万不要这么做啊！！！这个过程太精确了——可用性测试的目标是看看人们是否可以在不提醒的情况下完成你的产品的实际任务。要点：如何编写和组织任务将在很大程度上决定远程可用性测试的成功与否。根据用户的目标使用简单的语言，避免让任务太复杂或太明显。5. 问一些有效的问题来获得更丰富的见解提问是在远程可用性测试中获得更多反馈的一种方式。在每项任务结束后跟踪参与者，了解他们对具体设计元素的看法，或在测试结束时提出一般性问题，以获得定性反馈。因为你需要为远程测试提前写好问题，所以它们需要是完美的。这里有一些建议:把开放式的问题留到最后，询问某人的整体经历可以让你得到详细、定性的回答。下面是一些我会经常问到的可用性测试问题的例子:你完成这项任务后的感觉如何?你觉得这个设计总体上怎么样?您如何看待信息和特征的布局?最后在拼死压榨一下，填写一下系统可用性度量表(SUS)的问题。这是一个经过测试的可用性调查，经常被用来衡量产品的可用性。SUS甚至会在最后给你的产品一个可用性评分。计算评分如下：计算SUS得分的第一步是确定每道题的转化分值，范围在0-4。对于正面题（奇数题），转化分值是量表原始分减去1（X-1），对于反面题（偶数题），转化分值是5减去原始分（5-X）。所有题项的转化分值相加后乘以2.5得到SUS量表的总分。所以SUS分值范围在0-100，以2.5分为增量。你也可以问一些人口统计问题来根据年龄、职业、教育等对用户进行细分。这对于发现不同人群的可用性趋势很有用。隐私就别问了啊。要点：措辞精准、请反复核对。四、结合Think aloud完成可用性测试（这一点是根据一位不知名的网友提供的。虽然他单词拼错了，哈哈哈可我还是依然给他置顶了评论)。Think aloud释义：Think aloud 是可用性测试中常用的一种方法，它是由IBM公司Clayton Lewis 在1982年在 《以任务为中心的界面设计》书中被阐述，同时引进到了可用性领域，1993年由前苹果研究院VP的Jakob Neilson在可用性工程这本书中再次推出。使用 Think aloud方法，需要提供给被测用户待测的产品或界面原型，要求被测用户根据指定任务操作产品或界面，与此同时，即时地说出使用产品界面时的想法、感受和意见。Think aloud适合在产品设计的任何阶段使用，并且适用于各种形式的产品原型，对于用户路径，界面信息构架，误操评估等有快速有效的校验作用。我在以往做可用性测试的时候，往往会忽视了参与者的即时感受。除非他自言自语，我找不到这个功能在哪了，那会儿我才反应到他为什么出现认知错误了。现在经过他的留言，我才反思到是我过度的专注于实操和他的表情了。希望小伙伴们要注意哦~本文由 @交互思维铺子 原创发布于人人都是产品经理，未经作者许可，禁止转载。题图来自Unsplash，基于CC0协议。

可用性测试，能够让产品经理借助用户，更加客观理性地理解产品功能以及交互，并结合测试结果予以改进。1. 可用性测试介绍1.1 可用性测试（Usablitity Testing）不知道你作为产品经理、交互设计或视觉设计时，会不会困惑于功能操作是否合理，交互是否流畅，视觉提示是否能够引起足够注意等问题。由于设计人员对自己的产品和功能的交互设计过于了解，往往无法客观判断其可用性，这时候就急需对用户进行可用性测试。可用性测试是指让一群具有代表性的用户按照指令对产品进行典型操作，同时观察员和相关人员在一旁观察、聆听、记录。该产品可能是一个网站，软件，或者其他任何产品。可用性测试可以是早期的纸上原型测试，也可以是后期成品的测试。随着现在的工具越来越敏捷，即使是低保真的交互原型图也可以通过类似于墨刀或者Figma等工具，可以让用户直接上手进行简单交互操作。1.2 可用性测试和深度访谈之间的差别可用性测试偏重于观察用户使用产品的行为过程，而深度访谈一般是洞察用户动机、态度、诉求为导向，通常深度访谈需要更加关注不同城市、性别、年龄段、收入等方面的用户，了解不同类型用户之间对产品态度和诉求之间的差异。一般的可用性测试在以上方面的影响是比较小的，一般来说，对同个城市5-6人进行可用性测试，就基本能够暴露产品的一些共性的问题，满足一个快速洞察其可用性的测试需求。1.3 对产品的意义可用性测试可以发现用户和产品之间存在的交互问题，了解产品的可用性水平。在可用性测试中加入A/B Test测试，帮助判断用户方案的偏好。在完成可用性测试之后，整理研究数据，通过报告输出的方式，进而对后续产品优化具有指导性意义。2. 准备工作2.1 评估模型可用性测试主要围绕有效性、效率性、满意度进行展开：有效性（Effectiveness）：任务完成情况；效率性（Efficiency）：任务完成时间和完成路径；满意度（Satisfaction）：用户自我报告数据。针对以上三点，将效率性的完成时间和路径进行拆分，可以得到以下四个评估模型以及标准。2.2 提纲准备可用性测试的提供是依据预先制定的测试目的，分解目的，列出任务列表，将任务场景化，来编写提纲。暂且用以微信理财通举例，测试用户购买理财产品的可用性。购买的任务可以分解为：进入理财通随意浏览并对比理财产品的收益选择一个理财产品并买入该产品管理和查看收益卖出该产品在这个基础上对于任务进行场景化设计：场景：您刚刚发了工资，了解到微信理财通可以购买理财产品，准备以此来购买理财产品。任务一：请在微信中找到购买理财通，并进入；场景：为了了解理财产品的性质和收益的不同，您想要对比一下再进行购买。任务二：在理财通中随意浏览对比理财产品，并选择一个想要购买的产品。…以上只是我提供的一个思路，意在说明需要拆分单个的操作步骤，再适当整合并进行场景化设计对用户进行测试。提纲的编写应该始终围绕用户使用目标，难点在于：顺序的设置，应符合典型用户的操作流程，操作舒适自然，符合常态；任务描述方式，避免直接指出指导操作，不能过于详细，但也不能过于宽泛，而产生歧义和茫然，需要掌握描述的平衡点；控制任务数量，测试时间过长用户会疲倦，任务的保留和舍弃思量也相当重要。2.3 资源&人员准备资源准备包括测试环境和工具，包括办公室、观察间、保密协议、礼金、网络、测试设备（手机、电脑等）、账号预登、麦克风、任务卡、录屏软件、屏幕共享软件、摄像机、眼动仪等。比起深度访谈，可用性测试需要用到的仪器较多，一定要提前抵达办公室，进行调试。在上一个用户测试完后，一定要恢复初始化状态，清除数据等，便于下一个用户测试使用。人员准备，除了记录员和相关人员的就位，主测人员需要熟悉产品，能够全面体验所测试的功能界面，知道用户说的是什么，以及当用户进行提问时，能够解答用户问题。2.4 测试预演测试预演非常重要，能够帮助了解提纲任务设置是否合理流畅，验证时间是否在预想内，主测人员会不会有什么卡壳或者对产品也不熟悉的地方等等，测试预演完成之后，一般都会再进行提纲的修改。修改完成后可以再进行预演，能够在时间和流畅度上有把握之后再进行正式测试。3. 用户邀约3.1 用户选择甄别用户需要问卷调查建立有效的甄别条件，立足自身产品，选取有效的维度标准，可能需要知道用户的年龄、性别、使用频率、个性特征等甄别是否为典型用户。如果不是针对性强或者专业性强的产品，用户挑选也不必过于严苛，可用性的关键还是普遍兼容，任何人都可以上手使用。但一般来说，对产品的使用&熟悉的程度对可用性测试的结果影响较大，用户甄别时，需要选取一定比例从来没有使用过该产品的用户。3.2 用户邀约和double-cheek通过电话的方式与测试用户进行邀约，电话中一定要告知一些关键信息，和用户确认时间和地点。不管是一般的用户访谈还是可用性测试，用户爽约的情况时有发生，所以在开始前一天的晚上也要再提醒测试用户，确认是否到场。本文由 @舒季 原创发布于人人都是产品经理，未经许可，禁止转载。题图来自 Unsplash，基于CC0协议

可用性测试，能够让产品经理借助用户，更加客观理性地理解产品功能以及交互，并结合测试结果予以改进。01 测试现场1. 用户发声思考练习不同于其他用户研究方式，可用性测试尤其关键的一点是用户的发声思考的练习，发声思考直接影响可用性测试最后的效果和结论。在破冰、保密协议和流程说明等基础步骤完成之后，可用性测试的第一步即是用户发声思考练习，在提纲中可以使用一个简单的例子来使用户得到练习，举个例子：主试：“下面我们进行出声思考练习。请在执行每一步操作时，用语言描述出你当前的感觉和想法。比如：我准备打开菜单，我正在寻找某功能，我现在觉得很迷惑等等，任何想法都可以说出来，不需要刻意去思考，这有助于我去了解你的想法和感受。接下来，先由我示范一下出声描述的做法。我将进行出声思考示范：为了会议不迟到，需要设定第二天7:00起床的闹钟。”主试人员示范后，请被访者练习。练习完成之后，主试可以说：“现在您已经了解如何进行边操作边描述，在之后的任务操作中，请尽量保持。在测试的过程过，如果用户不进行出声思考，不便于现场对其操作进行判断和，后期数据整理时，不便于回看追踪和统计问题。2. 把控时间，适当提示除了发声思考练习，主试可对用户说明：在完成任务之后请告知任务完成；在探索之后仍然无法完成任务时，可以求助或者告知无法完成。用户主动的说明可以更为快速知道用户的难处，便于之后的询问，另一方面可以有效提升测试的速率，不会一个任务上死磕，拉长整个测试时间。同时也需要主试人员观察用户的操作和表情，进行适当的提示，并且在大纲中记录是提示后完成的任务，在现场进行询问。另外，测试时候需准备“任务情景卡片”，卡片可用较大的字将每一个具体任务打印下来，每出一个测试任务，主试展示一个。如果仅仅是主试人员表述任务，用户很有可能不清楚具体任务，或者在操作一半后遗忘。3. 根据情况及时调整问题和用户在发声思考完成测试任务时主试可不说话，测试中一定要观察用户的表情变化，当用户出现思考、犹豫、惊讶、皱眉等表情时，可进行简单询问。不必完全按照大纲设置的问题进行询问，可针对当下用户个体表现的差异性进行。的方式可以采用一般疑问的方式，客观具体的重复说一遍他刚才的行为，询问“为什么”会出现刚刚的行为。如果用户能较快和肯定说出原因，则表示信任度较高，但如果他很犹豫、很难以说出原因，就不要再，不要让用户太为难。有时候用户的困难和反应是我们设想之外，所以对其进行具体问题原因才便于后续进行设计，在说出具体的问题原因后，也可以询问用户的期望，但是因为用户对于产品一定程度上是片面的，所以建议可以收集作为参考，但不一定要完全采纳。如果用户提出了很好的建议，应表示鼓励和夸奖，认同其价值，即使他提的建议不合理，也不要否定对方，我们要做的是鼓励对方，让对方有参与感。4. 可能出现的问题和解决测试的现场一定会产生一些突发的情况，主试需要掌控局面，关注用户的心理。例如：操作过程中，如果出现了BUG等情况，及时告诉用户这是产品问题，不要给用户造成压力；主测需要对测试的产品足够的了解，如果碰到用户提出的问题无法解答，如果现场有另外的人员在场可以在合适的适合进行询问解答疑惑，实在不知，那么直接告知用户不知，测试后会再去了解。5. 现场注意点1）将大纲打印出来，主试人员也需要及时在大纲上面进行记录，便于后期内容整理；2）可用性测试仅针对交互操作，不对态度，切记不要在态度和需求上面进行过多的纠缠和讨论；3）用户可以提出建议和方案，但是不要强制用户提出；4）针对测试部分，如果和一些功能存在耦合情况，可以直接告知耦合部分的名词和使用方式，避免耽误进度；5）如果测试项目较多，可以在完成一个部分后进行简单的几分钟休息时间。02 数据和报告1. 数据整理测试完成后，如果时间允许，趁着记忆犹新，就尽快对数据和内容进行整理。测试场数较多之后，记忆就会出现混淆和遗忘，之后再整理数据或者内容就需要在反复去核对录制视频和翻看主试的笔记，会稍微麻烦。另外，我们需要提前设计数据整理的表格，表格内容通常包含：任务、完成率、任务完成时间、满意度评分、标准/错误路径、可用性评价等信息，数据整理表格可以让数据更加清楚，也方便抓取不同的数据给不同职能部门的人。此处的表格应尽量详细，做完后提前和相关人员进行沟通是否全面。2. 数据分析和报告思路对数据进行整理后，对报告进行编写的思路一般为：背景和目标阐述：对项目背景和需要达成的目的进行讲述，方便观看报告的人能够了解项目背景。方法概述：研究方法的概述，调研的基本信息，包括产品版本号、时间、调研人数、年龄层分布等。可用性报告：先进行整体结论叙述，再根据各项任务进行分别的阐释和优化方案建议。附录：添加用户的档案信息、对可用性测试的评价及满意度情况，方便其他参阅报告者更加清晰了解到全部内容。在上述思路的第3点中，可以先整体结论叙述是对全局进行一个概括性总结，便于观看报告人能够了解宏观大体结论，再对测试的所有任务项目进行完成率/满意度对比，即可大致发现产品所暴露的可用性问题以及严重程度，再根据各项任务进行分别的阐释和优化方案建议。可用性报告对于观看报告的产品人员来说，还需要界定问题的真假，根据自身情况，对问题的严重程度排列问题优先级，才能对后续对产品进行逐步优化。本文由 @舒季 原创发布于人人都是产品经理，未经许可，禁止转载。题图来自 Unsplash，基于CC0协议

这些技巧有助于开展 Guerrilla 可用性测试。enjoy~Guerrilla 可用性测试是一种非常流行的技术。它快速，低成本，并且能获得真实的用户反馈。Guerrilla 可用性测试的实施总是由其自身情况决定，但我有一些简单实用的技巧能够确保测试产生更好的结果。1. 确定目标无论使用哪种研究技术，在开始测试前确定目标，都是值得的。如果不知道期望从研究中得到什么，这可能是花时间做一些事的最佳时间。你不需要做一个非常详尽的计划（相对于便宜、灵活的“即时”技术来说，这显得有点与初衷背道而驰），但它需要你在开始的时候明确定义你要找的东西。2. 注意偏见如果你总在当地网吧测试，那么你需要意识到你正在将结果导向网吧用户（如果大多数用户在家使用智能手机登录，那这就尴尬了）。承认偏差的存在能够帮助你调整测试内容，最大限度降低影响。在 Guerrilla 可用性测试的多样性，与清晰的用户画像是成正比的。3. 让参加者之情在开始测试前，确保参与者对你在做什么、你是谁以及你为什么这样做有所了解。你可能也要具体介绍你期望的输出（或者反馈）。理想情况下，你需要创建一个简单的发布表单，以说明对测试参与者的潜在影响。虽然看起来有点尴尬，但这个过程有助于建立起研究人员和用户之间的信任。作者/版权所有者：欧洲议会。版权条款和许可：CC BY-NC-ND 2.04. 给予奖励你不必给参与者 100 刀，但你可以用其他一些东西作为奖励——一杯咖啡或午餐，能够让参与者意识到你真正重视他们的时间和付出，从而为你带来理想的回报。也可以为他们提供一个休息的地方，可以聊一会儿，从而与参与者建立更牢固的关系。5. 保持真诚在可用性测试开始时，有时候需要使用一些小手段或说善意的谎言——特别是让自己远离产品团队（如果人们认为这可能会伤害你的感受或给你带来麻烦，他们会给出相反的反馈）。但消除这些顾虑是十分必要的。如果在开始时使用任何形式的欺骗，就需要在测试结束后向用户澄清。这是公平的，但它也会让参与者把你的品牌视为一种道德品牌。6. 鼓励用户反馈中的创造力常规的，我们总是会按照问题列表进行提问，并按照观察列项做一系列的执行。当然，这些是没有任何问题的（因为这些有助于保持研究的一致性），但你还需要考虑帮助用户有创造性的反馈、感受和体验。让他们勾画想法或感受，或者如果 UI 有问题——让他们圈出不喜欢的东西…混搭并匹配反馈机制，可能你发现那样会获得更多更深入的见解。作者/版权所有者：Heinrich-Bll-Stiftung。版权条款和许可：CC BY-SA 2.07. 参与而不是主导当然，你应该支持参与者，帮助他们回答所有问题。然而，这不意味着要去一味的引导他们通过每一步的测试——如果告诉他们该如何使用产品，这就不是一个真正的可用性测试了，不是么？鼓励他们尝试并提出问题；这才是真正的用户在下载产品后需要经历的过程。如果有人最终完全陷入困境…你需要把他们带出来，但记住那一刻，表明这是一个很大的可用性问题。8. 随时记录当然，你会有一个旨在记录可用性测试结果的清单，但有时你看到的事物或听到的东西，并不是真实的（译者注：很多可用性测试切勿盲目记录现象，并将现象当作根源）。最好有一个笔记本电脑（或录音笔），随时记录这些片段，在测试后仔细推敲。无论如何，不需要在每次测试结束时拿到所有的观察结果。如果需要，可以在测试结束后添加补充，但大多数情况下，这不是 Guerrilla 可用性测试。9. 有一个正式的反馈提取过程使用自动化工具提取反馈信息就会非常方便了。有很多便宜的可用性测试工具可以在测试的时候使用，以便节省时间和其他成本。或者你可以想出自己的方法，只要它具有可移植性并且能够快速布置和使用。选择工具时最重要的是要解决谁需要数据以及数据的格式…当工具在数据提取和传播方面做了大量工作时，团队协作会变得更加容易和高效。作者/版权持有人：Praludium Liu。版权条款和许可：保留所有权利Img source10. 按时完成如果你需要别人 10 分钟的时间进行测试，那么就 10 分钟而不是 30 分钟。请记住，人们在忙碌的生活中难得休息，确参加了你的研究；如果你不尊重他们的时间——他们会很不高兴、不快乐，就有可能在研究测试中捣乱。概要这些技巧有助于开展 Guerrilla 可用性测试。当然，你可能已经做了很多这样的事情，但根据我们的经验，即使是长期使用 Guerrilla 可用性测试的人，往往也会在测试过程中忽略其中的一部分。#专栏作家#郑几块，人人都是产品经理专栏作家，前新浪微博产品经理。题图来自 Pexels，基于 CC0 协议

小强今天给大家带来的是可用性测试分享，适用于UX、UI、视觉、用研和产品经历等岗位。这篇文章从由五个模块内容组成：什么是可用性测试？为什么要做可用性测试？怎样去做可用性测试？什么时候需要进行可用性测试？在哪去做可用性测试？那我们基于这5点一起展开详细描述下吧。什么是可用性测试？-可用性最早来源于人因工程（human factors）。人因工程又称工效学（ergonomics），起源于二战时期，设计人员研发新式武器时研究如何使用机器、人的能力限度和特性，从而诞生了工效学，这是一门涉及多个领域的学科，包括心理学、人体测量学、环境医学、工程学、统计学、工业设计、计算机等。可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题，通常只能做少数几个用户的测试，看他们怎么做，属于典型的定性研究。“可用性”一词也指在设计过程中提高易用性的方法。可用性由五部分组成：可学习：用户首次使用时是否很容易完成基本任务操作？效率性：用户完成任务操作所花时间成本为多少？用户是否可以轻而易举的就知道怎么使用？可记忆：当用户在一段时间内不再使用设计时，他们能很容易的再次熟练使用吗？容错性：用户使用中是否会遇到错误？错误严重性大吗？用户是否能够轻而易举的解决纠正错误？满足感：用户使用这个设计时，感到愉快吗？可用性和实用性同样重要，并共同决定某些功能是否需要存在：如果功能不是用户想要的，那么再重要的功能也无意义。如果你只是从业务角度考虑增加这个功能，而不考虑用户是否真的需要这个功能或者设计时，做出来的东西可能会很难用，用户慢慢地也不去用了。要研究同个功能点的时间时，你可以采用AB方法来进行验证提高可用性。实用定义=所需功能特性可用性定义=容易程度好用性=实用性+可用性为什么要做可用性测试？-在web、app上，可用性是产品生存的必要条件。如果一个产品很难使用，人们就不会用它了；如果主页用户都不知道你这是什么app，是用来干嘛的，用户就会离开他；如果用户在app上迷路，用户就会离开；如果一个app的信息很难阅读或者没有回答用户的关键问题，用户就会离开；用户不会像买复杂数码产品一样，还需要查看说明书。用户看不懂就会离开，就如互联网早期，各类今日头条的飞聊app，一度号称挑战微信地位，但最后几乎很少人使用。原因就在于，大家并不知道飞聊有什么用；对于企业内部网站、app而言，可用性与员工生产力有关，可用性测试同样重要。用户浪费在你的内部网上丢失的时间，或者在思考困难的指令是你浪费企业的钱，花费了太多没必要的时间在非核心工作内容上。当前的最佳实践要求在可用性上花费设计项目预算的10%左右。在设计app、网页过程中其实进行可用性测试成本其实比较小，但是带来的收益确是实打实的。怎样去做可用性测试？-可用性测试的方法很多，但最基本和最有用的方法是用户测试，它有三个部分组成：获得一些典型的用户，比如产品的忠实用户，或者公司非相关业务的同事。要求用户执行具有代表性的设计任务。观察用户做什么，他们在哪里成功，以及他们在用户界面上有什么困难。测试过程中尽量让用户来说话。重要的是要单独测试用户，让他们自己解决任何问题。如果你帮助他们或引导他们注意屏幕的任何特定部分，你已经影响到了测试结果。要确定设计中最重要的可用性问题，测试5个用户就足够了。与其运行一项庞大而昂贵的研究，不如更好地利用资源来运行许多小测试，并在每个测试之间修改设计，这样您就可以在识别问题时修改它们。迭代设计是提高用户体验质量的最佳方法。您与用户测试的版本和界面想法越多，越好。用户测试不同于焦点组，后者是不适合评估设计可用性。焦点小组在市场研究中占有一席之地，但要评估交互设计，您必须密切观察用户在执行用户界面任务时的情况。听别人说的话是有误导性的，你必须观察他们的实际行动。什么时候需要进行可用性测试？-可用性在设计过程的每个阶段都起作用。因此我建议快速、简单地进行可用性测试。以下是主要步骤：可用性和实用性同样重要，并共同决定某些东西是否有用：除非您正在内部网上工作，否则测试您的竞争对手的设计，以便在一系列具有与您自己的相似功能进行快速迭代和优化，学习竞品优势。进行一项实地调查，了解使用者在真实场景中的行为。制作一个或多个新设计理念的原型并测试它们。您在这些设计思想上投入的时间越少，越好，因为您需要根据测试结果来更改它们。通过多次迭代优化设计思想，逐步从低保真度原型到在计算机上运行的高保真表示。测试每个迭代。检查设计与制定的可用性指南，无论是从您自己的早期研究或发表的研究，找到一种适合自己的方法。一旦您决定并实现了最终的设计，再次测试它。微妙的可用性问题总是在实现过程中悄然出现。不要推迟用户测试，直到您有了一个完全实现的设计。如果您这样做了，就不可能修复测试发现的绝大多数关键可用性问题。其中许多问题可能是结构性的，解决这些问题需要进行重大的重新架构。要获得高质量的用户体验，唯一的方法是在设计过程的早期就开始用户测试，并继续测试该方法的每一步。在哪去做可用性测试？-如果你每周至少进行一次用户研究，那么建立一个专用的可用性实验室是值得的。然而，对于大多数公司来说，在会议室或办公室进行测试是没问题的-只要你能关上门，以免分心。重要的是你能接触到真正的用户，并在他们使用设计时与他们坐在一起。记事本是你唯一需要的设备。

用户调研分为两种，包括定性和定量研究。常见的调研方式有用户访谈、可用性测试、问卷调查、数据分析、A/B测试等。在产品的设计开发及优化迭代的过程中起着非常重要的作用。本文笔者主要总结下可用性测试的亲身操刀经验。什么是可用性测试可用性测试（usability testing）是一项通过用户的使用来评估产品的技术，因为它反应了用户的真实使用体验，所以可以视为一种不可或缺的可用性检验过程。也就是说，可用性测试是让用户使用产品的设计原型或成品。通过观察，来直观的记录用户的感受和体验，从而改善及提升产品可用性的方法。可用性测试适用于产品发展的各个阶段，包括前期设计开发阶段到后期优化改进阶段。做可用性测试价值在于能够在不同的阶段更加高效的发现问题，从而提高问题解决效率。可用性测试行动计划及操作步骤想要做好产品的可用性测试，具体的行动计划十分关键。在做一件事情之前，笔者保持的工作思路是：先看整体框架，再关注细节要点。所以将可用性测试划分为以下几个阶段：第一阶段：做好测试前的准备工作1. 制定时间规划我们需要在项目开展前，首先确定项目的时间要求，制定合理的Timeline。即初步规划一下前期测试准备、中期测试开展及后期总结分析各个阶段所需要的时间，以便根据整体节奏及时做调整和安排。2. 定义测试目标和范围（1）确定需要测试的产品（服务）。以目标为导向，我们需要优先确定需要测试的产品是什么，希望验证什么样的结论或者预期。无论是开发测试期产品还是优化迭代期产品，要有出发点。（2）确定产品测试范围。产品测试范围，包含想要测试的产品所涵盖的服务范围或全部功能。可根据实际的需求进行控制。3. 定义目标用户要对自己调研的用户有清晰的定位，即需要定义清楚测试的目标用户画像。可以从以下两个方面对测试用户进行条件筛选：用户基本特征（性别、年龄、所在地区、社会身份、收入水平、个人使用设备等）用户行为特征（产品访问习惯、需求频次、使用时长等）4. 招募测试用户招募测试用户，就要以我们定义的目标用户为标准来找。大量的可用性测试实践证明，5名参与者即可发现75%以上的问题。希望通过增加参与者数量来发现更多的问题意义不大，所以我们基本选择5-7名参与较为合适。5. 选择测试任务在可用性测试的具体实施阶段，需要我们根据测试需求设置相关的任务。思考用户在产品实际体验过程中可能存在的场景和需求，要求用户配合并完成相关的操作。6. 拟写任务的测试脚本当我们对任务有了具体的思考后，接下来需要对任务进行具体描述，以便更好地实施。一般情况下，我们要准备好完整的测试脚本并分给团队成员共同配合。常用的测试脚本包含以下内容：可用性测试协议书提问者大纲（包含测试前声明、基本信息提问、发声练习、正式测试任务、体验访谈等内容）记录者大纲（依据提问者大纲同步整理，观察并记录用户完成任务的过程）满意度问卷7. 确定可用性测量维度根据测试的目的需要我们进一步筛选测量维度，找到相关数据指标。我们通常会从定量和定性两个维度出发衡量任务的难易程度：定量维度：任务完成时间、任务操作成功/出错次数、任务协助次数等定性维度：用户对测试的整体评价及满意度情况等此外还有其他维度的指标用于从更多的角度衡量整体设计流程及细节是否安排合理。8. 准备测试物资测试物资的筹备，需要我们打印相关材料，准备好测试使用的设备及场地。可用性测试需要收集非常多的信息和数据以便后期总结分析，通常在实验室进行，可选择使用一些合适的辅助设备。实验室通常分为测试区和观察区：测试区：主要是提供给调研者和参与者（用户）使用观察区：则主要是提供给记录者、产品开发或其他相关成员使用但一般情况下，测试场所可选择普通会议室、测试设备使用手机或电脑操作即可。9. 组建测试团队我们在一个测试项目中，需要有不同角色的人相互分工配合。通常设置项目经理、产品经理、观察记录员、项目助手、设备管理员等角色。但实际上安排以下两个角色也可以完成：产品经理：主要负责与用户沟通、控制整体项目进度、拟写测试脚本、数据分析等观察记录员：主要负责协助记录测试要点、招募用户、测试现场支持等第二阶段：做好测试中的观察记录1. 预测试环节预测试环节主要是为了在正式测试开始前模拟真实的测试过程。主要目的也是为了及时优化调整测试内容。除了检查全部脚本是否正确无误外，还要在测试时间控制和设备环境等方面进一步检查，看看是否存在什么问题，做好各类风险的初步预估。2. 正式测试环节正式测试环节即我们可用性测试的具体实施阶段，主要可以按照以下几个步骤操作：步骤一：接待用户（1）用户来访签到。在招募好用户后，需要安排合适的时间邀请用户到指定地点测试。用户到达后需核对清楚用户信息并引导进入休息区等待测试的开始。（2）发放可用性测试协议书。随后发给用户可用性测试协议书，让用户仔细阅读并签字，对本次调研做一个初步的了解。协议书主要是说明此次测试的目的、征求内容采集的权限、告知个人信息保密性及同步测试后可获得的奖励。步骤二：测试实施笔者总结出一些常规固定的流程模板，在测试实施阶段可以按照以下内容进行：（1）测试前声明。在测试正式实施前，要对本次测试的背景和目的做一个声明。（2）基本信息提问。该环节主要是为了缓解测试的紧张气氛，热场是用户和调研者之间相互熟悉的过程，以保证用户在测试过程中的放松和配合状态。可以选择做一些比较轻松的暖场聊天（如亲切的和用户聊聊今日装扮、近期出行计划等）。也可以对用户进行一个简单的提问（如年龄、爱好、职业、产品使用习惯等）。（3）发声练习。在可用性测试过程中，往往会先要求用户进行Think Aloud。即在测试的过程中，让用户将心中所想口头表达出来。可以给用户一个简单的示例。（4）正式测试任务。当用户利用发声思维法操作后没有问题，可安排进入正式测试任务。正式测试任务和发声练习一样，需要用户积极配合去完成，如果遇到问题也可随时提出。正式测试的任务在实施过程中需要注意几点：第一，任务解释需要清晰到位。每一项任务都需要用户理解透彻，知道这个任务具体是要做什么，才能顺利完成。不然盲目的操作也会影响测试结果，增加记录的复杂程度。第二，任务节奏要良好掌控。根据脚本内容，让用户依照实际的任务要求操作 ，不要随意尝试，控制好测试的时间和节奏。提问者和记录者之间也要有较好的配合。第三，任务内容较好把握。对任务的难易程度要有初步的评估，并给到心里预期，如果用户遇到了问题，在测试结束后要及时沟通，找到发生的原因。（5）体验访谈。体验访谈的目的在于对测试做一个补充提问，包括任务外的其他测试需求。此外，对任务执行过程中遇到的问题也可以进一步沟通，定位发生的原因并做好记录。步骤三：结束退场（1）用户填写满意度问卷。测试结束后，需要邀请用户填写满意度问卷，对测试进行简单的评价，做好信息反馈与总结。（2）核对测试收录的内容及信息。在用户离开前，需要确认是否所有任务都已完成，测试记录的相关信息是否都已完整收录，尽可能的避免出现任何的遗漏。第三阶段：做好测试后的总结分析1. 信息整理测试结束后，首先需要对测试结果进行数据处理与分析，及问题的归纳总结。（1）数据分析。主要是依据行动计划中确定的可用性测量维度，从定性和定量的维度初步统计。通过任务的完成时间、任务操作成功/失败次数及协助次数等指标，评估任务的难易程度，从而进行调整优化。也可以对用户评价及满意度的反馈进行统计，方便后续工作的继续开展。（2）问题归纳。可用性测试结束后，重点工作就是对用户反馈的问题进行归纳总结。主要是汇总整理全部访谈记录内容及归纳出一些主要的结论。通常我们可以先将任务做一个划分，再从用户体验反馈和优化建议两方面进行梳理，关注反馈频次并整理优先级。2. 结果总结与分析结果总结与分析对调研而言至关重要。可用性测试报告框架可包含：项目背景（可用性测试调研的背景及目的）、任务总览（用户完成每项任务的实际情况描述）、问题汇总（归纳测试过程中发现的问题）以及优化方案。此外，还可以再附录中添加用户的档案信息、对可用性测试的评价及满意度情况。方便其他参阅报告者更加清晰的了解到全部内容。3. 测试结果沟通与反馈当我们完成测试后，除了汇报测试的结果，还需要与具体的需求方做进一步的沟通，从而给出具体的改进方案和后续规划。不是将结论或报告呈现在文档中，将所有资料归档就算结束，而是需要我们主动沟通，将可用性测试得出的诸多有效结论同步给相关负责人，主动驱动业务的发展。写在最后可用性测试在产品的设计开发及优化迭代的过程中起着非常重要的作用。笔者总结的具有实操性的方式方法需要灵活运用，最关键的是贴合具体的业务，通过可用性测试快速发现并解决问题。感谢阅读。本文由 @Sherily 原创发布于人人都是产品经理，未经许可，禁止转载。题图来自Unsplash，基于CC0协议。