更新时间：2026年10月14日

UI用户测试没有得到可用结论，先检查四件事：参与者是否有这类任务，任务说明是否暗示了操作答案，主持人是否过早提供帮助，原型是否真的能走到结果。只问“好不好看”或演示完再问“会不会用”，很难判断界面能否被独立使用。一次有效的测试应留下具体行为、发生位置和影响，团队才能决定改哪里。

用原型开展测试时，可以通过Pixso的原型设计与评审功能准备任务路径并收集讨论意见。这里要验证的是用户如何理解和操作页面，不能把工具里的播放成功等同于用户测试通过。

1. UI用户测试的重要性：让判断有行为证据

设计师熟悉每个按钮和页面，容易把自己的理解当成用户的理解。用户测试的价值，是在产品设计阶段观察潜在使用者的实际行为，提前发现文案、信息顺序或操作反馈中的障碍，再将结果反馈给团队。

例如，团队要确认用户能否在订阅页面找到“本月应付金额”。主持人如果说“点右下角的费用明细看看”，参与者顺利打开页面只能说明按钮能点击；改成“请确认这次需要支付多少，再决定是否继续”，才有机会看到用户会先看哪里、是否理解优惠、是否误把月费当成本次费用。

测试可以在不同设计阶段进行：早期用简单原型看任务与信息结构，方案收敛后看真实内容和异常状态，上线后继续观察使用中的新问题。它能帮助团队减少基于猜测的返工，但不能单凭一次测试保证商业成功，更不能把复杂产品的成败都归因于有没有做用户测试。

2. UI用户测试与可用性测试：先说清要回答什么

“用户测试”在日常讨论中常是宽泛称呼，可包括对概念、需求和界面使用的研究。可用性测试更具体：观察目标用户能否完成特定任务，以及在哪里遇到困难。两者不必争论成互斥术语，研究开始前先明确这次问题属于哪一类。

比较和探索适合回答不同的研究问题。比较时，用相同任务和内容评估两个版本，留意先看某版本带来的学习影响；探索时，让参与者讲述并尝试可信的场景，发现团队尚未考虑的限制。原型是承载设计问题的材料，访谈、观察现有服务等也可能更适合某些研究问题。

原型让团队在投入完整开发前尝试方案，围绕具体页面交流，也能把用户反馈更快地变成下一版设计。快速试错、及早发现不合适的功能、获得团队之外的视角、发现新的需求线索，都是值得保留的使用价值。

但反馈不会因为来自用户就自动客观。如果参与者被任务卡里的按钮名称引导，或所有错误分支都被原型省略，就可能得到过于顺利的结果。费用确认练习至少要让参与者看到金额、计费周期、优惠条件以及确认后的结果；如果某一步尚未实现，要提前记在主持人说明中，在记录里标明由此中断，不能归为“用户不会操作”。

同样，参与者停顿不一定是设计缺陷。可能是文案难懂，也可能是在计算金额或考虑是否接受费用。先问“你刚才在考虑什么”，再结合其操作判断，避免把所有停顿都改成更醒目的按钮。

在Pixso中按“方案选择—费用说明—确认结果”准备画板，再连接需要测试的按钮和返回路径。可以借助已有线框组件搭建表单、按钮和说明区域，把精力放在影响判断的内容上；测试金额理解时，真实而一致的费用文案比复杂转场更重要。

先请同事试跑一遍，确认起始页、链接权限、目标画板和结果页都能访问。预演的目的在于发现材料与脚本问题，不能用熟悉项目的同事代替正式目标用户。

GOV.UK的主持式可用性测试指南强调用可信且不提示答案的任务观察参与者。测试开始时说明这是在检查产品，参与者可以按自己的理解尝试。少解释界面；遇到含糊的表述，用“是什么让你这样想”追问，不急着纠正。

当用户完全卡住，可以提供必要帮助以继续了解后续环节，但记录帮助发生的位置与内容。例如“在费用说明入口得到提示后继续”，与“独立找到入口”应分开。观察者也要避免点头、指向控件或代替用户操作。

小轮次定性研究有利于发现问题后尽快修改再测。Nielsen关于五名用户的文章讨论了迭代研究和相似用户任务的条件，也指出不同用户群需要分别覆盖。不要把“五个人发现85%的问题”当成项目保证。新用户与续费用户对费用页面的背景不同，应按本轮问题安排覆盖，而不是凑齐一个固定人数就结束。