Adversarial UX-тест

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

Метаданные навыка

Источник	Опционально — установка через vibeos 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

к сведению

Ниже приведено полное описание навыка, которое VibeOS загружает при его активации. Это те инструкции, которые видит агент, когда навык активен.

Adversarial UX-тест

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

Думайте об этом как об автоматизированном «тесте для мамы» — только злом.

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

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

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

Фильтр прагматизма (Фаза 3) — вот что делает этот подход полезным, а не просто развлекательным. Без него вы бы добавили кнопку «напечатать эту страницу» на каждый экран, потому что дедушка не умеет работать с PDF.

Как использовать

Скажите агенту:

«Проведи adversarial UX-тест на [URL]»
«Будь ворчливым [тип персоны] и протестируй [название приложения]»
«Сделай тест мудацкого пользователя на моём стейджинге»

Вы можете указать персону или позволить агенту сгенерировать её на основе целевой аудитории вашего продукта.

Шаг 1: Определите персону

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

1. Кто самый сложный пользователь для этого продукта? (возраст 50+, нетехническая роль, десятилетия опыта работы «по старинке»)
2. Каков их уровень комфорта с технологиями? (чем ниже, тем лучше — только WhatsApp, бумажные блокноты, почту настроила жена)
3. Какова ЕДИНСТВЕННАЯ задача, которую им нужно выполнить? (их основная работа, а не ваш список функций)
4. Что заставило бы их сдаться? (слишком много кликов, жаргон, медленно, запутанно)
5. Как они говорят, когда раздражены? (прямолинейно, с руганью, пренебрежительно, со вздохами)

Хороший пример персоны

«Большой Мик» МакАллистер — 58-летний тренер по силовой и кондиционной подготовке. Пользуется только WhatsApp. Его «электронная таблица» — это бумажный блокнот. «Если я не разберусь за 10 секунд, возвращаюсь к блокноту.» Нужно записывать результаты тренировок для 25 игроков. Ненавидит мелкий текст, жаргон и пароли.

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

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

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

Шаг 2: Станьте мудаком (просматривайте как персона)

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

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

3. Перейдите в приложение с помощью инструментов браузера

4. Попытайтесь выполнить РЕАЛЬНЫЕ ЗАДАЧИ персоны (а не обзор функций):

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

5. Протестируйте эти категории трения:

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

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

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

Шаг 3: Тирада (напишите отзыв в образе)

Напишите отзыв ОТ ЛИЦА ПЕРСОНЫ — их голосом, с их разочарованиями. Это не отчёт об ошибке. Это настоящий человеческий выплеск эмоций.

[ИМЯ ПЕРСОНЫ] о [ПРОДУКТЕ]

В целом: [Продолжили бы они им пользоваться? Да/Нет/Возможно, с условиями]

ХОРОШЕЕ (неохотное признание):
- [вещи, которые даже они вынуждены признать работающими]

ПЛОХОЕ (реальные UX-проблемы):
- [настоящие проблемы, которые помешали бы им использовать продукт]

УЖАСНОЕ (критические блокеры):
- [вещи, которые заставили бы их немедленно удалить/отменить подписку]

КОНКРЕТНЫЕ ЖАЛОБЫ:
1. [Страница/функция]: «[цитата голосом персоны]» — [что произошло, ожидалось]
2. ...

ВЕРДИКТ: «[однострочная цитата персоны, резюмирующая опыт]»

Шаг 4: Фильтр прагматизма (критически важно — не пропускайте)

Выйдите ИЗ ОБРАЗА персоны. Оцените каждую жалобу как продуктовый специалист:

• КРАСНЫЙ: НАСТОЯЩИЙ UX-БАГ — Любой пользователь столкнулся бы с этой проблемой, а не только ворчливые. Исправить.
• ЖЁЛТЫЙ: ВАЛИДНО, НО НИЗКИЙ ПРИОРИТЕТ — Реальная проблема, но только для экстремальных пользователей. Отметить.
• БЕЛЫЙ: ШУМ ПЕРСОНЫ — Говорит «я ненавижу компьютеры», а не проблема продукта. Пропустить.
• ЗЕЛЁНЫЙ: ЗАПРОС ФУНКЦИИ — Хорошая идея, скрытая в жалобе. Рассмотреть.

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

1. Столкнулся бы с этой жалобой 35-летний компетентный, но занятой пользователь? → КРАСНЫЙ
2. Это настоящая проблема доступности (размер шрифта, контрастность, цели кликов)? → КРАСНЫЙ
3. Это сопротивление цифровизации в духе «я хочу, чтобы работало как бумага»? → БЕЛЫЙ
4. Это реальная неэффективность рабочего процесса, на которую наткнулась персона? → ЖЁЛТЫЙ или КРАСНЫЙ
5. Добавит ли исправление сложности для 80%, у которых всё в порядке? → БЕЛЫЙ
6. Раскрывает ли жалоба отсутствующий момент онбординга? → ЗЕЛЁНЫЙ

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

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

Только для КРАСНЫХ и ЗЕЛЁНЫХ пунктов:

• Понятный, действенный заголовок
• Включите дословную цитату персоны (занимательно + запоминается)
• Реальная UX-проблема под ней (объективно)
• Предлагаемое исправление (действенное)
• Тег/метка: «ux-review»

Для ЖЁЛТЫХ пунктов: один общий тикет со всеми заметками.

БЕЛЫЕ пункты появляются только в отчёте. Без тикетов.

Максимум 10 тикетов за сессию — сосредоточьтесь на худших проблемах.

Шаг 6: Отчёт

Предоставьте:

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

Советы

• Одна персона за сессию. Не смешивайте точки зрения.
• Оставайтесь в образе на Шагах 2-3. Выходите из образа только на Шаге 4.
• Тестируйте ОСНОВНОЙ РАБОЧИЙ ПРОЦЕСС в первую очередь. Не отвлекайтесь на страницы настроек.
• Пустые состояния — золото. Опыт нового пользователя выявляет больше всего трения.
• Лучшие находки — КРАСНЫЕ пункты, которые персона обнаружила случайно при попытке сделать что-то другое.
• Если у персоны ноль жалоб, ваша персона слишком технически подкована. Сделайте её старше, менее терпеливой, более закостенелой.
• Запускайте это перед демо, запусками или после выкатки пакета функций.
• Регистрируйтесь как НОВЫЙ пользователь, когда это возможно. Не используйте предварительно созданные админские аккаунты — опыт холодного старта содержит больше всего трения.
• Ноль БЕЛЫХ пунктов — это сигнал, а не неудача. Если фильтр прагматизма не находит шума, у вашего продукта реальные UX-проблемы, а не просто ворчливая персона.
• Проверьте известные проблемы в документации проекта ПОСЛЕ теста. Если персона нашла баг, который уже есть в списке известных проблем, это на самом деле самый убийственный вывод — значит, команда знала о нём, но никогда не чувствовала боли пользователя.
• Тестирование подписки/платёжного барьера критически важно. Тестируйте с истёкшими аккаунтами, а не только с активными. Опыт «что происходит, когда вы не можете заплатить» показывает, уважает ли продукт пользователей или удерживает их данные в заложниках.
• Посчитайте клики для выполнения ЕДИНСТВЕННОЙ задачи персоны. Если их больше 5, это почти всегда КРАСНАЯ находка независимо от технического уровня персоны.

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

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

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

Правила

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