UX-аудит продукта по ссылке или репозиторию

Первый — браузерный агент по публичной ссылке. Playwright MCP и Chrome DevTools MCP видят страницу как дерево доступности, а не пиксели. Они умеют кликать, заполнять формы, читать консоль и сетевые запросы, менять вьюпорт и эмулировать медленную сеть. Визуальные проблемы (наложения, контраст, иерархию) они не видят, пока не попросишь скриншоты.

Второй — агент в твоём залогиненном браузере: Claude in Chrome или Claude Code с флагом --chrome. Этот способ нужен для приложений за логином; агент пишет GIF прохождения и останавливается на капче.

Третий — терминальный агент в репозитории. Он перечисляет маршруты и компоненты, ищет отсутствующие состояния, строки интерфейса, несогласованные компоненты, проверяет доступность в коде. Но «ревью только по коду недостаточно»: один из публичных скиллов требует скриншоты на 1280, 768 и 375 и иначе ставит на отчёт штамп «визуальные проблемы не оценены». Figma MCP полезен только для сверки реализации с макетом и токенами; поведение он не видит.

Агент может найти тупики и битые ссылки, ошибки в консоли и сети по маршрутам, сообщения при неверном вводе. Ещё — проблемы доступности с клавиатуры, поломки на заданных ширинах, пустые состояния, нарушения axe с уровнем влияния и ссылкой на WCAG.

Агент не может судить о намерении: анимацию печатной машинки один агент пометил как баг. Он не знает конвенций домена и приоритетов бизнеса. Он не замечает устаревший кеш страницы: один «критичный» дефект оказался невоспроизводимым именно из-за этого.

Структура из лучшего публичного скилла:

1. Обход карты сайта.
2. 3–5 пользовательских «нитей» в роли персоны.
3. Исчерпание элементов: списки на 0, 1, 100, 1000+ записей.
4. Адаптив на 1440 / 1280 / 1024 / 768 / 375 и тёмная тема.
5. Восемь сценариев.
6. Консоль и сеть.
7. Отчёт.
8. Цикл «исправить и проверить».

Восемь сценариев такие: первый контакт, прерванный процесс, возврат после неверного поворота, вернувшийся пользователь, только клавиатура, тяжёлые данные, уверенность при удалении, второй пользователь. Отчёт начинается с покрытия: сколько маршрутов найдено и сколько пройдено. Любое разрушительное действие — только после вопроса.

Baymard в 2023 году дал GPT-4 двенадцать экранов интернет-магазинов. Модель нашла 14% проблем, найденных экспертами, а 80% её замечаний были ложными. Заметная часть реальных проблем возникала при переходе между экранами и на скриншоте была невидима. Проверка 2025 года на GPT-4o дала похожую картину и ни одной проблемы по эвристике восстановления после ошибок.

Есть и обратный сбой. В другом исследовании модель покрыла большую долю сводного списка проблем, чем пять экспертов, но выдала десятки замечаний нулевой серьёзности и повторяла одно замечание на каждом экране. В аудите по коду согласованность между прогонами оказалась средней, и авторы подчёркивают, что согласованность не равна правильности.

Что работает: Baymard довёл согласие с аудиторами до 95%, когда модель только классифицирует паттерн интерфейса в 2–10 вариантов, а вывод делает человеческая эвристика. Для темы это значит, что агент предлагает кандидатов в находки, а серьёзность и решение оценивает дизайнер.

Шкала Нильсена 1994 года:

• 0 — не проблема;
• 1 — косметика;
• 2 — незначительная, низкий приоритет;
• 3 — серьёзная, высокий приоритет;
• 4 — катастрофа, исправить до релиза.

Серьёзность складывается из частоты, влияния и устойчивости.

Оценка одного оценщика «слишком ненадёжна», среднее по трём приемлемо. Оценивают независимо, после обхода, по сводному списку. Приоритизация по NN/g: ценность для пользователя × усилия, не больше двух критериев на одну матрицу.

Карточка находки: id · где (маршрут, файл:строка, скриншот) · что наблюдал (цитата или скриншот) · эвристика · серьёзность 0–4 с обоснованием · проверено или предположено · рекомендация · шаг проверки · влияние и усилия.

«Сплит» — вымышленное приложение из темы «Процесс с ИИ: Double Diamond и Design Sprint». Дизайнер прогнал два прохода на одном сценарии «создать группу → пригласить → добавить трату → рассчитаться». Это тот самый сценарий, где в теме «JTBD и journey map» нашёлся отвал 42%. Проходов два: третий промпт по репозиторию и первый промпт по ссылке на стейджинг. Агент вернул 14 находок. Четыре из них после разбора (пример условный):

Из 14 находок пять отклонены: три предположения без шага воспроизведения, одна дублировала другую на каждом экране, одна была про баннер стейджинга. Серьёзность дизайнер ставил сам, после обхода, по сводному списку. Квадрант «высокое влияние, малые усилия» дал три правки на эту неделю. Первая из них, похоже, и есть причина отвала на добавлении траты, но это уже гипотеза для темы «Проверка гипотез и тест прототипа с ИИ».

Три истории практиков показывают границы. Даниэла Наполи собрала скилл эвристической оценки для Claude и прогнала пять сайтов: меньше 10 минут на сайт вместо 20–30 часов. Скилл поймал остатки шаблона, провал контраста и адрес почты, спрятанный за иконкой без подписи. Но мелкие проблемы вёрстки шли как критичные, намеренные решения как баги, тон был резким. Её исправления: обязательная проверка свежести страницы, генерация кандидатов отдельно от оценки серьёзности, шаг воспроизведения к каждой находке.

Иштван Колоши отдал ревью портала Claude и ChatGPT параллельно с данными GA и Clarity. Часть находок была верна, часть несуществующей, несколько реальных пропущены. Экономия времени получилась небольшой, в основном на написании отчёта. Патрик Ниман добавляет: широкий аудит большого репозитория получается поверхностным, поэтому область нужно сужать, а аудиторию описывать заранее.

ИИ вредит в четырёх случаях. Находка без шага воспроизведения попадает в план. Серьёзность взята из отчёта агента, а не проставлена людьми. Намеренное решение чинят как баг. Агент в залогиненном браузере получает право удалять без вопроса.

Проведи аудит https://[адрес] как новый пользователь в роли [персона]. Вьюпорт 1440×900, потом ключевые страницы на 375 и в тёмной теме. 1. Обойди карту сайта и навигацию, перечисли все маршруты. 2. Пройди эти задачи от начала до конца: [задача 1], [задача 2], [задача 3]. Делай скриншот каждого изменения состояния. Попробуй неверный ввод, пустой ввод, кнопку "назад" посреди процесса и только клавиатуру. 3. На каждой странице читай консоль и сетевые запросы; 500+ — критичная, 403 и CORS — высокая, 404 — средняя. 4. Ничего не удаляй, не отправляй, не публикуй и не оплачивай — остановись и спроси. Запиши docs/ux-audit-[дата].md: покрытие (маршрутов пройдено / найдено, элементов проверено / найдено), находки по группам критичная / высокая / средняя / низкая, у каждой — путь к скриншоту, точный шаг воспроизведения, эвристика, исправление. В конце перечисли маршруты, которые не прошёл, и всё, что не смог проверить

Используй мою залогиненную сессию Chrome. Открой [адрес]. Запиши GIF прохождения [основная задача] от [точка входа] до [подтверждение]. Затем: если в аккаунте есть тестовые данные, которые можно удалить, удали их по одному с моего подтверждения и сними пустое состояние, иначе пропусти этот шаг и отметь, что пустое состояние не проверено; отправь форму с неверными данными и сними каждое сообщение об ошибке; сожми окно до 375 и повтори. Читай консоль на каждой странице. Отчёт: точки трения, которые ты испытал сам (каждое колебание или повтор — находка) с таймкодами в GIF, и список того, что проверить НЕ смог

Контекст: приложение для [аудитория]; основные сценарии [A], [B], [C]. Область аудита: [папка или маршрут]. 1. Перечисли каждый маршрут и компоненты, которые он рендерит. 2. Для каждого экрана с данными найди в коде состояния загрузки, пустое, ошибки, частичных данных и отсутствия прав. Нет состояния — находка. 3. Выпиши все строки интерфейса; пометь разные названия для одного действия, жаргон и сообщения об ошибках, которые не говорят, что делать. 4. Пометь несогласованные компоненты: две кнопки, модалки или поля, собранные по-разному для одной работы. 5. Доступность в коде: подписи привязаны к полям, стили фокуса, области нажатия 44px, состояние только цветом, prefers-reduced-motion. Выход: таблица находок с файл:строка, проблемой, почему это важно для [аудитория], серьёзностью 0–4, конкретным исправлением и шагом проверки, который человек выполнит в браузере. Сортируй по влиянию на пользователя, не по сложности правки. Код не меняй

Вот сводный список находок. Оцени каждую независимо от 0 до 4 по Нильсену, отдельно назвав частоту, влияние и устойчивость. Затем оцени усилия на исправление (S / M / L) по описанному решению. Построй матрицу 2×2 "влияние на пользователя × усилия", сначала перечисли квадрант "высокое влияние, малые усилия", и отдельно пометь находки серьёзности 4 с большими усилиями как решения для команды, а не для тебя

Проверь свой отчёт. Каждую находку пометь: проверена прямым наблюдением или выведена. Выведенные удали или понизь. Убедись, что у каждой есть шаг воспроизведения, который повторит третий человек. Перечисли страницы, загруженные из кеша или не загруженные заново. Перечисли, что осталось вне области. Любую находку, которая судит о намерении ("эта анимация сломана"), перепиши как вопрос владельцу