对抗性 UX 测试 —— 为您的产品扮演最难对付、抗拒技术的用户

{/* 此页面由 website/scripts/generate-skill-docs.py 从技能的 SKILL.md 自动生成。请编辑源文件 SKILL.md，而非此页面。 */}

对抗性 UX 测试

为您的产品扮演最难对付、抗拒技术的用户。以该角色浏览应用，找到每个 UX 痛点，然后通过实用主义过滤器将投诉分类，将真正的问题从噪音中分离。仅针对真实问题创建可操作的工单。

技能元数据

来源	可选 —— 使用 hermes skills install official/dogfood/adversarial-ux-test 安装
路径	optional-skills/dogfood/adversarial-ux-test
版本	1.0.0
作者	Omni @ Comelse
许可证	MIT
平台	linux, macos, windows
标签	qa, ux, testing, adversarial, dogfood, personas, user-testing
相关技能	dogfood

参考：完整 SKILL.md

:::info 以下是 Hermes 在触发此技能时加载的完整技能定义。这是技能激活时代理所看到的指令。 :::

对抗性 UX 测试

为您的产品扮演最可怕的用户 —— 那个讨厌技术、不想要您的软件、会找出所有投诉理由的人。然后通过实用主义过滤器筛选他们的反馈，将真正的 UX 问题与”我讨厌电脑”的噪音分开。

可以把它想象成一个自动化的”老妈测试”—— 但脾气暴躁。

为什么这有效

大多数 QA 发现的是 Bug。这发现的是摩擦。一个技术上正确的应用对真实用户来说仍然可能无法使用。对抗性角色能够捕捉：

• 令开发者觉得合理但对用户来说令人困惑的术语
• 完成基本任务需要太多步骤
• 缺少新手引导或”啊哈时刻”
• 可访问性问题（字体大小、对比度、点击目标）
• 冷启动问题（空状态、无演示内容）
• 付费墙/注册摩擦导致转化率下降

实用主义过滤器（第 3 阶段）是让这变得有用而非仅有趣的关键。没有它，你会因为”爷爷不会用 PDF”而在每个页面上添加”打印此页”按钮。

如何使用

告诉代理：

"对 [URL] 运行对抗性 UX 测试"
"扮演一个暴躁的 [角色类型] 测试 [应用名称]"
"对我的暂存站点做一个混蛋用户测试"

您可以提供角色，或让代理根据产品的目标受众生成一个。

步骤 1：定义角色

如果未提供角色，通过回答以下问题生成一个：

1. 这个产品最难对付的用户是谁？（50 岁以上、非技术岗位、用”老方法”做事数十年）
2. 他们的技术熟练程度如何？（越低越好 —— 只会用 WhatsApp、纸质笔记本、老婆帮他们设置邮箱）
3. 他们需要完成的一件事是什么？（他们的核心工作，不是你的功能列表）
4. 什么会让他们放弃？（点击太多、术语、慢、困惑）
5. 他们沮丧时怎么说话？（直率、骂骂咧咧、不屑一顾、叹气）

好的角色示例

“大块头 Mick” McAllister —— 58 岁的体能教练。只会用 WhatsApp。他的”电子表格”就是纸质笔记本。“如果 10 秒内搞不定，我就用回我的笔记本。“需要记录 25 名球员的训练结果。讨厌小字、术语和密码。

不好的角色示例

“一个不喜欢这个应用的用户” —— 太模糊，没有约束，没有特征。

角色必须足够具体，能够在 20 分钟的测试中保持角色一致。

步骤 2：成为混蛋（以角色身份浏览）

1. 阅读任何可用的项目文档以了解应用背景和 URL

2. 完全融入角色 —— 他们的挫折、限制、目标

3. 使用浏览器工具导航到应用

4. 尝试角色的实际任务（不是功能导览）：

   • 他们能完成想做的事情吗？
   • 需要多少次点击/多少个页面？
   • 什么让他们困惑？
   • 什么让他们生气？
   • 他们在哪里迷路？
   • 什么会让他们放弃并回到老方法？

5. 测试这些摩擦类别：

   • 第一印象 —— 他们会在落地页就放弃吗？
   • 核心工作流 —— 他们最常需要做的那一件事
   • 错误恢复 —— 当他们做错事时会发生什么？
   • 可读性 —— 文本大小、对比度、信息密度
   • 速度 —— 感觉比他们当前的方法快吗？
   • 术语 —— 有哪些他们看不懂的行话？
   • 导航 —— 他们能找回来路吗？知道自己在哪里吗？

6. 对每个痛点截图

7. 检查每页的浏览器控制台是否有 JS 错误

步骤 3：咆哮（以角色身份写反馈）

以角色的身份写反馈 —— 用他们的语言，表达他们的挫折感。这不是 Bug 报告。这是真实的人在发泄。

[角色名称] 对 [产品] 的评测

总体评价：[他们会继续使用吗？是/否/有条件地]

好的方面（勉强承认）：
- [连他们也不得不承认好用的东西]

糟糕的方面（真实的 UX 问题）：
- [会阻止他们使用产品的真实问题]

丑陋的方面（阻碍性因素）：
- [会导致他们立即卸载/取消的东西]

具体投诉：
1. [页面/功能]："[角色原话]" — [发生了什么，期望的是什么]
2. ...

结论："[一句话角色原话总结他们的体验]"

步骤 4：实用主义过滤器（关键 — 不可跳过）

跳出角色。 以产品人的身份评估每个投诉：

• 红色：真正的 UX Bug —— 任何用户都会遇到此问题，不限于脾气暴躁的用户。修复它。
• 黄色：有效但低优先级 —— 真实问题但仅针对极端用户。记录下来。
• 白色：角色噪音 —— “我讨厌电脑”在说话，不是产品问题。跳过。
• 绿色：功能请求 —— 隐藏在投诉中的好主意。考虑它。

过滤标准

1. 一个 35 岁、能干但忙碌的用户会有同样的投诉吗？→ 红色
2. 这是真正的可访问性问题（字体大小、对比度、点击目标）吗？→ 红色
3. 这是”我希望它像纸质一样工作”对数字化的抗拒吗？→ 白色
4. 这是角色偶然发现的真正工作流低效问题吗？→ 黄色或红色
5. 修复这会为 80% 觉得没问题的人增加复杂性吗？→ 白色
6. 投诉是否暴露了缺少的新手引导时刻？→ 绿色

此过滤器是强制性的。 切勿将原始角色的投诉作为工单提报。

步骤 5：创建工单

仅针对红色和绿色项目：

• 明确、可操作的标题
• 包含角色原话（有趣 + 易于记忆）
• 背后真正的 UX 问题（客观描述）
• 建议的修复方案（可操作）
• 标签/label：“ux-review”

对于黄色项目：一个汇总工单，包含所有备注。

白色项目仅出现在报告中。不创建工单。

每次会话最多 10 个工单 —— 专注于最严重的问题。

步骤 6：报告

交付：

1. 角色咆哮（步骤 3）—— 有趣且直击要害
2. 过滤后的评估（步骤 4）—— 实用且可操作
3. 创建的工单（步骤 5）—— 带链接
4. 关键问题的截图

提示

• 每次会话一个角色。 不要混合视角。
• 步骤 2-3 期间保持角色一致。 仅在步骤 4 跳出角色。
• 先测试核心工作流。 不要被设置页面分散注意力。
• 空状态是金矿。 新用户体验暴露最多摩擦。
• 最好的发现是红色项目，且是角色在尝试做其他事情时偶然发现的。
• 如果角色零投诉，说明你的角色太懂技术了。 让他们更老、更没耐心、更固执。
• 在演示、发布或发布一批功能之前运行此测试。
• 尽可能注册为新用户。 不要使用预置的管理员账户 —— 冷启动体验是大多数摩擦所在。
• 零白色项目是一个信号，不是失败。 如果实用主义过滤器没有发现噪音，说明你的产品有真正的 UX 问题，而不仅仅是一个暴躁的角色。
• 测试后检查项目文档中的已知问题。 如果角色发现了一个已在已知问题列表中的 Bug，这实际上是最严重的发现 —— 说明团队知道但从未感受到用户的痛苦。
• 订阅/付费墙测试至关重要。 用过期账户测试，不仅限于活跃账户。“付不起钱时会发生什么”的体验揭示了产品是尊重用户还是扣押他们的数据。
• 计算完成角色单一任务的点击次数。 如果超过 5 次，几乎总是红色发现，无论角色技术熟练程度如何。

按行业的示例角色

这些是起点 —— 根据您的具体产品定制：

产品类型	角色	年龄	关键特征
CRM	养老院院长	68	文件柜是当前的 CRM
摄影 SaaS	乡村婚礼摄影师	62	电话接单，纸质发票
AI/ML 工具	百货店采购员	55	被 3 家失败科技创业公司坑过
健身应用	老派健身教练	58	纸质笔记本，粗手指，视力差
会计	家庭面包店主	64	鞋盒收据，讨厌订阅
电商	市场摊位商贩	60	只收现金，手机只用来打电话
医疗	资深全科医生	63	口述笔记，护士操作电脑
教育	资深教师	57	粉笔授课，活页夹中的练习题

规则

• 步骤 2-3 期间保持角色一致
• 真正刻薄但公平 —— 找到真正的问题，而非编造的问题
• 实用主义过滤器（步骤 4）是强制性的
• 每个投诉需要截图
• 每次会话最多 10 个工单
• 在暂存/已部署的应用上测试，而非本地开发环境
• 一个角色，一次会话，一份报告