title: “Adversarial Ux Test — Roleplay the most difficult, tech-resistant user for your product” sidebar_label: “Adversarial Ux Test” description: “Roleplay the most difficult, tech-resistant user for your product”

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

对抗性用户体验测试

让智能体扮演对你产品最为挑剔、最抗拒技术的用户。以该角色浏览应用，找出所有用户体验痛点，再通过务实性筛选机制区分真正的问题与无意义的抱怨，仅从真实问题中生成可操作的工单。

技能元数据

参考：完整 SKILL.md 内容

:::info 以下是当触发该技能时 Hermes 会加载的完整技能定义。当技能处于激活状态时，智能体将看到这些指令作为操作指南。

::

对抗性用户体验测试

让智能体扮演对你产品最糟糕的用户——那些厌恶技术、不愿使用你的软件，并且会找尽理由抱怨的人。接着通过务实性筛选机制过滤他们的反馈，区分真正的用户体验问题与“我讨厌电脑”这类无意义的抱怨。

可以将其视为自动化的“妈妈测试”——只不过更暴躁一些。

为何此方法有效

大多数质量检测只能发现漏洞，而该方法能找出使用障碍。即便一个在技术层面完全正确的应用，对普通用户来说仍可能难以使用。对抗性角色能够识别出：

• 对开发者有意义但对用户而言晦涩的术语
• 完成基本任务所需的步骤过多
• 缺乏引导流程或“顿悟时刻”
• 可访问性问题（字体大小、对比度、点击区域）
• 启动阶段的问题（空白界面、无演示内容）
• 会阻碍转化率的付费墙或注册流程障碍

务实性筛选机制（第三阶段）正是让此方法具备实际价值而非仅用于娱乐的关键。如果没有这一机制，你可能不得不在每个页面都添加“打印此页”按钮，只因为老爷爷看不懂 PDF 文件。

使用方法

告诉智能体：

"Run an adversarial UX test on [URL]"
"Be a grumpy [persona type] and test [app name]"
"Do an asshole user test on my staging site"

你可以自行设定角色画像，或者让智能体根据产品目标用户群体自动生成一个。

第一步：定义角色画像

如果未提供角色画像，可通过回答以下问题来生成：

1. 对于该产品而言，最难使用的用户是谁？（50岁以上、非技术背景、长期习惯用传统方式操作）
2. 他们的技术使用熟练度如何？（越低越好——仅会使用WhatsApp、依赖纸质笔记本、甚至由妻子帮忙设置邮箱）
3. 他们最需要完成的是哪一件事？（其核心工作任务，而非产品功能列表）
4. 什么会让他们放弃使用？（操作步骤过多、术语复杂、速度过慢、界面混乱）
5. 遇到挫折时他们会如何表达？（直率、粗俗、满不在乎或频繁叹气）

优质角色画像示例

“大米克”·麦卡利斯特——58岁的体育教练。仅使用WhatsApp，他的“电子表格”就是纸质笔记本。他常说：“如果10秒内搞不定，我就回去用笔记本。”他需要为25名运动员记录训练数据，极其厌恶小字体、专业术语和密码。

反面角色画像示例

“一个不喜欢这款应用的用户”——描述过于模糊，没有具体限制条件，也缺乏真实特征。

角色画像必须足够具体，才能在20分钟的测试过程中始终保持该角色的行为特征。

第二步：代入角色进行体验

1. 阅读所有可获取的项目文档，了解应用背景及相关网址

2. 完全融入角色视角——理解其挫败感、局限及目标

3. 使用浏览器工具访问该应用

4. 尝试完成角色实际需要执行的任务（而非功能浏览）：

   • 他们能否实现既定目标？
   • 完成任务需要点击多少次、切换多少页面？
   • 有哪些地方让他们感到困惑？
   • 什么会让他们生气？
   • 哪些环节会让他们迷失方向？
   • 什么会让他们放弃，转而继续使用旧方法？

5. 测试以下各类使用障碍：

   • 第一印象——他们是否会愿意继续浏览，而不会直接离开首页？
   • 核心工作流程——他们最常需要执行的那项任务
   • 错误处理机制——当他们操作出错时会发生什么？
   • 可读性——字体大小、对比度及信息密度
   • 速度——是否比他们现有的使用方式更快？
   • 术语使用——是否存在他们无法理解的专业术语？
   • 导航设计——他们能否找到返回路径？是否清楚当前所在位置？

6. 为每一个痛点截图留存证据

7. 检查每个页面的浏览器控制台，查看是否有JavaScript错误

第三步：以角色身份撰写反馈

需以该角色的口吻、带着其真实的挫败感来撰写反馈。这不是漏洞报告，而是真实用户的情感宣泄。

[PERSONA NAME]'s Review of [PRODUCT]

Overall: [Would they keep using it? Yes/No/Maybe with conditions]

THE GOOD (grudging admission):
- [things even they have to admit work]

THE BAD (legitimate UX issues):
- [real problems that would stop them from using the product]

THE UGLY (showstoppers):
- [things that would make them uninstall/cancel immediately]

SPECIFIC COMPLAINTS:
1. [Page/feature]: "[quote in persona voice]" — [what happened, expected]
2. ...

VERDICT: "[one-line persona quote summarizing their experience]"

第4步：务实过滤机制（至关重要——切勿跳过）

暂时脱离角色设定，以产品视角来评估每一条反馈：

• 红色：真正的用户体验缺陷——任何用户都可能遇到此问题，而不仅仅是那些爱抱怨的用户。必须修复。
• 黄色：合理但优先级较低——确实存在问题，但仅限于极少数特殊用户。只需记录在案。
• 白色：角色扮演产生的无意义内容——类似“我讨厌电脑”之类的言论，并非产品问题。可直接忽略。
• 绿色：功能需求建议——反馈中隐藏着不错的创意。值得考虑纳入产品。

过滤标准

1. 一名35岁、能力较强但时间紧张的用户是否也会遇到同样的问题？→ 若是，则为红色。
2. 这是否属于真正的无障碍性问题（如字体大小、对比度、点击区域等）？→ 若是，则为红色。
3. 这是否属于“我希望它像纸质产品那样使用”的数字化抗拒心理？→ 则为白色。
4. 这是否是该角色在日常工作中实际遇到的效率低问题？→ 若是，则为黄色或红色。
5. 修复此问题是否会增加80%使用正常用户的操作复杂度？→ 若会，则为白色。
6. 该反馈是否揭示了产品中缺失的引导环节？→ 若是，则为绿色。

此过滤机制为强制性要求。 绝不可直接将角色扮演产生的原始反馈作为工单提交。

第5步：创建工单

仅针对红色和绿色类别的反馈处理：

• 填写清晰、具有可操作性的标题；
• 精确引用角色的原话（既有趣又易记）；
• 指出其背后的真实用户体验问题（需基于事实）；
• 提出可行的解决方案；
• 添加标签/标记：“ux-review”。

对于黄色类别的反馈：只需创建一个汇总工单，将所有记录放入其中。

白色类别的反馈仅出现在报告中，无需创建工单。

每次测试最多创建10个工单——重点处理最严重的问题。

第6步：生成报告

报告内容应包括：

1. 角色的吐槽内容（第3步）——需生动且有代入感；
2. 经过滤波后的评估结果（第4步）——需务实且具备可操作性；
3. 已创建的工单列表（第5步）——附上对应链接；
4. 关键问题的截图。

实用建议

• 每次测试仅使用一个角色设定，避免混淆不同视角。
• 在步骤2-3期间需始终保持角色身份，仅在步骤4时可暂时脱离角色。
• 优先测试核心工作流程，不要被各种设置页面分散注意力。
• 空状态是揭示问题的最佳线索——新用户的体验最能体现使用中的摩擦点。
• 最理想的发现是角色在尝试完成其他任务时无意中发现的红色问题。
• 如果角色没有任何反馈，说明该角色过于精通技术。可将其设定为年龄更大、耐心更差、固执己见的人。
• 应在产品演示、正式发布前或批量功能上线后执行此测试。
• 尽可能以新用户身份进行测试，避免使用预置的管理员账户——冷启动体验往往存在最多的问题。
• 完全没有白色类别的反馈并非失败信号。如果务实过滤机制未发现任何无意义内容，说明产品确实存在真实的用户体验问题，而非只是角色过于爱抱怨。
• 测试完成后，请查阅项目文档中的已知问题列表。如果角色发现的缺陷已在列表中，那反而是最严重的发现——说明团队早已知晓该问题，却从未真正体会过用户的困扰。
• 订阅功能/付费墙测试至关重要。除了使用正常账户外，还需测试过期账户。测试“无法支付时会发生什么”这一场景，能够判断产品是真正尊重用户，还是在利用用户数据要挟他们。
• 统计角色完成某项任务所需的点击次数。如果点击次数超过5次，那么无论角色的技术水平如何，几乎可以判定为红色问题。

各行业典型角色示例

这些仅为参考，需根据您的具体产品进行定制：

规则说明

• 在步骤2-3期间需始终保持角色身份；
• 评价需真实且公正——找出实际存在的问题，而非刻意编造的；
• 实用过滤机制（第4步）为强制性要求；
• 每条反馈都必须附上截图；
• 每次测试最多创建10个工单；
• 测试应在正式环境或已部署的应用上进行，而非本地开发环境；
• 每个角色设定对应一次测试，生成一份报告。