“好用”怎么验？先让真实任务走通

原创方法示例。以下是一套可用于讨论与试用的检查方法，不代表已经完成的用户研究或产品效果证明。

把评价写成一个动作

“界面清楚”“操作简单”很难直接验收。可以换成一句任务说明：“负责市场内容的同事，在已有案例列表中新增一篇中文案例，核对英文展示，并确认它什么时候会出现在已发布页面。”这句话同时定义使用者、起点、内容和预期结果。

先选择日常发生且确实重要的任务，不必一次覆盖全部功能。官网可选更新案例与联系方式，业务系统可选查询一条订单的进度。准备一组可公开的样例资料，包含正常内容，也包含较长标题、缺失图片等常见情况。

演示时少解释，记录具体位置

让负责这项工作的人自己操作。观察他们首先点击哪里，在哪一步犹豫，是否理解“保存”“发布”“停用”的差别。主持人可以确认任务目标，但不要每次都提前告诉对方正确入口，否则测到的只是对方能否跟随指导。

观察项	建议记录
任务起点	用户看到的页面与账号角色
完成标准	哪个可见结果说明任务结束
卡住的位置	页面、控件和当时的理解
错误恢复	输入是否保留，如何返回继续
后续核对	哪些页面或记录需要再次检查

换个条件，再验证

用手机重复关键步骤；检查键盘能否到达主要按钮；换成没有相关权限的角色；模拟一项资料缺失或请求失败。目标不是故意增加难度，而是确认真实环境稍有变化时，使用者仍能理解下一步。页面草稿与独立内容的生效方式不同，也需要分别核对。

用证据决定改什么

把“按钮不好找”写成具体观察：几位参与者在哪里停留、预期入口在哪里、需要了什么帮助。保留任务说明、测试环境和完成记录，再按影响排序处理。不要把少量样本换算成未经验证的效率提升比例。

第一轮可以只解决一个高频任务。改完后用相同任务重新检查，再补充尚未测试的角色和设备。这样得到的是一份可以复核的改进记录，而不是只有“感觉好一些”的评价。