正式使用前，可以请一位没有参与制作的人尝试完成真实任务。对方需要知道产品是否适合、资料在哪里、怎样联系，而不应靠制作人员在旁提示。这类检查能够发现“设计时觉得明显，客户却找不到”的问题。
给测试者任务，不先告诉路径
假设任务是“找到 P100 的使用条件，下载手册，并提交一个咨询”。观察对方从首页或产品分享链接进入后在哪里停顿、误解或返回。若测试一开始就告诉他点击哪个按钮，就很难发现导航问题。
每个任务写清背景、起点和预期结果，例如“从销售发来的产品链接进入，判断指定用途是否适用，并找到需要补充的询价资料”。不要在任务里暗示按钮名称。根据实际访客选择手机或电脑及常见入口；少量测试用于发现具体障碍，不据此计算代表全部客户的成功率。
使用脱敏测试资料并事先通知接收人。演练以查找、阅读和普通咨询为主；若页面动作会触发真实订单、付款或其他不可随意撤回的处理，应先确定可用的测试方式和操作边界，不把业务后果当成普通点击测试。
沿客户任务检查四个阶段
| 阶段 | 观察内容 |
|---|---|
| 找到资料 | 栏目名称是否清楚，搜索或分类是否有用 |
| 理解内容 | 型号、单位、条件与图片是否对应 |
| 采取动作 | 下载、电话或表单入口是否清楚 |
| 得到结果 | 文件正确，需求真实接收，反馈可理解 |
若资料找到了却看不懂，问题通常不只是导航；若填写完成却无人收到，也不能只调整按钮外观。分阶段记录有助于确定修复方向。
把观察到的事实与解释分开
记录“测试者在两个栏目间往返三次，仍未找到手册”，比写“导航不好”更容易复查。先记访问入口、实际动作、停顿位置和最终结果，再询问他当时期待看到什么。未经询问，不把停顿直接归因为按钮颜色或文字太小。
卡住时先记录，必要的帮助另行注明。经提示才完成的任务与独立完成应分开；中途放弃也要记录停止在哪一步及原因。测试结束后再集中讨论调整，避免观察者边提示边把结果记成“全部顺畅”。
手机测试看实际遮挡与阅读
检查固定导航或联系栏是否盖住正文和按钮，参数表是否能对应行列，图片关键细节是否被裁掉。不要只把电脑浏览器缩窄一次就代表全部手机体验。
电话、微信和表单应适合当前设备使用。只显示当前手机屏幕上的二维码，可能需要额外操作，应提供清楚可用的替代联系方法。
故意制造可控的输入错误
测试漏填必填项、格式不符和附件失败时的提示。客户应知道哪里需要修正，已经填写的内容不应无故消失。对结果不确定的超时，应避免诱导反复提交。
正常测试结束后，接收人员核对字段、来源页面与附件；客户看到成功，不能替代接收端确认。
把问题写成可复查事项
问题记录采用“任务、设备、入口、步骤、预期、实际、影响”的格式。例如：“从手机产品页下载 A 型号手册，实际得到 B 型号文件，导致无法核对适用条件。”这比“下载有问题”更方便定位，也能直接作为修复后的复测任务。
按影响排序：错误资料、无法联系等阻断任务的问题优先；需要额外提示才能完成的入口其次；不影响判断的样式偏好单独记录。优先级基于这次测试中的实际影响，不凭问题看起来是否容易修改来决定。
每条问题指定处理人和复查条件。例如手册链接错误，复查应从原来源页进入，确认下载的是对应型号和版本，而不只是按钮已能点击。修复表单接收问题，则再次核对页面结果与接收端记录；优先复测原先失败的设备和入口，再抽查受改动影响的相关位置。
复查结果保留通过、未通过或因条件不足暂未验证，并记录日期。体验测试仍需与业务资料确认及技术检查配合；一个任务顺畅完成，只能证明该条件下的这条路径，不能替代所有页面、权限和异常场景的检查。
如需检查官网上线体验，可私聊客服，提供网址、主要客户任务和发现的问题，沟通测试与调整范围。
