Adversarial Ux Test
扮演最挑剔、最抗拒技术的用户来测试你的产品。以该用户角色的身份浏览应用,找出每一个用户体验痛点,然后通过一层实用主义过滤器筛选投诉,区分出真正的问题和噪音。只针对真实问题生成可操作的任务工单。
技能元信息
| 来源 | 可选 — 使用 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
以下内容是 Hermes 在触发该技能时加载的完整技能定义。这是 Agent 在技能激活时看到的指令。
Adversarial UX Test
扮演你的产品最糟糕的用户 —— 那种讨厌科技、不想要你的软件、并且会找出所有理由来抱怨的人。然后通过一层实用主义过滤器来筛选他们的反馈,将真正的 UX 问题与“我讨厌电脑”的噪音区分开。
可以把它看作是一个自动化的“老妈测试”——只不过脾气更暴躁。
为什么这招有效
大多数质量保障能找到 Bug。但这招能找到摩擦。一个在技术上正确的应用,对真实用户来说可能仍然难以使用。这种对抗性角色能捕捉到:
- 对开发者有意义但对用户来说令人困惑的术语
- 完成基本任务步骤过多
- 缺少新手引导或“顿悟时刻”
- 无障碍问题(字体大小、对比度、点击目标)
- 冷启动问题(空状态、无演示内容)
- 导致转化失败的付费墙/注册摩擦
实用主义过滤器(第三阶段)才是让它变得有用而非仅仅有趣的关键。没有它,你就会在每个屏幕上添加一个“打印此页”按钮,因为老爷爷搞不懂 PDF。
如何使用
告诉 Agent:
“对 [URL] 运行一次对抗性 UX 测试”
“扮演一个脾气暴躁的 [角色类型] 来测试 [应用名称]”
“在我的预发布站点上做一个混蛋用户测试”
你可以提供一个角色,或者让 Agent 根据你产品的目标受众自动生成一个。
第一步:定义角色
如果没有提供角色,通过回答以下问题来生成一个:
- 这个产品最难搞的用户是谁?(50岁以上、非技术岗位、几十年都在按“老办法”做事)
- 他们的技术水平如何?(越低越好——只会用 WhatsApp、纸质笔记本、老婆给设的邮箱)
- 他们需要完成的唯一一件事是什么?(他们的核心工作,而不是你的功能列表)
- 什么会让他们放弃?(点击太多、术语太多、太慢、太困惑)
- 他们感到沮丧时怎么说话?(直白、骂人、不屑、叹气)
好的角色示例
“大麦克”麦卡利斯特 —— 58岁的体能教练。只会用 WhatsApp,没了。他的“电子表格”就是一本纸笔记本。“如果10秒内搞不定,我就回去用我的笔记本。”需要为25名球员记录训练结果。讨厌小字体、术语和密码。
--- 结束文档片段 ---
糟糕的角色示例
"一个不喜欢该应用的用户" —— 太模糊,没有约束,没有语气。
角色必须足够具体,以便在20分钟的测试中保持角色一致。
第二步:变成混蛋(以角色身份浏览)
-
阅读所有可用的项目文档,了解应用上下文和URL
-
完全代入角色 —— 他们的挫折、限制、目标
-
使用浏览器工具导航到应用
-
尝试角色的实际任务(不是功能导览):
- 他们能完成想做的事吗?
- 需要多少次点击/多少个屏幕才能完成?
- 什么让他们困惑?
- 什么让他们生气?
- 他们在哪里迷失?
- 什么会让他们放弃并回到旧方法?
-
测试以下摩擦类别:
- 第一印象 —— 他们甚至会费心浏览着陆页吗?
- 核心工作流 —— 他们最常做的一件事
- 错误恢复 —— 当他们做错事时会发生什么?
- 可读性 —— 文本大小、对比度、信息密度
- 速度 —— 感觉比他们当前的方法快吗?
- 术语 —— 有没有他们不理解的 jargon?
- 导航 —— 他们能原路返回吗?他们知道自己在哪吗?
-
截取每个痛点的屏幕截图
-
检查每个页面浏览器控制台的JS错误
第三步:发泄(以角色身份写反馈)
以角色的身份写反馈 —— 用他们的语气,带着他们的挫折感。这不是一份 bug 报告。这是一个真实的人在吐槽。
[角色名称] 对 [产品] 的评价
总体评价:[他们会继续使用吗?是/否/有条件的可能]
好的方面(勉强承认):
- [连他们都不得不承认好用的地方]
坏的方面(合理的UX问题):
- [真正会阻止他们使用产品的问题]
丑陋的方面(致命障碍):
- [会让他们立即卸载/取消的东西]
具体投诉:
1. [页面/功能]:"[角色原话]" —— [发生了什么,期望什么]
2. ...
最终结论:"[一句话的角色原话,总结他们的体验]"
第四步:实用主义过滤(关键 —— 不可跳过)
跳出角色。以产品人员的身份评估每条投诉:
- 红色:真正的UX BUG —— 任何用户都会遇到这个问题,不只是脾气暴躁的用户。修复它。
- 黄色:有效但优先级低 —— 真实问题但只对极端用户有意义。记录它。
- 白色:角色噪音 —— "我讨厌电脑"在说话,不是产品问题。跳过它。
- 绿色:功能请求 —— 投诉中隐藏的好点子。考虑它。
过滤标准
- 一个35岁能干但忙碌的用户会有同样的投诉吗?→ 红色
- 这是真正的可访问性问题(字体大小、对比度、点击目标)吗?→ 红色
- 这是"我想让它像纸一样工作"对数字化的抵触吗?→ 白色
- 这是角色偶然发现的真正工作流低效吗?→ 黄色或红色
- 修复这个问题会给80%没问题的用户增加复杂性吗?→ 白色
- 投诉是否揭示了一个缺失的入门引导时刻?→ 绿色
此过滤是强制性的。 绝不要将原始的角色投诉直接作为工单提交。
第 5 步:创建工单
仅针对 RED 和 GREEN 项目:
- 清晰、可操作的标题
- 包含人设的原话引用(有趣且令人印象深刻)
- 底层的真实用户体验问题(客观描述)
- 建议的修复方案(可操作)
- 标签/标记:"ux-review"
对于 YELLOW 项目:创建一个汇总工单,包含所有备注。
WHITE 项目只出现在报告中,不创建工单。
每次会话最多 10 个工单——聚焦在最严重的问题上。
第 6 步:报告
交付内容:
- 人设的吐槽(第 3 步)——生动且直击痛点
- 过滤后的评估(第 4 步)——务实且可操作
- 创建的工单(第 5 步)——附带链接
- 关键问题的截图
提示
- 每次会话只使用一个人设。 不要混合不同视角。
- 在第 2–3 步期间保持角色。 只在第 4 步跳出角色。
- 先测试核心工作流。 不要在设置页面分心。
- 空白状态是金矿。 新用户体验最能暴露摩擦点。
- 最佳发现是用户在做其他事情时偶然发现的 RED 项目。
- 如果人设没有任何抱怨,那你的人设太懂技术了。 把年纪设大一些,耐心少一些,更固执一些。
- 在演示、发布或批量功能上线前运行此测试。
- 尽可能注册为新用户。 不要使用预置的管理员账户——冷启动体验是摩擦最多的地方。
- 零 WHITE 项目不是失败,而是一个信号。 如果务实过滤器找不到噪音,说明你的产品确实有用户体验问题,而不仅仅是人设在抱怨。
- 测试后再检查项目文档中的已知问题。 如果人设发现了一个已在已知问题列表中的 bug,那实际上是最致命的发现——说明团队明知问题存在,却从未感受过用户的痛苦。
- 订阅/付费墙测试至关重要。 用过期账户测试,而不仅仅是活跃账户。“当你付不了费时会发生什么”这个体验,能揭示产品是尊重用户,还是在挟持用户数据。
- 计算完成人设的单一任务所需的点击次数。 如果超过 5 次,那几乎总是 RED 发现,无论人设的技术水平如何。
按行业分列的示例人设
以下为起点——请根据你的具体产品进行定制:
| 产品类型 | 人设 | 年龄 | 关键特征 |
|---|---|---|---|
| CRM | 养老院院长 | 68 | 目前用的是文件柜作为 CRM |
| 摄影 SaaS | 乡村婚礼摄影师 | 62 | 用电话接客户,纸质发票 |
| AI/ML 工具 | 百货商店采购员 | 55 | 被 3 家失败的科技初创公司伤过 |
| 健身应用 | 传统健身房教练 | 58 | 纸质笔记本,手指粗,眼神差 |
| 会计 | 家庭面包店老板 | 64 | 鞋盒装收据,讨厌订阅制 |
| 电商 | 菜市场摊主 | 60 | 只收现金,手机只用来打电话 |
| 医疗健康 | 资深全科医生 | 63 | 口述病历,护士操作电脑 |
| 教育 | 资深教师 | 57 | 粉笔加讲课,练习本装订在文件夹里 |
规则
- 在第 2-3 步期间保持角色设定
- 要真正刻薄但公平——找出真实问题,而不是捏造的问题
- 实用主义过滤器(第 4 步)是强制性的
- 每个投诉都需要截图
- 每轮会话最多 10 个工单
- 在预发布/已部署的应用上测试,而不是本地开发环境
- 一个人设、一轮会话、一份报告