Перейти к содержанию

На этой странице

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

Метаданные навыка​
Source
Path
Version
Author
License
Tags
Related skills

Справочник: полный SKILL.md​

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

Адверсарное UX-тестирование

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

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

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

Большинство QA-тестов находит баги. Этот находит трение. Технически корректное приложение всё равно может быть непригодным для реальных людей. Адверсарный персонаж выявляет: * Запутанную терминологию, понятную разработчикам, но не пользователям * Слишком много шагов для выполнения простых задач * Отсутствие онбординга или «моментов озарения» * Проблемы доступности (размер шрифта, контраст, области кликов) * Проблемы холодного старта (пустые состояния, отсутствие демо-контента) * Трение при оплате/регистрации, убивающее конверсию

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

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

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

[code] "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"

[/code]

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

Шаг 1: Определение персонажа​

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

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

Хороший пример персонажа​

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

Плохой пример персонажа​

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

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

Шаг 2: Станьте тем ещё типом (Изучайте приложение как персонаж)​

  1. Прочитайте доступные документы проекта для понимания контекста приложения и URL
  2. Полностью вживитесь в образ персонажа — его разочарования, ограничения, цели
  3. Перейдите в приложение с помощью инструментов браузера
  4. Выполните РЕАЛЬНЫЕ ЗАДАЧИ персонажа (а не обзор функций):
    • Могут ли они сделать то, за чем пришли?
    • Сколько кликов/экранов нужно для выполнения задачи?
    • Что их сбивает с толку?
    • Что их злит?
    • Где они теряются?
    • Что заставит их сдаться и вернуться к старому способу?
  5. Протестируйте следующие категории трения:
    • Первое впечатление — стали бы они вообще заморачиваться дальше лендинга?
    • Основной рабочий процесс — ЕДИНСТВЕННОЕ, что им нужно делать чаще всего
    • Восстановление после ошибок — что происходит, когда они делают что-то не так?
    • Читаемость — размер текста, контраст, информационная плотность
    • Скорость — кажется ли это быстрее их текущего метода?
    • Терминология — есть ли жаргон, который они не поймут?
    • Навигация — могут ли они найти дорогу назад? Знают ли они, где находятся?
  6. Делайте скриншоты каждой болевой точки
  7. Проверяйте консоль браузера на наличие JS-ошибок на каждой странице

Шаг 3: Выплеск эмоций (Напишите отзыв в образе)​

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

[code] [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]"

[/code]

Шаг 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| Обжёгся на 3 провальных техстартапах
Фитнес-приложение| Старого зала тренер| 58| Бумажный блокнот, толстые пальцы, плохое зрение
Бухгалтерия| Владелец семейной пекарни| 64| Коробка с чеками, ненавидит подписки
E-commerce| Продавец с рыночного ларька| 60| Только наличные, смартфон только для звонков
Здравоохранение| Врач общей практики| 63| Диктует записи, медсестра работает с компьютером
Образование| Ветеран-учитель| 57| Мел и доска, раздаточные материалы в папках

Правила​