可用性测试中，用户的一句“挺好的”可能暗藏玄机。本文通过数十次测试经验总结，拆解有效反馈与无效反馈的本质差异，并针对数据类、表单类、导航类等不同功能场景，提供精准追问话术与优化策略，教你如何从用户行为中挖掘真实需求。

一、可用性测试的基本逻辑

做了几十次可用性测试之后，发现一个规律——产品经理容易犯的错误，就是把”用户说好”当成”产品做好了”的决策依据。

用户是一个很难拒绝别人的生物。你请他坐下来，打开你的产品，问他”你觉得这个界面怎么样”——大概率得到的回答是”挺好的”。听起来不错，但这句话的信息量几乎为零。

“挺好的”可以是”确实不错”、”还行但我不想多说话”、”这个功能我其实用不上”，甚至可以是”我不想打击你”。同一个词背后完全不同的信息状态，取决于用户的性格、当天的状态、跟你熟不熟。

可用的反馈是什么样的？是跟操作绑定的。

用户说”我点了一下这个地方发现没反应”、”我以为这里是能输入的”、”我找了一会儿才找到这个按钮在哪”——这些话背后有清晰的操作路径，你能复现他的操作，能定位到具体的问题节点。”挺好”背后什么都没有。

这不是用户的配合度问题，这是测试方法的问题。用户不是专业的可用性测试师，他们不会主动告诉你哪里不好——他们只会按你的引导给出他们以为你想要的答案。产品经理要做的事不是”听用户评价”，而是”设计让用户操作的场景，观察他的行为”。

可用性测试的核心逻辑：不评价，只操作。用户的评价可以作为参考，用户的行为才是决策依据。

二、有效反馈、低效反馈、无效反馈

做了几十次测试后，把用户反馈分成了三类。

有效反馈是指向具体操作路径的。用户说”我点这个标签页的时候，以为会展开内容，但它跳到了另一个页面”——这是有效反馈，因为你知道了用户在哪个节点产生了错误的预期。你能针对这个节点做优化：改成展开内容，或者加视觉提示说明这里是跳转。

用户说”这个表太长了，我找不到我要的那一行”——这是有效反馈。”太长”是感官描述，但”找不到我要的那一行”指向了具体问题：信息密度高、缺少筛选、行视觉区分度不够。后续可以落地的选项是清晰的。

低效反馈是感受型的。用户说”感觉怪怪的”——你没办法直接执行。追问方向不是”怎么改”，而是”你第一次看到这里的时候，你本来期待的是什么”——把”感受型反馈”翻译成”预期型反馈”，才能定位到问题。

无效反馈是”挺好的”、”还行吧”、”没什么感觉”。这类反馈的价值在于告诉你：这个部分没让用户产生强烈的负面感受。但它不能作为决策依据——”没触发投诉”不等于”体验足够好”。

一次标准的可用性测试中，有效反馈大约占30%-40%，低效反馈40%-50%，无效反馈10%-20%。比例取决于两个因素：一是任务场景的设置（场景越具象，有效反馈占比越高）；二是研究员的追问能力（追问能力越强，有效反馈占比越高）。

无效反馈占比低并不代表处理优先级高——恰恰相反，无效反馈通常出现在没有大问题的模块。有效反馈占比才是衡量测试质量的核心指标。一次测试中有效反馈低于20%，说明要么任务场景设置太抽象，要么追问能力不足。

三、UAT环境下的测试场景拆解与追问话术

以下按照不同的功能场景类型，对照该系列第一篇《百次客户对话提炼：值得收藏的交互设计沟通万能公式》中的场景，逐一拆解用户的典型反馈，给出对应的追问策略和话术。每个场景都包含：场景描述 → 典型用户反馈 → 追问策略（含正向/反向）→ 核心技巧。

4.1 数据类功能——列表、筛选、搜索、导出

场景：列表页面数据展示

用户在列表页查看数据，可能出现的问题是：信息不知道如何排列、字段过多或过少、找不到特定的数据。

典型用户反馈一： “这个列表太长了，翻了好几页也没找到我要的东西。”

有效追问：

“翻了好几页——你本来要找的是哪一条数据？”

这个追问的核心逻辑是让用户说出他的目标是什么。如果目标是”找一条昨天提交的待办”，那问题可能是排序方式不对（按时间倒序但用户期望按状态排序）、缺少快速定位手段（搜索或筛选）、或者视觉区分度不够。知道了目标，你就能判断是功能缺失还是交互表达不到位。

反向追问（如果用户说列表太短）：

“你觉得列表应该展示多少条数据会比较合适？”

这个追问不是让用户给你一个精确数字（用户给出的数字不一定是最优解），而是让你判断用户的真实需求——他是觉得翻页效率低（需要更大的单页行数），还是觉得数据密度不够（需要一次看到更多维度的信息）。

核心技巧： 列表类的问题，先问目标（找哪条数据），再问预期（你觉得应该怎么找）。目标决定了方向，预期决定了参照。两个信息都有了，优化方案自然浮现。

典型用户反馈二： “这个搜索框我找了半天，原来在右上角。”

有效追问：

“你第一次进来的时候，你本来是往哪个方向去找搜索的？”

这个追问让用户告诉你他的”默认搜索位置预期”。用户的回答会分为几类：有人习惯左上角（因为阅读顺序从左到右）、有人习惯顶部中央（因为百度/谷歌搜习惯了）、有人习惯右上角（跟你的设计一致）。如果是前两种，说明你的搜索框位置跟用户的预期有偏差，需要评估是改位置还是加视觉引导。如果多数用户的习惯都是一致的，那问题出在搜索框的视觉层级不够突出，而不是位置本身的问题。

反向追问（如果用户很快就找到了搜索框）：

“用了之后感觉怎么样？搜索结果符合你的预期吗？”

“找到搜索框”只是第一步，”搜索结果质量”才是长期体验的关键。用户找到了但搜不出想要的结果，比找不到搜索框更致命——因为前者让他觉得”这个系统不好用”，后者只是”这个系统还没习惯”。

核心技巧： 搜索类的问题分两层：找不找得到（定位问题）和用得好不好（精准度问题）。两层要分开问，不能混在一起。

典型用户反馈三： “导出的时候我没有看到进度提示，我以为没点成功，又点了两次。”

有效追问：

“你点了导出之后，你当时期望页面出现什么反应？”

用户的回答会告诉你他的”操作反馈预期”。有人期望弹窗提示”导出中”，有人期望按钮变成灰色”不可点击”，有人期望进度条出现。任何形式的即时反馈都比”什么都没有”好。用户又点了两次不是他的操作失误，是系统没有给足反馈信号。

反向追问（如果用户说导出很快、不需要进度提示）：

“如果是导出几千条数据的时候，也不需要提示吗？”

这个反问把”当前场景”扩展到”极限场景”。用户在测试环境导出几十条数据时可能真不需要进度提示，但上线后导出几万条数据时，没有进度提示用户就会反复点击、刷新、甚至认为系统崩溃了。可用性测试中一个常见短板就是：只在正常数据量下测试，没覆盖数据量大、网络慢、系统负载高的边界条件。

4.2 表单类功能——输入、校验、提交、反馈

场景：表单填写与提交

用户填写表单时，可能出现的问题是：不知道填什么、填了之后校验报错、提交后不知道成功与否。

典型用户反馈一： “我这个字段填完了，下一步怎么做我不太确定。”

有效追问：

“你填完之后，你本来是打算怎么继续的？”

这个追问让用户描述他的”操作连续性预期”。用户的预期操作路径跟实际设计路径之间的差距，就是你需要填补的交互缺口。如果用户说”我填完最后一个字段后，我以为它会自动保存或进入下一步”——说明表单缺少”完成感”反馈（比如自动跳转、成功提示、下一步按钮高亮）。如果用户说”我找了一圈，才发现提交按钮在左上角”——说明按钮位置跟用户预期不匹配。

反向追问（如果用户说”按钮挺明显的，我填完就看到了”）：

“你能接受填完之后在当前页面看到提示，还是更希望能自动跳转到下一步？”

这不是让用户做决策，而是让用户暴露他的操作习惯偏好。B端产品中不同用户群体的预期差异很大——操作频繁的用户希望自动跳转（减少点击）、偶尔使用的用户希望看到明确提示（确认操作成功）。知道你的主流用户群体属于哪种，才能决定默认方案。

核心技巧： 表单问题中，用户”卡在哪个节点”和”预期下一步怎么走”是两个同等重要的信息。

典型用户反馈二： “我填了数据之后，提交的时候弹了一堆错误提示，也不知道从哪里开始改，改完一个后面的校验又变了。”

有效追问：

“你看到错误提示的时候，你第一反应是先改哪一个？”

这个追问揭露了两个问题。第一：错误提示的显示区域是否在用户的视线预期内。如果用户说”我翻到页面底部才看到提示”，说明错误提示应该放在表单上方或字段旁边，而不是在底部只出现一次。第二：错误提示的排序逻辑是否合理。用户倾向于从上到下或按严重程度修改，如果你的提示顺序跟用户预期的修改顺序不一致，他就会觉得”改完一个又冒出一个”。

反向追问（如果用户说错误提示很清楚、知道怎么改）：

“你能接受提交时一次性校验所有字段，还是希望离开每个字段时就单独校验一次？”

这是个经典的交互设计取舍：即时校验（每个字段填完就校验，用户体验好但开发成本高）vs 提交时校验（一次校验所有字段，开发成本低但用户体验差）。你问用户这个问题不是为了让他决定技术方案，是为了了解用户的容忍度。如果大部分用户希望即时校验，那这个功能就是优先级较高的改进项。

核心技巧： 校验类问题，不要只看”提示清不清晰”，还要看”提示出现的时机合不合理”。

典型用户反馈三： “提交之后页面没变化，我不确定有没有提交成功。”

有效追问：

“你点了提交按钮之后，你当时期望页面上出现什么变化？”

这跟导出进度提示是同一个问题域——”操作已发生”的反馈信号要明确。用户期望看到的东西各有不同：弹窗提示、按钮变灰、表单重置、页面刷新跳转、或者底部出现一条”提交成功”的toast通知。不论哪种，关键是要有。用户点了提交后页面无变化，在用户视角就等于”操作无效”。

反向追问（如果提交后页面跳转了，用户说没问题）：

“如果提交之后你发现还需要补充一些数据，你更希望能够直接在已提交的表单上修改，还是重新填一份新的？”

这个问题测试的是”成功后的再编辑路径”。用户提交后如果需要修改，系统的容错设计是否能让用户方便地完成”提交→发现错误→修改→重新提交”的闭环，是可用性的另一个重要维度。如果用户说”希望能直接修改”但系统只能重新填写，那这就是下一个优化的方向。

4.3 流程导航类功能——菜单、层级、跳转、返回

场景：多步骤或多层级操作

用户在一个多步骤流程或多层级菜单中操作时，可能不知道自己在哪、下一步要去哪、如何回到上一步。

典型用户反馈一： “我点了这个菜单之后，不知道我进入到哪个页面了。”

有效追问：

“你进到这个页面的时候，你第一眼看的是什么？”

这个追问的目的是判断用户的”信息阅读顺序”。如果用户说”我习惯看左上角有没有页面标题”——那么问题可能是页面标题不够突出、或者标题跟菜单名称不一致。如果用户说”我先看内容，从内容来推断我到了哪里”——那么问题可能是内容区域的视觉层次没有建立清晰的”当前位置感”（比如面包屑导航缺失、或者页面头部缺少当前模块标识）。

不同用户的页面定位习惯不一样，但产品不可能同时满足所有习惯。关键是通过测试找到主流用户的定位习惯，然后统一用这个习惯来设计反馈机制。

反向追问（如果用户说通过面包屑知道自己在哪）：

“如果这个流程有5步，你走到第3步的时候，你想不想知道后面还有几步？”

这个问题测试的是”进度感知”的需求。对于多步骤流程，有时候用户需要的不只是”我当前在哪”，还有”我还有多久才能完成”。如果用户说想知道后面还有几步，说明你的流程需要增加步骤进度指示。B端产品的业务流程往往有固定步骤（比如合同审批：发起→部门审核→法务审核→领导审批→归档），五步走完需要时间，没有进度提示用户会焦虑。

核心技巧： 导航问题分三层——”我在哪”（当前位置）、”我从哪来的”（上一步骤）、”我还得多久”（剩余进度）。三层都要有反馈，不能只解决一层。

典型用户反馈二： “我做完这个操作之后，页面回到了首页，但我本来还想继续做另一个操作。”

有效追问：

“做完上一步之后，你本来期望接下来做什么？”

这是个经典的”流程断点”问题。用户完成了一个操作后，系统的默认跳转方向跟用户的后续操作预期不一致。用户说”我本来还想继续做另一个操作”——说明系统应该保留用户的操作上下文，而不是直接跳转到首页或列表页。很多B端产品在”操作完成后跳转到哪”这个问题上，用的是”开发最方便的实现方式”（返回列表页），而不是”用户最自然的延续路径”（比如提供”继续操作”的选项或保留当前页面以便用户在相近模块间切换）。

反向追问（如果用户说系统跳转方向是对的，不需要改）：

“如果在当前操作完成之后，系统能给你一个选项让你选择下一步去哪，你会觉得有用吗？”

这个问题测试的是”可控性”的需求等级。如果用户说有用，说明跳转问题不只是”默认路径不对”，而是”系统应该给用户跳转的选择权而不是默认行为”。

4.4 信息阅读类功能——布局、字体、图表、排版

场景：信息展示与阅读

用户在阅读信息时，可能遇到排版不清晰、信息层次混乱、数据表达不清、视觉疲劳等问题。

典型用户反馈一： “这个页面的东西太多了，我看不过来。”

有效追问：

“你在这个页面上最常关注的是哪一块信息？我帮你看看能不能把它做得更突出。”

这个追问把”东西太多”这个笼统的问题，拆解成了”哪些信息对用户是重要的、哪些不重要”。用户指出的”最常关注的信息”如果不能在一秒钟内找到，那就是信息架构的问题——优先级最高的信息没有占据最重要的视觉位置，或者被次要信息淹没。知道了用户的信息优先级之后，有两种优化方向：一是调整信息布局，把高频信息放在视觉重心；二是对低频信息做”可折叠”或”默认收起”的设计，减少信息密度。

反向追问（如果用户说信息刚好、不觉得多）：

“如果同时需要处理3条待办，你更倾向于用列表还是用卡片来展示？”

“信息密度”这个问题的复杂性在于：不同的用户的承受力不同。老手用户可能觉得信息密度越高越好（可以快速扫描），新手用户觉得信息要少而精（减少干扰）。这个追问让用户暴露他的使用场景和偏好，帮你判断你的产品应该采用哪种默认方案（或者是否要给用户提供切换选项）。

核心技巧： 信息密度问题，用户的偏好差异可能很大。关键在于区分主流用户群体，按主流用户的偏好设计默认方案，把另一种方案作为可选项保留。

典型用户反馈二： “这个图我看不懂，不知道它想表达什么。”

有效追问：

“你看到这个图的时候，你先看的哪个部分？你希望它能回答你的什么问题？”

两个问题的维度不同。第一个问题”先看哪”暴露了图表的视觉引导是否合理。如果用户先看了一个次要数据指标，说明图表的信息层级没有把核心指标放在视觉重心。第二个问题”希望回答什么问题”暴露了图表类型是否匹配。用户说”我想知道上周和这周的对比”但你给了一个饼图，那问题不是图好不好看、是图选错了类型。

反向追问（如果用户说图表看得懂、很清楚）：

“如果把这表格转换成图表展示，你会觉得更直观还是更习惯看表格？”

这个追问判断用户是”文字型思维”还是”图形型思维”。不同的用户群体对信息载体的偏好不同。知道了这一点，你在设计时就不会盲目堆数据可视化——有些场景下表格比图表更适合。

4.5 操作反馈类功能——状态、错误、提示、确认

场景：系统反馈与用户预期对齐

用户操作后系统的反馈方式，决定了用户对”操作是否成功”的判断。

典型用户反馈一： “我点了一下这个按钮，页面没反应，我又点了一下，还是没反应。”

有效追问：

“你点了之后，你期望页面出现什么变化？”

几乎所有”点了没反应”的问题，根源都在于”系统的反馈速度不符合用户的预期”。用户的预期可能是：按钮变灰表示已点击、出现loading动画表示正在处理、立即跳转表示操作成功。如果页面没有任何变化，用户会认为操作无效并重复点击——这不是用户的问题，是系统没有给出任何操作已注册的信号。

反向追问（如果操作确实有反馈，用户没注意到）：

“你点完之后，有没有注意看页面上的某个位置有没有变化？比如弹窗、提示文字之类的东西？”

这个追问的目的是区分”反馈不存在”和”反馈存在但用户没看到”。如果反馈是存在的（比如底部有一个轻量toast提示），但用户没有注意到——说明反馈信号不够强、位置跟用户的视觉区域不匹配、或者反馈消失得太快。这个信息告诉你：需要的不是加反馈，是把已有的反馈做得更”必看”。

核心技巧： 操作反馈问题的核心判断是：用户到底是没有收到反馈，还是收到了但没看到。两个问题的解法完全不同。

典型用户反馈二： “我点了删除，它弹窗问我’确定要删除吗’，我点了确定，然后就什么都没了。”

有效追问：

“你点了确定之后，你期望看到的是什么？”

删除操作的反馈跟正常操作的反馈有些不同。用户在点击”确定删除”后，期望看到的可能不只是”操作成功”提示，还有一个清晰的”现状确认”——比如”这个数据确实已经不在列表中了”。如果用户点了删除、点了确定、然后页面没有任何变化（即使系统已经删除了数据），用户会觉得：是不是没删除？要不要再删一次？系统状态跟操作结果之间的呼应要明确。

反向追问（如果没有二次确认弹窗，用户直接删了数据）：

“如果删除之前没有弹窗确认，点一下就删了，你会不会有顾虑？”

不是所有操作都需要二次确认。删除一条垃圾数据、清空一个临时列表——这些场景下过多的确认弹窗反而降低效率。用户说”有顾虑”说明需要保留确认；用户说”不用，我本来就是来清理数据的”说明你可以在某些场景下减少确认弹窗，提高操作效率。设计方案要基于用户的真实反馈来平衡”防错”和”效率”。

4.6 不同用户类型的差异化追问策略

不同的用户类型，追问的方式和切入点需要不同。以下按三种常见用户画像给出建议：

新手用户（使用产品时间少于1个月）

新手用户的反馈特点是：他们说不清楚”问题在哪”，但他们的操作路径能最真实地反映新用户的学习成本。

追问重点应该放在操作层面，而不是评价层面。不要问”你觉得这个功能好不好”，要问”你之前做这个操作，是在哪个系统里做的？那个系统是怎么做的？”

新手用户的反馈价值在于：他能暴露产品的前期引导是否够用。他们关注的是功能的可见性和可理解性——”这个按钮是干嘛的？”、”我点这里会发生什么？”。

熟手用户（使用产品3个月以上，日常使用频率高）

熟手用户的反馈特点是：他们知道系统能做什么，但希望”做得更快”。

追问重点应该放在效率提升上，而不是功能完整性上。不要问”这个功能够不够”，要问”你每天用这个功能的时候，哪些操作最浪费时间”。

熟手用户关注的是快捷键、批量操作、默认选项、自定义视图——任何能减少操作步骤数的优化方向。他们的反馈不暴露”不存在的问题”，但能暴露”效率瓶颈”。

专业用户（行业专家级用户，使用产品作为工作核心工具）

专业用户的反馈特点是：他们能精确描述问题和期望，但也最容易给出”解决方案层”的建议。

追问重点应该放在将”解决方案翻译回问题层”上。当专业用户说”这里应该用XXX方式处理”时，不要直接采纳，要追问”你觉得用XXX方式解决的是哪个问题”。

专业用户的反馈需要”过滤”后再使用——他们的解决方案不一定适用于主流用户群体，但他们发现的问题通常是真实的。

四、测试任务设计的五个原则

可用性测试的质量，50%取决于测试任务的设计。任务设计得好，用户不需要引导就能说出有效反馈；任务设计得不好，你问再多问题也得不到有用信息。

第一：任务要场景化，不要功能化。

一个功能指令和场景化任务之间的差距，决定了用户的测试状态是”点功能”还是”做业务”。

❌ 不好的例子：”请使用导出功能”——用户不知道为什么要导出、什么时候需要导出，自然不会带着实际操作中的感受去测试。

✅ 好的例子：”假设你下周要出差，需要把手上这个审批列表带到路上看，你会怎么做”——用户一听就知道需要把数据导出带走，然后基于真实场景操作。操作过程中的卡顿、疑惑、绕路都会暴露出来。

第二：任务要有具体的完成标准。

“请看看这个页面”不是测试任务，因为没有完成标准。用户看完不知道该不该说”好了”。

“请在这个列表中找到一条2025年3月提交的、金额超过50万的合同”——有完成标准的任务。用户找到或没找到、时间花了多久、中间绕了几次路，都是可量化的。

第三：不要在任务描述里包含操作提示。

❌ 不好的例子：”请点击左侧菜单的统计报表，然后找到月度报表”——你告诉用户怎么走了，测试的意义就消失了大半。

✅ 好的例子：”请查看上个月的项目完成情况”——用户会自己去菜单里翻。翻到了是正常路径，翻不到是导航设计的问题，翻到但路径很长是信息架构的问题。每一步都暴露了产品的真实状态。

第四：难度从易到难排列。

前两个任务应该是1-2分钟内能完成的简单任务，帮助用户建立信心和舒适感。中间是核心功能路径，设计1-2个用户日常使用频率最高的场景。末尾放一个略带挑战性的任务，观察用户在遇到困难时的应对策略——是放弃、绕路、还是寻求帮助。这个信息对设计帮助系统很有价值。

第五：每个任务结束后问一个固定结构的问题。

“这个任务你觉得难吗（1-5分）？”——定量。

“你觉得难度在哪里？”——定性。

“你有没有在其他系统里做过类似的操作？”——预期参照。

前两问在每个任务后都做，后一问根据情况选择。核心顺序：先让用户评价，再让用户解释，再让用户参照。 评价获取定量数据（方便不同任务之间对比），解释获取定性信息（定位具体问题），参照获取期望基线（了解用户对类似功能的预期水平）。

五、测试中的三个大坑

第一个坑：引导式提问

“你觉得这个入口好找吗？”——这已经暗示了”可能不好找”。

“如果你要找XX功能，你会从哪里开始？”——这是中性的，用户没有受到暗示。

前一个问题无形中给了用户一个方向性暗示，后一个让用户基于自己的真实判断来行动。产品经理在做测试时，最担心”用户找不到”，所以忍不住问”你觉得好找吗”。这个问题不是帮用户纠偏，是帮自己缓解焦虑。需要克制——用户找不到，本身就是有价值的测试结果。

第二个坑：用户一卡顿就提示

“可能你点击这里会快一点”——这句话一出，接下来的测试结果就失真了。你提示了他，他就知道了，你观察到的行为不再是用户自己的行为。

用户卡顿了，第一反应应该是：拿笔记下来——”用户在这里卡顿了15秒，最终通过点击XX找到了”。这个记录比提示更有价值，因为它告诉你在哪个节点上需要优化。如果用户卡顿超过3分钟，可以适当提示，但要在后续的数据记录中标注”有提示”，以区分”自然完成”和”在提示下完成”。

第三个坑：只看结果不看过程

用户完成了任务，用时也比预设短——你可能会觉得产品体验不错。但如果你回看录屏：用户点了A→发现不对→退回→点了B→点了C→返回→重新检查→最后点了D完成了任务——这个操作路径跟你设计的路径差了一大截。

结果完成率100%，但完成路径跟预期不一致。说明产品虽然能到达终点，但用户到达的方式跟你设计的路线不同。如果用户的路径中包含了多余的操作步骤，其他用户也可能重复这些多余步骤。定期回看录屏、关注操作路径而非结果完成率，能发现很多”结果很好但路径不顺”的问题。

六、如何判断测试结果够不够用

可用性测试做到什么时候算够了？不是”测完所有功能”，是”从最新一轮测试中获取的信息创新率低于20%”。

如果这一轮测试中80%的问题在上轮已经发现过了，只有不到20%是新问题——说明测试已经覆盖了用户的核心体验路径，可以进入下一轮优化了。

如果这一轮测试中新问题的占比超过50%，说明之前的测试覆盖都不够，需要继续测。

这个判断逻辑比”测5个人就够了”更实用——5个同一背景的用户和5个不同背景的用户，信息创新率完全不一样。

测试后的分析建议分为三个步骤：

第一步：汇总所有问题清单。 把每一轮测试中记录的问题全部列出来，按用户维度归类。

第二步：按严重程度分级。 严重=用户无法完成任务、只能退出或求助；中等=用户能完成任务但路径不畅、用时显著延长；轻微=用户能完成任务但感到困惑或觉得不舒服。

第三步：按优先级排序。 严重问题>中等问题>轻微问题。同类问题中出现频次高的优先处理，频次低的放到下一轮优化时处理。

排序逻辑：可用性优化的本质是”修复用户使用中最大的障碍”，不是”把所有问题一次性修复”。严重问题影响用户完成任务的意愿，是第一优先级。中等问题影响效率，是第二优先级。轻微问题有时间就改，时间排不上可以放。

七、收尾

可用性测试这件事做多了以后，有一个感触越来越深：它检验的不是用户会不会用你的产品，是你有没有站在用户的角度理解自己的产品。

• 你说”这个按钮很明显”——用户找不到，那就是不够明显，跟你设计时的判断没有关系。
• 你说”这个流程很自然”——用户走不通，那就是不自然，跟你设想的”自然是正确路径”没有关系。
• 你说”这个页面信息很清楚”——用户说”东西太多了看不过来”，那就是不清楚，跟你设计时的信息层级判断没有关系。

可用性测试的价值不在于”发现了多少问题”，在于发现了你之前认为自己没问题的地方。那些”我以为没问题”的地方才是真正值钱的信息——因为它修正的不是界面，是你的判断。