任何与人可以发生交互的产品都应该是可用的，就一般产品而言，可用性被定义为目标用户可以轻松使用产品来实现特定目标。
ISO9241/11中的定义是：
一个产品可以被特定的用户在特定的场景中，有效、高效并且满意得达成特定目标的程度。
人机交互专家JakobNielsen将可用性框架的定义为：
什么是可用性测试？
可用性测试，大多用于网站或移动应用的设计评估，其实也可以用于智能硬件的完整体验流程，通常会邀请目标受众群体中的真实用户，在特定场景下通过产品完成典型的任务。
在真实的使用过程中观察用户的实际操作情况，详细记录并分析用户在使用产品中遇到的问题，目的是发现产品中存在的可用性问题，收集定性和定量数据帮助产品改进，并确定目标用户对产品的满意度。
为什么要进行可用性测试？
可用性测试是改善产品的极佳方式。
有时，我们并不是产品的目标用户，很多需求和设计方案是产品设计人员自己想出来的，在讨论方案的时候总是说：”用户想要…”、”我觉得…”、”如果是我，我会…”，虽然设计时会依据一些经验与设计法则，但这些都只是未经验证的主观猜测而已，无法准确的评估设计方案的优劣，这往往导致观点对立，僵持不下。
所以为了了解真相（用户到底会怎样使用产品），我们要找到我们的目标用户并向他们学习（观察他们如何使用产品），这样才能使团队尽快对设计方案达成一致并积极改善产品。
通过可用性测试，我们可以：
可用性测试类型
可用性测试的类型（进行可用性研究的原因）有三种：
可用性测试方法
产品可用性测试方法分为分析法和实验法。
1.分析法
让产品可用性工程师及用户界面设计师等专家，基于自身专业知识和经验进行评价的一种方法。
分析法常用于可用性检查阶段，常见的分析法包括但不限于：
专家评审：评审由精通设计可用性概念的专家进行，基于自身专业知识与经验对产品进行审查。
启发式评估：让可用性专家判断每个页面及元素是否遵循已确立的可用性原则。
认知走查：设计师模拟用户在使用产品过程中的每个操作步骤所遇到的问题，检查用户的任务目标和心理认知是否可以顺利执行下一步操作？
针对每步操作提出四个问题：
通过回答每个操作步骤的问题，就能发现可用性问题。
多元走查：认知走查的变体，使用小组会议，其中用户、开发人员和人为因素让人们在场景中逐步讨论操作流程中的每个交互页面及元素。
一致性检查：让代表多个其他项目的设计人员检查界面，以查看它是否以与他们自己的设计相同的方式进行操作。
2.实验法
收集真实的用户使用数据，比较典型的是用户测试法，问卷调查等方法也属于此类。
实验法常用于可用性测试阶段（用户测试阶段），常见的实验法包括但不限于：
分析法与实验法的主要区别在于：是否有用户参与其中？
分析法的参与者是具备可用性知识的设计师与工程师；而实验法的参与者是目标用户或小白用户。从某种程度而言，分析法和实验法是一种互补的关系。
一般，在设计用户测试时，先在可用性检查阶段通过分析法去排查可用性问题，把排查出的问题按重要程度排序，然后在可用性测试阶段通过用户测试去重点观察和验证。
分析法的最大缺点是：它得到只是分析者的假设或观点，在团队意见不一致时，并不能够提出支持自己意见的有力证据。为了结束争论，就只能通过实验法。
接下来重点介绍分析法中的启发式评估法与实验法中的一对一用户测试。
启发式评估1.启发式评估简介
因为专家评审过度依赖于自身的专业知识与经验，为了得到一个更客观的结果，JakobNielsen根据多年可用性工程的经验创造了启发式评估法。
启发式评估使专家按照公认的可用性原则，来审查用户界面中的可用性问题，然后通过一系列原则对它们进行分类和评分。JakobNielsen的十种启发式评估原则（尼尔森十大交互定律）是行业中最常用的可用性评估原则。
除此之外，还有Gerhardt-Powals的认知工程原理、Weinschenk和Barker的分类、ISO9421对话原则等。
2.启发式评估原则
JakobNielsen倡导的启发式评估十原则内容如下：
3.启发式评估法的实施步骤
STEP1：招募评价人员
JakobNielsen认为：一个人评价大约只能发现35%的问题，因此大概需要3~5人才能得到稳妥的结果，能够胜任启发式评估职位的人可以是用户体验设计师、交互设计师、UI设计师等。界面的原设计师是不适合评价界面的，因为评价结果可能会不够客观抑或是发现问题直接就进行修改而不会反馈。
STEP2：制定评价计划
评价产品的所有功能是比较困难的，所以要事先定好要评价界面的哪些部分，以及依据哪些原则进行评价（Gerhardt-Powals的认知工程原理、Weinschenk和Barker的分类、ISO9421对话原则等）。
STEP3：实施评价
最好对界面进行两次评价：第一次检查界面的流程是否正常，第二次详细检查各界面是否存在问题。评价人员之间应禁止相互讨论，以避免评价结果被权威人士所影响。
STEP4：召开评价人员会议
评价人员完成了各自的评价后，要集中开会以汇报评价结果，会议上描述问题的同时将界面显示出来会更有效率。
启发式评估的优点是：通过单独评价和评价人员之间的讨论这二次过滤，可以发现单独一人不能发现的跨度较大的问题。
STEP5：总结评价结果
汇总所有的评价结果后，就可以整合评价的问题列表了，可能会有一个问题存在多种表达方式，所以需要对问题列表进行适当的整理。
STEP6：输出总结性报告
启发式评估法的输出成果就是产品可用性问题列表，但如果只给出列表，其他成员理解可能会比较困难，因此最好配上界面截图、流程图等输出一份简介的启发式评估报告。
启发式评估报告（HE报告）的内容主要包括：
启发式评估问题列表的示例
4.启发式评估法的局限性
平心而论，启发式方法是打算作为一种帮助新手从业者进行可用性检验的“脚手架”，因此它无论如何都无法与专家可用性检验方法相提并论。而且，只有专家才能通过可检验方法发现问题，而不是使用启发式方法的都是专家。
启发式评估法是由多位专家基于自身经验和启发式原则，对用户界面进行的评判，因此势必会发现很多问题。而且实施启发式评估法需要多名专家在限定的几天内进行作业，所需成本也较高。
所以应结合实际情况对启发式评估做简化，可以只由一两名专家进行简单审查，这种做法被成为启发法。不过在不提供客观的判断标准，且检验人员数量又少的情况下，评估结果可能会被指责“这些问题只是检验人员的主观想法而已”。
因为资源有限而导致不能进行正规的启发式评估，而改为简易的审查时，要注意：
用户测试1.用户测试简介
用户测试，可用性工程师与用户进行一对一访谈（理想情况下，观察者与使用者彼此不认识，以便收集更多客观数据），其他成员在监听室观察整个访谈，而且用户操作计算机时的界面和声音，全程都被录像。
可用性测试的基本内容是相同的：为用户构建一个场景，让用户通过产品完成特定任务，在用户执行任务的过程中观察他们遇到的问题。
2.用户测试的常见方法
（1）发声思考法
发声思考法观察的重点：
（2）回顾法
让用户操作完后回答问题的方法。
回顾法的限制：
（3）性能测试
性能测试一般会安排在项目前后实施，目的是设置目标数值、把握目标的完成程度和改善程度。
数据统计处理较多的心理学实验里，一般至少会收集20~30人的数据。而且所谓20人是目标用户的人数，因此整体而言需要40~60人。
性能测试的限制：当任务完成率只有20%时，团队只知道这个任务的执行效率很低，但不知道用户究竟是为什么没能完成任务，因此会感觉无所适从。
缺少发生思考的性能测试没有任何意义，但如果同时实施这两种方法，又需要很大预算。所以只要还未明确定量数据的必要性，就不应实施性能测试。我们没必要把有限的资源浪费在定量数据的测试上。相反，反复进行的发生思考法这种只需几个人参加的测试，可以更好的改善界面。
3.用户测试的实施步骤
STEP1：设计任务
可用性评估是基于任务的，任务设计的优劣能直接影响测试结果的准确性。所以在招募用户前，应先针对产品设计任务。比如：一个购物类APP设定的任务可以是：购买一件价格高于100元的T恤。
想要设计出合适的任务须注意以下几点：
（1）选择最核心的功能或操作流程作为任务
一个产品可以执行很多任务，不可能把所有任务都执行一次。所以应采用精益思维，把有限的资源放在最有价值的环节上，产品最核心的功能或操作流程往往是最频繁被用户使用的地方。
如果这里还存在可用性问题，那么就算改善了其他边缘地带的可用性问题，依然对产品整体体验于事无补，所以设计的任务要以核心功能和操作流程为主。
（2）任务应符合常规操作流程
有时设计者会把自己想要用户做的事当任务来测试，但实际用户并不是按设计者想的流程去完成任务的。而且由于测试的任务较多，设计者为省事有时会把多个小任务合并为一个大任务，这样做有时是可以的，但如果小任务之间的操作流程存在冲突，用户测试的操作流程就是不合乎常规的。
也就是说，用户实际在执行的任务在正常使用产品的时候，根本不会出现或极少出现，这样的测试的结果准确性令人堪忧，且还会给参与测试的用户造成困惑。
（3）为任务创建一个应用场景
简短的场景描述会会对用户执行任务有所帮助。比如：任务是“购买一件价格高于100元的T恤”，我们可以创建这样一个场景——你的同事过生日了，你想挑一件一百多块的T恤给他，请使用XXAPP来完成T恤的购买。
这样给了用户一个执行任务的理由和目的，不会使任务变得突兀，而且用户也会变得有代入感从而更好的理解并执行任务。注意场景描述里不要涉及用户的直系亲属，没人知道他们的经历，以免引起用户的情绪反应。
（4）明确任务的起点和终点
判断用户是否完成了任务的主要依据就是：用户是否从起点（页面A）到达了终点（页面B）。
所以要清晰的定义，哪个页面是起点？哪个页面是终点？起点未必一定要是首页，起点位置应根据具体场景来确定，毕竟并不是每个任务都是从首页开始的。比如：任务是“购买一件价格高于100元的T恤”，那么起点页面可以是APP的首页，终点页面就是付款成功页面。
不过除了检查是否到达终点，可能还要检查一些关键信息，比如：用户购买的T恤价格是否高于100元、用户是否正确填写了地址等。如果没有，那么我们要搞清楚原因是什么？
（5）任务不应过于简单
如果想测试用户是否可以找到某功能，不要用类似“找到XX功能按钮”这样的描述，我们应该给用户提供一个要处理的现实任务，而不只是定位功能的位置。“找到退款功能按钮”应改为“购买一件T恤并退款。”
（6）避免提供线索和描述操作步骤
任务应给出具体目标，而不是操作步骤。
以买T恤的任务为例：如果告诉用户“搜索T恤，然后选择数量和颜色，填写地址并确认订单，最后进行支付”，那么用户在执行任务时的思路可能是这样的：找T恤、找数量选择按钮、找颜色选择按钮、找填写地址的位置、找订单确认按钮、找支付按钮，一个完整的核心任务就这样被拆分成了多个确认功能按钮位置的操作，引导性过强的任务失去了测试的意义。
这样做会错过用户在任务中，执行到某一步骤时可能提供的宝贵反馈。因为用户一开始可能并不知道会有这些操作步骤，可能会因一些额外的操作感到惊讶或烦恼。而且用户在实际使用产品时，考虑的是使用目标，而不是具体的操作和功能。
因此，一定要避免提供线索和操作步骤给用户。
STEP2：招募用户
（1）要根据资金预算和日程安排来招募用户，并给予他们一些报酬（小礼物即可）
招募对象的选择理论上应该是产品的典型目标用户，但是仍然需要定义具体的用户特征——即招募条件。
招募条件可以从早期市场调研阶段中建立的用户画像中提取用户特征，要尽可能的代表将来的真实用户。如果目标用户画像分为几类，那就要求招募的用户中要包括所有类型的用户。
被招募的用户应具备使用产品执行任务的能力，比如：我们一定不会找电脑都不太会使用的人来体验桌面软件。
通常我会找两类用户来体验产品：
因为我的产品目标是降低同类产品的操作复杂度，让小白用户也能轻易上手，通过这两种用户可能会发现截然不同的问题。
（2）接下来要确认所要招募的用户数量
JakobNielsen提出过一个法则：有5人参加的用户测试，即可发现大多数（85%）的产品可用性问题，而且通常最严重的问题都是前几名用户发现的，随着用户数量的增多，发现的问题逐渐减少，被发现的问题数量与测试用户的数量的关系如下图所示。
但它也存在一些局限性，比如：它只能说明发现的问题的数量，但不能确认所发现问题的严重程度（还有很多局限性在此不一一列举）。所以我们要根据我们的实际情况，来确定要招募的用户的数量，查看每次测试的结果与迭代效果，看看是否值得投入更多资源来做可用性测试。
Resource:NielsenNormanGroup
（3）关于招募渠道
STEP3：准备工作
（1）测试地点与工具的准备
专业的用户测试一般在实验室内进行，实验室有观察室与操作室，测试人员与用户在操作室进行可用性测试，其他团队成员在观察室中观察，两个房间之间通常由单面镜隔开。
操作室内无法看到观察室的情况，而观察室能看到操作室的情况。通常观察室中还需要配备电脑或投影仪，实时显示操作室中正在被用户操作的用户界面。但绝大多数公司往往不具备这样的条件的实验，这时我们找一间安静的会议室就可以了。
测试人员与用户在会议室进行测试，如果是PC端软件的测试，可在PC预安装录播或直播软件，便于其他成员观看用户操作的流程与表情。如果是手机端软件的测试，可以直接使用同屏功能，团队其他成员直接在另外的PC上观看用户的操作即可。
推荐使用能同时录制屏幕和用户表情具备画中画功能的软件，因为观察用户屏幕帮助我们了解用户做了什么，观察用户表情可以了解用户的情绪（困惑、恼怒等）。
总之，方法和工具有很多，只要不影响用户测试并便于团队成员观察即可。
要准备任务提示卡，一张用于记录用户要完成的任务的卡片，有些任务可能比较复杂，这样可以更准确的传达任务信息，且便于用户主动查看。
更专业的用户可用性测试，会与用户签署一些协议。
比如：
有的测试可能还会用到培训资料，比如：某些复杂的智能硬件，可能需要用户先阅读说明书后再执行任务，诸如此类在此不过多阐述。
（4）可用性测试剧本的准备
可用性测试剧本指我们从接触用户、开场白、开始测试、事后访谈、给予奖励并送走用户的整个过程中要执行的行为与台词的集合，测试人员通过执行剧本中的内容来推动可用性测试的进行。（别忘了准备报酬）
4.可用性剧本示例
（1）开场白（3分钟），说明访谈目的和基本流程，签订录像许可与保密协议等文件
常用话术：您好，我是XX购物APP的可用性工程师，很高兴见到您。今天由我来和您做这次测试，这次测试的目的是测试我们的产品是否便于用户使用，接下来会拜托您通过APP执行几个任务，执行任务的过程我们需要通过摄像头记录下来，以便于我们的重复观察与分析。还要麻烦您对本次测试的内容进行保密，如果没有什么疑问，请您在这些协议上签字，谢谢。
（2）事前访谈（5~10分钟），了解用户背景，也可通过问卷来获取信息
常用话术：方便透露下您的年龄/职业嘛，说个范围就可以，比如：20~30/某个行业。您是否有用过类似的在线购物产品？有的话，感觉怎么样？感觉优点/缺点有哪些？如果没有，您购物是通过什么方式呢？通过什么方式支付呢？
常用话术：接下来请您使用我们的APP购买一件商品，任务的细节和背景都写在这张卡片上了。需要强调的是：我们的APP只是一个初步版本，我们已经知道它存在一些体验上的问题，想通过您的使用验证这些问题，所以如果遇到了什么问题，都是产品设计的问题，操作失败了也请不要放在心上。
在操作过程中，希望您能一边操作一边告诉我您要进行什么操作？您为什么要这么操作？您是怎么想的？这对我将非常有帮助。
最后，您在操作过程中最好不要向我提问，因为如果我告诉了您如何操作，我可能就无法找到产品中的问题了。所以如果您问我问题，我没有答复您，还请见谅。
（4）观察测试（30~40分钟），观察并记录用户在执行任务中遇到的问题
假设目标任务为——购买一件100元以上的T恤，起点为首页，终点为付款成功页。
常用话术：假设您的同事过生日了，您想送他一件100元以上的T恤，请使用这款APP进行购买。
（5）事后访谈（5~10分钟），通过回顾法询问用户在执行任务中遇到的问题
常用话术：您刚才用这款APP进行了一次购物体验，能谈谈您的感想吗？
比如：觉得哪里比较好？哪里比较差？对比您之前使用过的同类APP感觉如何？如果要综合评价这次购物体验，您会给它打几分呢？给之用过的同类产品打几分呢？为了使产品体验更好，您觉得我们有哪些需要改进的地方呢？
虽然主流观点认为不该问用户产品哪里需要改进，因为改进产品是设计者的事情，用户给出的也只是基于自身经验的主观解决方案。但是如果针对用户的答案，继续深挖“为什么”，可能就会知道用户真正想要的结果是什么。
（6）结束语（3分钟），对用于表示感谢，并初始化实验室准备测试下一位用户
常用话术：今天的测试到此为止啦，感谢您的配合，这次测试的数据对我们非常有用，我们为您准备一盒咖啡以表谢意，请笑纳哈。（接着送走用户就好）
STEP4：试点测试
试点测试可以理解成可用性测试之前的彩排，无论进行了多么周密的计划，不实践一下是不会发现计划中的问题的，试点测试的目的就是对测试计划进行测试，以便于发现测试计划中的疏漏，及时修复，以免浪费测试资源。
最后，根据试点测试中发现的问题，对测试计划进行修复，完善测试计划。
STEP6：观察&访谈
（1）邀请关键干系人观察测试
建议邀请产品的核心研发、设计师、项目经理等来观察测试，因为这样可以是测试结果更有说服力。如果没有这些人来观察测试，测试结果得可信度对他们来说就大打折扣。因此，越多关键干系人观察到了测试，越有利于后续产品优化方案的执行。
（2）不要干扰用户执行任务
进入正式测试环节后，测试人员就不能像在事前访谈一样不断的像用户提问了，用户测试的主角是用户，测试人员应安静的观察用户的操作并记录，不要干扰用户执行任务。
当用户对当前操作存在疑问时，比如：“我现在可以按这个按钮吗？”
测试人员不可以直接回答用户应该如何操作，以及每个按钮代表什么。也不可以无视用户的问题，因为这样可能会引起用户的不满情绪。
此时，最合适的方式应该是回复“您觉得应该是怎样呢？是什么让您觉得应该是这样？您怎么想就怎么做，没关系的。”把问题推回给用户，并让其有一定安全感，做错了也没关系。我们只负责告诉用户“做什么”，至于“怎么做”这是要用户通过操作反馈给我们的信息。
（3）适当干预用户的操作
但在实际测试中，用户很少会把自己所思所想直接说出来，有的是因为害羞；有的是因为感到不自在，难以做到。
这时就需要测试人员进行适当的干预，比如：您正在看什么呀？您现在想进行什么操作呀？这是否和您的预期一致呀？通过这类问题试探用户的想法，并鼓励其发生思考。
原则上，只要用户操作的很顺利就不需要人为干预，我们只在用户碰到问题时进行干预，进而了解用户遇到了什么问题。用户的困惑除了发生思考，还可以从其肢体语言表达出来。比如：用户皱眉、发出语气词、喘粗气、清嗓子、挠头、突然停下动作等，这都暗示了用户在当前界面遇到了麻烦，所以测试人员应重点留意用户的肢体语言。
但切忌帮助用户进行预判断和给予用户提示，比如：“这个按钮可能设计的不太合理…”。测试人员只负责观察和记录用户的行为，不能引导用户操作和帮助用户判断。
（4）重点观察和记录用户在什么界面说了什么做什么了
记录这些客观事实即可，不要带着自己的观点去观察，比如：为了证明某个设计是对的/错的，带着寻找证据的心态去观察可能会忽略一些信息，因为人们只看到自己想要看到的。
（5）使用回顾法进行提问
有时，用户测试中出现了问题，但出于某种原因我们不便于打断用户深入提问，或者用户通过发生思考法遗漏了某些信息。这时，测试完成后，测试人员要对测试中发生的问题进行提问。
比如：“您刚才在XX界面停留了很久，能告诉我当时您在思考什么吗？”这样就能通过回顾法补全测试中遗漏的信息。
STEP7：分析
（1）整理数据，判断产品是否需要迭代
通过用户测试，我要们判断交互设计是否满足了用户体验目标水平。分析数据的第一步是整理出测试结果，通常要绘制一份表格，表格内容通常包含：任务、用户体验目标、任务基准值、任务目标值、是否完成目标等信息。
可用性测试数据整理表的示例
接着我们直接通过比较观测结果和用户体验目标，就可以知道哪些用户体验目标已经达到、哪些没有达到。如果体验目标没有达到且资源充足，那么产品就需要进行迭代。这时就要具体分析每个用户体验问题，并输出解决方案。
（2）分析问题的影响程度
并非所有的问题都是平等的，一些问题会带来负担，用户必须先处理才能继续原来的问题。其他错误可能会带来用户的情绪问题，让用户重复操作，但不会引发新的问题。
了解问题的严重性，能帮助我们更好的对用户体验问题优先级进行排序，我们通过问题性质和问题发生频率来确定问题的影响程度。
问题性质，一般要通过效果问题＞效率问题＞满意度（或者速度＞错误＞满意度）的顺序来评价问题的性质。
不管测试了多少人，我们用三个范围来表示频率：1个人、几个人、所有人（几乎所有人）。比如：10个人可能就被分为：1个人、2~7人、8~10人三个范围。
然后我们基于问题性质和发生频率建立一个表格，如下图所示：
问题影响度分析表的示例
列代表问题发生频率，行代表问题性质。把标记黄色的问题定义为必须要解决的问题，把标记绿色的问题标记为最好去解决的问题，把标记为蓝色的问题标记为资源充沛的话，可以去解决的问题。资源总是有限的，不可能每个问题都去修复，我们必须通过分析问题的影响程度确定要修复的问题。
（3）制作用户体验问题描述
以表格来维护用户体验问题的数据比较简略，不利于其他人了解详细情况和参考，所以我们需要对每个问题进行一些信息补充，让用户体验问题的实例在数据分析中变得更有价值。
我们需要做的就是——了解每个问题及其产生的原因和可能的解决方案，将表示同一个用户体验问题的多个用户体验问题进行合并（肯定会有重复出现的问题），并认清各个问题之间潜在的关系。
一份用户体验问题描述通常包含如下信息：
STEP7：重新设计
通常来讲，我们会针对每个问题，给出一个解决方案。但事实往往并非如此，问题和解决方案之间有时并不是一一对应关系。如果针对每个问题都给出解决方案，可能导致产品的复杂度提升。
有时，一个解决方案就能解决多个问题，这就需要我们对每个问题的联系及其产生原因有深刻的洞察，若是能从根本解决问题，产品的品质会得到极大提升。
这需要我们跳出原有的一对一的思维，先从宏观层面整体分析这些问题组，而不是孤立的一个个问题。在设计出解决方案后，还要对解决方案的成本和优先级等信息进行梳理，以便于更好的管理问题&解决方案信息表格，可以把这些用户体验问题与其解决方案当做产品需求来管理。
如下图所示：
问题&解决方案信息表的示例
要注意的是：不要以为按照设计方案修复好，用户体验问题就已经解决了。解决方案也只是我们的假设而已，假设这个修复方案可以解决问题，所以为了验证假设，我们要不断的通过可用性测试来验证新的方案。
这是一个贯穿产品开发过程持续循环的过程：不断的发现问题-分析问题原因-修复问题-测试问题是否已得到解决。对设计进行修改可能会使用户体验变得更糟糕，所以设计时要考虑用户体验问题修复是否会造成新问题。
STEP8：输出可用性测试报告
可用性报告的价值在于：记录评估过程，帮助组织内部了解测试过程和内容。为产品开发过程提供有价值的信息，开发团队知道了问题所在才能更好的执行开发。
传达信息，并说服干系人，可用性测试报告可以有理有据的告诉干系人，我们的结论并非凭空产生，便于资源的申请。除此之外，还可以传递评估结果，树立用户体验意识等。
可用性报告的内容一般包括：
可用性测试常见问题
（1）可用性测试在设计过程中进行的太晚
其实，在整个产品研发周期内反复进行小规模的测试是最合适的，在产品完成初步原型时，就可以先进行可用性测试，快速发现问题，及时修改，避免上线后修改带来的成本浪费。
（2）觉得可用性测试很专业，且要花费大量人力财力，所以干脆不做
因为收益无法量化，项目排期又比较紧张，所以总被忽略掉。其实可用性测试门槛很低，不必等产品做好才开始，不一定非要由专家来做，更不一定要求专业的设备。只要能有一个环境观察用户操作产品，或多或少都会发现一些可用性的问题。
其他小问题就不多阐述了，希望本文对读者有所帮助。由于作者接触可用性测试也没有多久，文中难免有不足之处，有问题的地方和描述不清楚的地方，还望请读者多多指正，感谢。
参考文献
本文由@少穻原创发布于人人都是产品经理。未经许可，禁止转载