UX 质量视角 Skill：从失败场景中验证用户体验连续性

8 分钟阅读 PolyForm Noncommercial 1.0.0

AI 测试Agent SkillsUX 质量视角

界面没有报错，用户也可能卡在等待、理解、纠错或键盘操作上。UX 质量视角先记录这些任务状态，再判断用户能否继续完成目标。

UX 质量视角 Skill 检查任务流、反馈、可访问性和恢复路径，把体验拆成团队可以复核和修复的具体问题。

本文沿着结账流程，检查等待、超时、键盘操作和返回页面这些场景，看看用户到底卡在哪里。

Awesome QA Skills 按语言和测试阶段组织这些 Skill。目录结构和安装方式请先看系列总览；本文聚焦 UX 质量视角，重点说明状态、反馈和恢复路径如何影响用户完成任务。

先看源 Skill

主 Prompt 把工作拆成“适用性判断”“UX 问题”“输出合同”“证据与边界”“执行流程”几个部分。这些标题只是导航，真正使用时还要回到项目材料。

它支持需求分析（requirements-analysis）、测试策略（test-strategy）、测试策略评审（test-strategy-review）、代码评审（code-review）、测试用例编写（test-case-writing）、测试用例评审（test-case-review）、测试报告编写（test-reporting）和测试报告评审（test-report-review）。其中，测试策略（test-strategy）、测试策略评审（test-strategy-review）、代码评审（code-review）、测试用例编写（test-case-writing）和测试报告编写（test-reporting）属于条件参与，只有存在可追溯的界面影响或 UX 证据时才分析。文章正文使用中文阶段名，调用参数仍使用括号里的英文键名。即使没有原型，也可以进行需求分析，但输出应限于已知事实、体验证据缺口和待确认问题，不能凭空补出页面和交互。

UX 视角关注信息架构、导航、可发现性、交互反馈、状态、一致性、响应式行为和无障碍。它不替前后端确认实现是否正确，不替 QA 宣称测试通过，也不替发布负责人判断可以上线。

这个 Skill 没有单独的示例目录，文中的片段根据入口、主 Prompt 和评测约束整理。

相关 Skill

UX 质量视角关注用户是否能理解、完成并恢复任务。遇到跨角色或专项问题时，可以衔接下面这些 Skill：

Skill什么时候接上它补什么
产品质量视角体验问题已经影响业务规则或用户价值时把体验观察连接到任务、转化、信任和验收取舍
可访问性测试键盘、焦点、语义或辅助技术成为主要风险时检查可访问性标准、操作路径和可复现证据
多角色质量汇总体验结论要和产品、QA、技术材料一起决策时保留用户影响、技术约束和不同角色的分歧
技术质量视角体验问题依赖接口、性能、错误处理或观测信号时补充运行后果和技术证据边界
项目交付视角体验补证据会影响测试窗口或发布日期时跟踪补证据行动，不替 UX 判断体验通过

同一研发流程，UX 视角输出什么

UX 质量视角与产品、QA 共用八个阶段，但它只对有体验影响或体验证据的材料展开分析。阶段名称相同，问题和交付物完全不同：

阶段UX 视角要检查什么输出给团队的内容
需求分析任务、导航、状态、反馈、断点和辅助技术证据是否充分体验事实、证据缺口、待确认问题和责任角色
测试策略已证实的体验风险是否覆盖任务流、关键状态、设备、输入方式和无障碍体验覆盖范围、方法、观察信号和退出条件
测试策略评审策略是否遗漏有证据支持的状态、设备或辅助技术路径体验风险、策略缺口和补证据动作
代码评审PR 是否有可追溯的 UI 影响，变更是否符合已有设计和状态证据可证明的体验偏差，以及设计、研发和 QA 待补证据
测试用例编写已提供的任务、状态和设计要求能否转成可观察步骤有证据支撑的前置条件、步骤、预期和风险
测试用例评审用例是否覆盖已有证据支持的状态、输入方式、设备和辅助技术可证明的体验覆盖缺口和修订动作
测试报告编写记录能支持哪些任务、设备、输入方式和辅助技术结论已观察问题、影响、复现条件、责任和下一步
测试报告评审报告是否把局部截图或录屏外推成全部状态和设备通过证据范围、体验风险、信息缺口和行动

UX 报告的输出合同包含摘要、事实、证据、发现、风险、信息缺口、待确认问题、行动和信心等级。它可以说明“这个录屏证明了什么”，也要说明“这个录屏没有证明什么”。没有原型、流程、状态或设备证据时，最有价值的输出往往是“不适用”和补证据清单。

同一份研发材料交给三个视角时，差异可以这样看：

共同材料：支付回调延迟产品质量视角QA 质量视角UX 质量视角
需求、PR、回归记录、支付日志、超时录屏确认等待规则、重复扣款风险和业务接受人判断超时/重试/对账是否真正执行并有证据检查处理中/超时反馈、焦点、文案和恢复路径

结账流程的体验证据要落到动作

本节评审结账流程的反馈、错误恢复、键盘操作、文案和移动端体验，重点看用户下一步能不能继续。

任务状态观察证据对用户的影响改进动作
支付等待没有进度、超时或重复提交提示用户可能刷新或再次付款增加状态反馈和幂等提示
地址校验失败错误只显示在页面顶部用户找不到需要修改的字段把焦点和错误信息关联到对应输入项
键盘操作弹窗打开后焦点仍在背景键盘用户无法完成支付加入焦点管理和退出路径
移动端恢复返回页面后表单被清空用户需要重新输入保留安全的草稿状态

UX 结论要指向具体状态、用户影响和可验证的改进动作。

观察记录要能复现

体验问题很容易被一句“感觉不顺”带过。记录设备、入口、操作步骤、状态变化和用户是否能继续，才方便复核者重现。

记录字段示例
环境iOS Safari、慢网络、键盘操作
入口会员页 → 升级 → 支付
失败状态支付超时，订单仍处于处理中
证据录屏、埋点、可访问性树、客服记录

记录完成后，再由产品与技术负责人判断用户影响和修复优先级。

放进研发过程：让体验风险跟着状态一起交接

UX 问题要在需求、设计、开发和测试之间保持同一条复现路径。结账流程可以按下面的交接方式推进：

研发环节输入或产物需要确认的体验问题交付动作
需求评审用户任务、流程图、目标用户用户在等待、失败和恢复时要完成什么补齐任务状态和待确认问题
设计交接原型、文案、断点、设计规范空状态、错误、加载、键盘和移动端是否有设计保存状态图和交互说明
开发联调状态模型、组件、接口错误码页面能否稳定呈现反馈，输入和焦点是否保留记录状态变更、埋点和复现入口
QA 验证构建、设备、浏览器、辅助技术用户是否看见反馈、理解下一步并完成恢复录屏、步骤、可访问性树和缺陷链接
发布后复盘漏斗、客服记录、用户反馈用户是否在真实环境重复遇到卡点更新风险、Owner 和修复验收

支付等待可以先整理成一张状态表，再交给开发和 QA 共用：

状态用户需要看到什么用户可以做什么验收证据
idle当前金额、支付方式和提交条件检查信息并提交页面录屏、键盘路径
submitting正在提交，按钮状态明确等待，不重复提交网络日志、按钮状态
processing订单处理中、预计下一步或查询入口留在页面或安全离开订单状态、状态文案
timeout已超时、是否继续等待、是否联系支持查询、重试或退出慢网络录屏、重复点击记录
success支付结果和权益到账状态查看权益或订单订单与页面状态对照
failure失败原因和可执行的恢复方式修正信息后重试错误关联、焦点位置

开发联调时，状态表还可以直接转成组件验收条件：错误信息要和对应输入项关联，弹窗打开后焦点进入弹窗并能返回原位置，加载状态要避免重复提交，返回页面后允许保留安全的表单内容。无障碍和移动端不是最后再扫一遍的装饰项，它们会改变用户是否能完成同一条任务。

下面是一份基于假设材料的 UX 观察记录，展示如何把“感觉卡住了”写成可以交给研发复核的输入。这不代表当前产品已经存在这个问题。

stage: test-reporting
environment: iPhone Safari / 慢网络 / VoiceOver 开启
task: 会员支付超时后恢复升级
steps:
  1. 打开会员升级页并提交支付
  2. 将支付回调延迟到客户端超时
  3. 返回订单页，再回到升级页
observed:
  - 页面显示错误，但没有说明订单是否已经创建
  - VoiceOver 没有播报订单处理中状态
  - 返回升级页后地址输入被清空
evidence:
  - checkout-timeout.mov
  - order-status-response.json
  - repro-steps.md
user_impact: 用户可能重复付款，也可能放弃重新填写
inference: 失败恢复路径的信息、状态播报和表单保留策略仍需确认
action: 明确订单查询入口，补状态播报，保留安全字段并补键盘复核
owner: 前端负责人 / 产品负责人
status: pending
confidence: medium

复核时还要问几个具体问题：错误文案是否被读屏正确播报，焦点是否落到需要修正的字段，窄屏下状态提示是否被按钮或键盘遮住，慢网络下用户是否知道系统仍在处理。每个问题都应对应界面、原型、录屏、可访问性树或运行记录，不能靠审查者的印象收尾。

UX 摘要可以写得简短，但任务、状态、设备/输入方式、体验影响和证据边界必须保留。没有界面或任务证据时，只能写适用性判断、风险假设和信息缺口。

一段可以直接改的调用词

把下面方括号中的内容替换成项目材料。材料越具体，Skill 越不需要猜测。

请使用 ux-quality-perspective Skill。

阶段：测试报告评审（stage: test-report-review）
任务：评审结账流程的反馈、错误恢复、键盘操作、文案和移动端体验
版本与环境：[需求版本 / 构建号 / 环境]
输入材料：[文件路径或链接]
范围：[本次包含与排除的业务链路]
限制：[账号、数据、时间、合规要求]

请先判断 UX 视角是否适用，再按“摘要、事实、证据、发现、风险、信息缺口、待确认问题、行动、信心等级”输出。记录任务流、状态、设备/浏览器、输入方式、无障碍条件和截图/录屏/复现步骤。没有 UX 证据就写成 `not_applicable` 或 `evidence_gap`，不要输出代码正确性、测试通过或发布结论。

先给出一条完整任务路径和对应证据，再让 Skill 判断体验；没有截图或录屏时，先收集材料。

UX 视角先看用户在失败时能不能继续走下去

用户体验问题常藏在失败态：支付超时后是否重复扣款、地址校验失败后输入是否保留、接口报错后用户是否知道下一步。UX 视角把每个关键任务拆成开始、等待、失败、恢复和完成五个状态，再逐一检查反馈是否足够。

这类结论需要真实任务证据，例如原型、埋点、可用性观察或客服记录。没有这些材料时，可以提出风险假设，但不能替用户宣称“体验良好”。

这个 Skill 适合谁

设计师和产品经理可以用它检查任务流和失败态；QA 可以把体验问题写成可复现证据；前端和无障碍负责人可以据此安排焦点、反馈和恢复修复。没有真实任务材料时，结果只能是风险假设。

UX 证据交付前复核

UX 结论必须能回到一条具体任务路径和一个具体状态。复核时要确认设备、输入方式和无障碍条件没有被一句“体验正常”带过。

复核项需要留下缺失时
任务与流程起点、目标、关键路径和失败后的恢复路径标记流程缺口，不补写交互
状态与反馈加载、成功、失败、空状态、焦点和错误提示说明缺失的状态证据
使用条件设备、浏览器、屏幕宽度、输入方式和无障碍设置不把单设备观察推广到所有设备
UX 证据原型、截图、录屏、可访问性树、复现步骤或用户观察标记 evidence_gap 或 not_applicable
体验影响与行动用户影响、负责人、修复动作和信心等级区分事实、推断和建议
stage: test-report-review
applicability: applicable / not_applicable / evidence_gap
task: [用户任务]
flow: [开始、等待、失败、恢复、完成]
state: [被观察的界面状态]
device_browser_input: [设备、浏览器、屏幕宽度、输入方式]
accessibility: [读屏、键盘、焦点或其他条件]
evidence: [截图、录屏、原型、可访问性树或复现步骤]
experience_impact: [用户影响]
action:
  owner: [负责人]
  next_action: [下一步]
confidence: high / medium / low

“移动端通过”必须说明测过哪台设备、哪个浏览器和哪条路径；没有这些条件，只能保留为局部观察或证据缺口。

安装与调用

安装单个 Skill 就够了。项目总览里的安装说明不再在每篇重复。

npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-workflows/ux-quality-perspective -g

调用时直接写“请使用 ux-quality-perspective Skill”，然后附上真实材料。

常见问题

只有截图可以做 UX 评审吗？

截图能说明视觉状态，不能证明等待、键盘、读屏或恢复流程。最好补上可操作原型、录屏或实际观察。

没有用户研究怎么办？

使用任务流、埋点、客服记录和可访问性检查，明确哪些是观察，哪些仍需用户确认。

怎么判断体验问题已经修好？

重新走同一入口和失败路径，确认用户能看到反馈、理解下一步并恢复任务，同时保存复核证据。

UX 结论能替代功能测试吗？

不能。它补充任务流和可感知质量，功能、接口和安全验证仍要单独完成。

拿一条真实的结账任务路径跑 UX 质量视角，保留设备、状态、证据和复核意见。文章里的片段只能帮你搭起结构，项目证据还得在项目里产生。

参考

安全测试白盒测试背靠背测试本地化测试边界测试
分享