Как провести анализ ошибок в UX-исследованиях: практический гайд с AI-промптами

Что такое анализ ошибок?

Анализ ошибок (Error Analysis) — это сфокусированный метод инспекции, который берёт моменты, когда пользователи делают что-то не так — неверные клики, провалившиеся отправки форм, брошенные сценарии, обращения в поддержку, rage clicks, — и превращает их в структурированный приоритизированный бэклог юзабилити-проблем. Вместо широкого вопроса «удалось ли пользователям» анализ ошибок задаёт другой: «где именно пользователи провалились, почему они провалились и какие провалы дороже всего обходятся бизнесу». Один проход анализа ошибок на сфокусированном сценарии занимает от одного до трёх дней, даёт категоризированный список всех уникальных режимов отказа с частотой и серьёзностью и говорит команде, что чинить в первую очередь, когда ресурсов разработки не хватает.

На какой вопрос отвечает метод?

Где в этом сценарии пользователи совершают ошибки и насколько часто случается каждая из них?
Чем вызваны наблюдаемые провалы — дизайном, ментальной моделью пользователя, контентом или системным багом?
Какие провалы полностью блокируют выполнение задачи, а какие — просто фрикции, из которых пользователь может выйти?
Какие два-три режима отказа дают большинство тикетов в поддержку и сколько будет стоить их починка?
После выхода редизайна — действительно ли частота отказов на основной задаче снизилась и появились ли новые режимы отказа?
Какие ошибки сконцентрированы на конкретных сегментах пользователей, устройствах или браузерах, а какие бьют по всем одинаково?

Когда использовать анализ ошибок

После модерируемого или немодерируемого юзабилити-теста, когда есть видео, заметки или самоотчёты, которые нужно закодировать в структурированный список провалов до того, как приоритизировать починки.
Когда тикеты в поддержку, фидбек в продукте или логи rage clicks указывают на паттерн провалов в конкретном сценарии, но никто ещё не количественно оценил, какие провалы важнее всего.
После запуска или редизайна, когда команде нужно понять, снизил ли новый билд частоту отказов или просто сместил их, прежде чем коммитить ресурсы на следующий раунд работы.
Когда аналитика показывает резкое падение на конкретном шаге, но цифры сами по себе не объясняют, почему пользователи уходят — анализ ошибок превращает «что» в «почему».
Когда LLM-фича в продакшене и команде нужно понять её специфические режимы отказа (галлюцинации, ошибки retrieval, ответы не по теме), прежде чем определять метрики оценки.
Когда руководство спрашивает «продукт становится лучше или нет», а команде нужно защитимое повторяемое измерение, которое можно отслеживать между релизами.

Не подходит, когда данных ещё нет — анализ ошибок зависит от наблюдаемых провалов в реальных сессиях, логах или каналах поддержки и не умеет генерировать инсайты с чистого листа. Он также неуместен для ранних discovery-вопросов о мотивации или неудовлетворённых потребностях пользователя; для них нужны интервью или дневниковые исследования. Анализ ошибок говорит, где сейчас ломается продукт, а не что строить дальше. Наконец, он не заменяет юзабилити-тест на свежем продукте — без базовых задач и наблюдения нет потока ошибок, который можно было бы анализировать.

Что вы получаете на выходе

Таксономия режимов отказа: небольшой набор названных взаимоисключающих категорий (типично шесть-десять), в которые можно положить любую наблюдаемую ошибку, с однострочным определением для каждой.
Закодированный лог ошибок: строка на каждый наблюдаемый провал, с тегами категории, серьёзности, экраном или шагом, где он произошёл, сегментом пользователя и дословной цитатой или скриншотом, если они есть.
Таблица частот: насколько часто появляется каждый режим отказа, в разбивке по задаче и сегменту, чтобы команда видела, какие провалы массовые, а какие — крайние случаи.
Матрица серьёзности: каждый уникальный провал оценён по импакту (блокирует ли задачу, можно ли выйти, косметика ли это), чтобы команда могла приоритизировать против ресурсов разработки.
Заметки по корневым причинам: для каждого высокоприоритетного режима отказа короткий абзац, объясняющий наиболее вероятную причину — дизайн, контент, ментальная модель, технический баг — на основе доказательств.
Рекомендации по фиксам: конкретные предложения по изменениям, привязанные к каждому высокоприоритетному режиму отказа, с грубой оценкой трудозатрат, чтобы команда могла спланировать следующий спринт.
Readout brief: документ на пять-десять страниц или короткая презентация с заголовочными провалами, категоризированным бэклогом, планом действий и описанием метода, чтобы будущие анализы можно было сравнить с этой базой.

Участники и данные

Участники: напрямую никого не рекрутируют. Анализ ошибок — это вторичный анализ данных, уже собранных другим методом: сессии юзабилити-теста, записи экрана, тикеты поддержки, логи ошибок, виджеты фидбека или самоотчётные пункты опросов.
Объём данных: для данных модерируемого юзабилити-теста сфокусированный сценарий с пятью-двенадцатью участниками даёт достаточно ошибок для содержательного прохода. Для данных из логов или тикетов практический минимум — пятьдесят-двести наблюдений на сценарий; чем больше, тем лучше для редких режимов отказа.
Подготовка: 0,5–1 день, чтобы определить scope, собрать исходные данные и выбрать инструмент кодирования.
Открытое кодирование: 0,5–1 день, чтобы прочитать каждое наблюдение, написать свободный текст-метку для каждого провала и удержаться от соблазна загнать метки в категории слишком рано.
Построение таксономии: полдня на кластеризацию свободных меток в небольшой набор названных категорий и однострочные определения.
Структурное кодирование: 0,5–1 день, чтобы перечитать каждое наблюдение и присвоить финальный тег таксономии, серьёзность и сегмент.
Синтез и написание: 0,5–1 день на построение таблицы частот, оценку серьёзности, заметки по корневым причинам и сам брифинг.
Полное календарное время: 2–4 дня от старта до конца на сфокусированный сценарий с пятьюдесятью-несколькими сотнями наблюдений.

Как провести анализ ошибок (по шагам)

1. Определите scope и источник данных

Прежде чем трогать данные, зафиксируйте на бумаге, какой именно сценарий, какую задачу, какое временное окно и какой сегмент пользователей вы анализируете. Scope вида «провалы оформления заказа на мобильном вебе у новых пользователей за последние 30 дней» даёт actionable-выводы; scope вида «ошибки в продукте» даёт расплывчатый отчёт, по которому никто не может действовать. Затем выберите источник данных под этот scope: видео и заметки модерируемого юзабилити-теста, записи экрана из немодерируемого исследования, тикеты поддержки, логи ошибок фронтенда, виджеты фидбека в продукте — или комбинацию. Разные источники ловят разные провалы, поэтому явно проговорите, какие из них вы используете, а какие нет.

2. Соберите репрезентативную выборку

Возьмите выборку наблюдений, достаточную, чтобы поверх неё всплыли частые режимы отказа и пара редких. Для модерируемых данных это всё, что вы собрали — пять-двенадцать сессий. Для логов или тикетов цельтесь в пятьдесят-двести наблюдений на анализируемый сценарий; для высокотрафиковых продуктов лучше делать стратифицированную выборку по сегментам, чем случайную, чтобы малые группы были представлены. При сэмплировании намеренно включайте и сессии, где пользователи справились, — контраст и есть то, что делает паттерны провалов видимыми. Сохраните выборку в одном месте (папка, очередь аннотации, таблица), чтобы все проходы кодирования работали с одним и тем же набором.

3. Открытое кодирование: пишите то, что видите, а не то, что думаете

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

4. Кластеризуйте метки в таксономию

Когда у вас есть свободные текст-метки на каждое наблюдение, разложите их и сгруппируйте похожие. Цель — небольшой набор (шесть-десять категорий — оптимум) взаимоисключающих режимов отказа с однострочным определением для каждого. Типичные категории включают slips (пользователь хотел сделать правильное действие, но промахнулся), mistakes (пользователь следовал неверной ментальной модели), confusions (неоднозначность интерфейса привела к паузе или возврату), системные ошибки (сам продукт сломался), контентные провалы (терминология или копирайт оказались непонятными) и abandonments (пользователь сдался без явной ошибки). Для LLM-продуктов таксономия выглядит иначе — галлюцинации, провалы retrieval, ответы не по теме, проблемы с форматированием, отсутствие follow-up. Не выдумывайте категории, которые данные не подтверждают; если вы видели только один пример «валидации формы», он живёт под «системные ошибки», а не отдельной строкой.

5. Структурное кодирование: переразметьте всё против таксономии

Теперь вернитесь к каждому наблюдению и присвойте канонический тег таксономии, серьёзность и сегмент. Это проход, который превращает сырые заметки в количественно измеримый датасет. Для каждого наблюдения зафиксируйте пять полей: где (экран или шаг), что (наблюдаемое поведение), категория (из таксономии), серьёзность (cosmetic / minor / major / critical или шкала 0–4) и сегмент (тип пользователя, устройство, браузер, время суток). Если найдутся наблюдения, которые не лезут ни в одну категорию, есть два варианта: расширить таксономию, если несовпадение — реальный паттерн, или добавить корзину «other» и пересмотреть в конце. Удержитесь от расширения таксономии за пределы десяти категорий — всё, что больше, становится слишком гранулярным, чтобы быть полезным.

6. Постройте таблицу частот и матрицу серьёзности

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

7. Диагностируйте корневые причины топовых провалов

Для топ-3–7 режимов отказа напишите короткий абзац, объясняющий, почему этот провал происходит. Различайте четыре причины: проблема дизайна (вёрстка, лейблинг или affordance ввели пользователя в заблуждение), несоответствие ментальной модели (пользователь ожидал другую модель, чем предлагает продукт), контентный провал (формулировка или терминология были непонятны) или технический баг (сам продукт сломался). У каждой из них свой фикс и своя команда-владелец, поэтому диагноз важен для действий. Используйте прямые доказательства — цитируйте дословное наблюдение, ссылайтесь на скриншот или запись сессии, а не на интерпретацию, чтобы дизайн- и инженерные лиды могли проверить вывод сами.

8. Приоритизируйте и предложите фиксы

Оцените каждый высокоприоритетный провал по трём измерениям: серьёзность (насколько сильно бьёт по пользователю, когда происходит), частота (как часто реальный пользователь в него попадает) и бизнес-импакт (влияние на активацию, retention, конверсию, support cost). Сложите три оценки, чтобы получить ранг приоритета, и выберите топ-5–10 провалов, которые пойдут в следующий спринт. Для каждого набросайте конкретный рекомендованный фикс и грубую оценку трудозатрат (small, medium, large). Завершите небольшим набором провалов, которые надо отслеживать, но отложить — обычно это малосерьёзные проблемы, которые дешевле починить как побочный эффект более крупного изменения.

9. Напишите бриф и презентуйте стейкхолдерам

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

Как AI меняет анализ ошибок

AI compatibility: partial — Большая часть анализа ошибок — это механический паттерн-матчинг по шумным текстовым данным, и современные LLM делают именно эту работу очень хорошо. Загвоздка в том, что самые ценные суждения — определение правильного scope, отличие реального режима отказа от единичного случая, калибровка серьёзности по бизнес-импакту и объяснение корневой причины каждого топового провала — всё ещё требуют человека, который знает продукт. AI сжимает проходы открытого кодирования и кластеризации с дней до часов, что освобождает исследователю время на диагностику и приоритизацию.

Что AI умеет

Кластеризовать свободные наблюдения в таксономию: на нескольких сотнях сырых заметок об ошибках из немодерируемого теста или экспорта тикетов поддержки LLM может сгруппировать похожие наблюдения, предложить шесть-десять связных категорий провалов и написать однострочные определения за несколько минут — ту же работу, на которую у исследователя уходит полдня сортировки карточек.
Прогнать структурное кодирование на масштабе: когда таксономия уже есть, LLM может переразметить каждое наблюдение против неё с высокой консистентностью и пометить пограничные случаи на ручную проверку. Это шаг, который исторически плохо масштабировался по объёму выборки; AI убирает это узкое горлышко и позволяет анализу покрывать сотни и тысячи наблюдений вместо десятков.
Выставить серьёзность по фиксированной рубрике: модель, применяющая однокабзацную рубрику серьёзности к каждому провалу, выдаёт консистентные оценки, которые исследователь может проверить выборочно, а не выставлять с нуля. Дрейф калибровки между ручными кодировщиками — хроническая проблема этого метода; AI решает её для рутинных случаев.
Майнить тикеты поддержки и транскрипты записей сессий на паттерны провалов: инструменты вроде Dovetail, Marvin, Notably и фичи Gong для исследований умеют переваривать большие объёмы неструктурированного фидбека, поднимать повторяющиеся темы и привязывать каждую к дословным цитатам — превращая стог сена жалоб в структурированный список провалов.
Анализировать режимы отказа LLM-приложений: для продуктов со встроенными LLM-фичами платформы оценки (Langfuse, Humanloop, Braintrust, Promptfoo) автоматизируют workflow открытого кодирования по продакшн-трейсам, кластеризуют провалы в названные режимы и позволяют команде отслеживать частоту провалов между моделями и промптами.
Сделать черновик readout-брифа: на закодированном логе и таблице частот LLM может выдать первый драфт брифа, организованный по режимам отказа, с заголовочными выводами, таблицами частот и рекомендованными фиксами. Исследователь потом переписывает его под тон, заостряет приоритизацию и убирает неизбежную ложную уверенность.

Что требует человека-исследователя

Определение scope и выбор источника данных: AI с радостью кластеризует всё, что вы ему дадите, но решение, какой сценарий важен, какое временное окно тянуть и какие источники комбинировать, — это продуктовое суждение, которое опирается на знание бизнес-контекста. Ошибётесь — и анализ окажется технически правильным, но бесполезным.
Диагностика корневых причин по ограниченным доказательствам: отличить проблему дизайна от несоответствия ментальной модели от контентного провала от бага требует знания того, как устроен продукт, кто пользователь и что команда уже пробовала. Модели будут гадать о причинах из одного текста и выдавать правдоподобные, но неверные диагнозы.
Калибровка серьёзности под бизнес-реальность: однокабзацная рубрика серьёзности не может уловить, что заминка на странице биллинга — критический сигнал оттока в этой конкретной компании, а заминка на странице настроек — косметика. Серьёзность нужно повторно привязывать к бизнес-импакту тем, кто знает и продукт, и бизнес.
Замечать режимы отказа, которых модель не видела: AI-кластеризация тяготеет к частым категориям и тихо роняет редкие крайние случаи, которые часто и важнее всего, — провал, который ловит один процент пользователей на высокодоходном сценарии, или новый режим отказа, который привнёс последний релиз. Исследователю нужно вручную прочитать выбросы, прежде чем доверять таксономии.
Разговор на readout-е: стейкхолдеры коммитятся на фиксы на встрече, а не в документе. AI может сделать защитимый драфт, но живая дискуссия, где product, design и engineering торгуются по приоритетам и трейдоффам, — это место, где отчёт реально вызывает изменения.

AI-усиленный workflow

До AI анализ ошибок на сотне наблюдений занимал три-пять дней времени аналитика: день — прочитать каждое наблюдение и написать открыто закодированные заметки, полдня — собрать таксономию на стикерах, день — переразметить всё против таксономии, полдня — построить таблицу частот, остальное — написать бриф. Бутылочное горлышко — два прохода кодирования, медленные, повторяющиеся и склонные к дрейфу, когда внимание аналитика начинает плыть к восьмидесятому наблюдению.

С AI в workflow тот же проект сжимается до одного-двух дней. Исследователь тратит час на формулировку scope и выбор источника, потом скармливает сырые наблюдения в LLM с промптом, который выдаёт черновик таксономии за минуты. Исследователь просматривает таксономию, редактирует там, где модель пропустила контекст, и добавляет режимы отказа, которые модель схлопнула. Структурный проход кодирования потом гонится против вычищенной таксономии на машинной скорости, исследователь проверяет 10–20% меток и переопределяет, где надо. Таблица частот и матрица серьёзности генерируются автоматически. Время исследователя уходит на шаги, которые важнее всего: scope, диагностика корневых причин и разговор на readout-е.

Загвоздка та же, что и для AI-усиленного desk research и эвристической оценки: ускорение реально только тогда, когда человек верифицирует вывод AI, а не доверяет ему. Исследования LLM-driven качественного кодирования показывают, что модели надёжно кластеризуют простые паттерны, но тихо роняют редкие и неоднозначные, а оценки серьёзности дрейфуют к середине рубрики, если человек её не якорит. Исследователи, которые получают от AI здесь больше всего пользы, относятся к нему как к быстрому джуниор-кодировщику: полезно для массового прохода, никогда не доверять как финальному ответу, всегда в паре с человеком, который читает выбросы и отвечает за диагноз.

Пример из практики

Среднеразмерная e-commerce компания увидела 12-процентное падение завершения мобильного оформления заказа после редизайна, в котором экраны адреса, оплаты и проверки были схлопнуты в одну длинную страницу. Аналитика чётко показывала падение, но не объясняла, что происходит между началом страницы и провалившимися отправками. У продакт-менеджера было две недели, чтобы вернуть утерянную конверсию до начала праздничного сезона.

Лид-исследователь подняла три потока данных за окно в 14 дней: 180 записей сессий, отфильтрованных по мобильным пользователям, которые начали оформление, но не завершили, 240 тикетов поддержки с тегами по ключевым словам checkout и лог фронтенд-ошибок из Sentry за тот же период. Записи она загрузила в Dovetail, тикеты — в Google Sheet, исключения Sentry — в отдельную вкладку. Она прогнала проход открытого кодирования на выборке из 60 записей и 60 тикетов, написав свободные метки для первого наблюдаемого провала в каждом. Затем она скормила все 120 свободных меток Claude с промптом-кластеризацией и получила черновик таксономии из семи режимов отказа — три из которых она оставила дословно, три отредактировала для ясности, а один разделила на два, потому что он смешивал контентный провал с реальным багом. После этого она переразметила все 420 наблюдений (180 записей + 240 тикетов) против вычищенной таксономии за два дня.

Таблица частот показала, что 41% всех провалов приходился на один режим: пользователи тапали по полю автозаполненного адреса, ожидая, что смогут отредактировать его inline, и вместо этого получали модальный пикер адреса, который терял контекст корзины при нажатии «назад». Лог Sentry подтверждал JavaScript-ошибку на обработчике закрытия модального окна. Рекомендованным фиксом было полностью убрать модальное окно и позволить редактировать автозаполненный адрес inline. Инжиниринг выкатил изменение за три дня, режим отказа исчез из следующей выборки, а коэффициент завершения оформления заказа восстановился на 9 пунктов в первую неделю — около трёх четвертей от изначальной потери. Анализ занял четыре дня работы исследователя, меньше половины того, что потребовал бы повторный модерируемый юзабилити-тест.

AI-промпты для этого метода

4 готовых AI-промптов с placeholder’ами — скопируйте и подставьте свой контекст. Все промпты для «анализа ошибок» →.