Adversarial Ux Test

Сыграй роль самого сложного, технофобного пользователя своего продукта. Пройди по приложению от его лица, найди все 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

Adversarial UX Test

Войди в роль худшего возможного пользователя своего продукта — человека, который ненавидит технологии, не хочет твой софт и найдёт любой повод поныть. Затем пропусти его обратную связь через фильтр прагматизма: отдели реальные UX-проблемы от мусора в духе «я вообще не люблю компьютеры».

Считай это автоматизированным «тестом мамы» — только злым.

Почему это работает

Обычное QA ищет баги. Этот подход ищет трение. Технически корректное приложение может быть совершенно непригодным для живых людей. Враждебная персона находит:

• Терминологию, понятную разработчикам, но не пользователям
• Слишком много шагов для простейших задач
• Отсутствие онбординга или «ага-моментов»
• Проблемы доступности (размер шрифта, контраст, зоны клика)
• Проблемы холодного старта (пустые состояния, нет демо-контента)
• Трение перед пейволлом или регистрацией, убивающее конверсию

Фильтр прагматизма (фаза 3) — это то, что делает навык полезным, а не просто развлекательным. Без него ты бы добавлял кнопку «распечатать эту страницу» на каждый экран, потому что дедушка не разбирается в 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: Определяем персону

Если персона не задана — сгенерируй её, ответив на вопросы:

1. Кто самый трудный пользователь для этого продукта? (50+, нетехническая роль, десятилетия опыта «по-старому»)
2. Какой у него уровень технической грамотности? (чем ниже, тем лучше — только WhatsApp, бумажные блокноты, почту настроила жена)
3. Одна задача, ради которой он пришёл? (его настоящая работа, а не твой список фич)
4. Что заставит его бросить? (слишком много кликов, жаргон, тормоза, непонятный интерфейс)
5. Как он говорит, когда раздражён? (грубо, матерно, пренебрежительно, со вздохами)

Пример хорошей персоны

«Большой Мик» Макаллистер — 58-летний тренер по силовой и кондиционной подготовке. Из всех технологий использует только WhatsApp. «Таблица» — бумажный блокнот. «Если не разберусь за 10 секунд — вернусь к блокноту». Ему нужно вносить результаты тренировок 25 спортсменов. Ненавидит мелкий шрифт, жаргон и пароли.

Пример плохой персоны

«Пользователь, которому не нравится приложение» — слишком расплывчато, никаких ограничений, никакого голоса.

Персона должна быть достаточно конкретной, чтобы оставаться в образе 20 минут тестирования.

Шаг 2: Войди в образ (ходи по приложению как персона)

1. Прочитай доступную проектную документацию — нужен контекст и URL-адреса приложения

2. Полностью вживись в персону — её раздражение, ограничения, цели

3. Открой приложение браузерными инструментами

4. Выполняй РЕАЛЬНЫЕ задачи персоны (не экскурсию по фичам):

   • Может ли она сделать то, зачем пришла?
   • Сколько кликов и экранов нужно для этого?
   • Что вызывает растерянность?
   • Что бесит?
   • Где она теряется?
   • Что заставит её вернуться к старому способу?

5. Проверь следующие категории трения:

   • Первое впечатление — вообще захочется листать дальше после лендинга?
   • Основной сценарий — то одно, что нужно делать чаще всего
   • Восстановление после ошибки — что происходит, когда что-то идёт не так?
   • Читаемость — размер шрифта, контраст, плотность информации
   • Скорость — ощущение, что это быстрее текущего способа?
   • Терминология — есть жаргон, который персона не поймёт?
   • Навигация — можно ли вернуться назад? понятно, где ты находишься?

6. Делай скриншоты каждой болевой точки

7. Проверяй консоль браузера на JS-ошибки на каждой странице

Шаг 3: Rant (пиши отзыв голосом персоны)

Пиши от лица персоны — её голосом, с её раздражением. Это не баг-репорт. Живой человек выпускает пар.

[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: Фильтр прагматизма (обязательно — не пропускай)

Выйди из образа. Оцени каждую жалобу как продуктовый человек:

• RED: НАСТОЯЩИЙ UX-БАГ — эта проблема есть у любого пользователя, не только у злобных. Чинить.
• YELLOW: РЕАЛЬНО, НО НЕ СРОЧНО — настоящая проблема, но только для крайних случаев. Зафиксировать.
• WHITE: ШУМ ПЕРСОНЫ — это говорит «я не люблю компьютеры», а не продуктовая проблема. Игнорировать.
• GREEN: ФИЧА-ЗАПРОС — хорошая идея, спрятанная в жалобе. Рассмотреть.

Критерии фильтра

1. Та же жалоба возникнет у компетентного, но занятого 35-летнего пользователя? → RED
2. Это реальная проблема доступности (шрифт, контраст, зоны клика)? → RED
3. Это «хочу, чтобы работало как бумага» — сопротивление цифровому? → WHITE
4. Персона наткнулась на реальную неэффективность рабочего процесса? → YELLOW или RED
5. Исправление усложнит жизнь 80%, у которых всё нормально? → WHITE
6. Жалоба указывает на пропущенный онбординг-момент? → GREEN

Этот фильтр ОБЯЗАТЕЛЕН. Никогда не отправляй сырые жалобы персоны в тикеты.

Шаг 5: Создаём тикеты

Только для RED и GREEN пунктов:

• Чёткий, конкретный заголовок
• Дословная цитата персоны (цепляет + запоминается)
• Реальная UX-проблема под ней (объективно)
• Предложенное решение (конкретное действие)
• Тег/метка: “ux-review”

Для YELLOW пунктов: один общий тикет со всеми заметками.

WHITE пункты попадают только в отчёт. Тикеты по ним не создаются.

Максимум 10 тикетов за сессию — фокус на самых серьёзных проблемах.

Шаг 6: Отчёт

Выдай:

1. Rant персоны (шаг 3) — живой и эмоциональный
2. Отфильтрованная оценка (шаг 4) — прагматичная и конкретная
3. Созданные тикеты (шаг 5) — со ссылками
4. Скриншоты ключевых проблем

Советы

• Одна персона — одна сессия. Не смешивай точки зрения.
• Оставайся в образе на шагах 2–3. Выходи из него только на шаге 4.
• Сначала тестируй ОСНОВНОЙ СЦЕНАРИЙ. Не отвлекайся на страницы настроек.
• Пустые состояния — золото. Опыт нового пользователя показывает больше всего трения.
• Лучшие находки — RED-пункты, которые персона обнаружила случайно, пытаясь сделать что-то другое.
• Если персона ни на что не жалуется — она слишком технически подкована. Сделай её старше, менее терпеливой, более консервативной.
• Запускай это перед демо, релизами или после выкатки пачки фич.
• По возможности регистрируйся как НОВЫЙ пользователь. Не используй заранее заполненные admin-аккаунты — больше всего трения живёт именно на холодном старте.
• Ноль WHITE-пунктов — это сигнал, не провал. Если фильтр прагматизма не нашёл шума, у продукта реальные UX-проблемы, а не просто злобная персона.
• Проверяй известные проблемы в документации ПОСЛЕ теста. Если персона нашла баг, который уже есть в списке known issues, — это самая показательная находка: команда знала, но так и не прочувствовала боль пользователя.
• Тестирование подписки и пейволла — критично. Тестируй с просроченными аккаунтами, не только с активными. Опыт «что происходит, когда не можешь платить» показывает, уважает ли продукт пользователей или держит их данные в заложниках.
• Считай клики до выполнения единственной задачи персоны. Больше 5 — почти всегда RED, независимо от уровня технической грамотности персоны.

Примеры персон по отраслям

Это отправные точки — адаптируй под конкретный продукт:

Тип продукта	Персона	Возраст	Ключевая черта
CRM	Директор дома престарелых	68	Картотека — текущая CRM
Photography SaaS	Свадебный фотограф из глубинки	62	Бронирует клиентов по телефону, счета на бумаге
AI/ML Tool	Байер торгового центра	55	Обожжён тремя провалившимися стартапами
Fitness App	Тренер old-school тренажёрного зала	58	Бумажный блокнот, толстые пальцы, плохое зрение
Accounting	Владелец семейной пекарни	64	Коробка с чеками, ненавидит подписки
E-commerce	Продавец на рынке	60	Только наличные, смартфон — для звонков
Healthcare	Старший врач общей практики	63	Диктует записи, компьютером занимается медсестра
Education	Ветеран-учитель	57	Доска и мел, распечатанные задания в папках

Правила

• Оставайся в образе на шагах 2–3
• Будь по-настоящему злобным, но честным — ищи реальные проблемы, не надуманные
• Фильтр прагматизма (шаг 4) — ОБЯЗАТЕЛЕН
• Скриншоты обязательны для каждой жалобы
• Максимум 10 тикетов за сессию
• Тестируй на staging или задеплоенном приложении, не на локальном dev
• Одна персона, одна сессия, один отчёт