title: “Adversarial Ux Test — Roleplay a hostile user to find and triage UX pain points” sidebar_label: “Adversarial Ux Test” description: “Roleplay a hostile user to find and triage UX pain points”

{/* 本页面由 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错误。

第3步：真情实感反馈（以角色身份撰写评价）

请以该角色的口吻，带着他们的真实挫败感来撰写反馈。这并非故障报告，而是一个真实用户的情感宣泄。

[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个工单
• 测试应在正式上线或预发布版本的应用中进行，不得在本地开发环境测试
• 每个角色设定、每次会话只能生成一份报告