Показал прототип реальным людям — они сломали всё за десять минут. Вот что я узнал

Я был уверен, что прототип готов. Три недели итераций, вылизанные экраны, аккуратные микроанимации, продуманный онбординг. Принёс на коридорный тест пяти людям — и за десять минут они разнесли его в пыль. Не потому что были злыми. Потому что они не были мной.

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

Эта статья — не про методологию юзабилити-тестов. Их и без меня описали. Это разбор того, что реально происходит, когда дизайнер впервые показывает свою работу не коллегам, а живым пользователям. Какие иллюзии разваливаются, какие паттерны повторяются у всех команд, и что с этим делать на следующей итерации — не через полгода, а на этой неделе.

## Почему «показать живым людям» так больно

В голове дизайнера прототип — это законченная история. Ты помнишь, почему кнопка стоит именно тут, какой сценарий привёл к этому экрану, что будет на следующем шаге. У пользователя в голове — пустота и задача. Он не видел макетов до этого, не сидел на воркшопах, не читал бриф.

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

### Что именно ломается чаще всего

• Названия разделов, которые казались очевидными — никто не понимает, что внутри
• Главное действие на экране — пользователь его не видит и кликает в логотип
• Онбординг — пролистывается за две секунды, всё забыто
• Иконки без подписей — угадываются хуже, чем кажется команде
• Состояния ошибок и пустые экраны — оказываются основным опытом, а не исключением

Когда это видишь вживую, первое желание — оправдаться. «Они же не дочитали», «они торопились», «реальный пользователь был бы внимательнее». Нет. Реальный пользователь будет ещё невнимательнее, потому что у него не будет тебя за плечом.

## Подготовка: что сделать до того, как звать людей

Большинство провальных тестов проваливаются не во время сессии, а до неё. Команда зовёт людей «посмотреть прототип», не договорившись, что именно проверяет.

### Сформулируй гипотезу, а не «потестим»

«Потестим онбординг» — не задача. Задача звучит так:

• «Проверяем, понимает ли новый пользователь, что наш продукт делает, за первые 30 секунд»
• «Проверяем, доходит ли человек до создания первого проекта без подсказок»
• «Проверяем, что блок с тарифами не пугает на этапе регистрации»

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

### Чеклист готовности прототипа к встрече с людьми

• Есть один основной сценарий, который реально кликается от начала до конца
• Реалистичные данные, а не «Lorem ipsum» и «Имя Фамилия»
• Состояния ошибок и пустые экраны прокликаны, а не «потом доделаем»
• Заглушки и неактивные кнопки помечены, чтобы не сбивать пользователя
• Прототип открывается на том устройстве, на котором его будут смотреть
• У тебя есть отдельный документ для заметок, а не Figma поверх макета

### Антипаттерны на этапе подготовки

• Показывать «всё, что успели нарисовать» — пользователь утонет, ты получишь шум
• Тестировать с коллегами из соседней команды — они уже знают продукт лучше, чем покажут
• Готовить сценарий, который ведёт пользователя за руку («теперь нажмите сюда») — это демонстрация, а не тест
• Звать только лояльных клиентов — они будут вежливыми и бесполезными

## Первые десять минут сессии решают всё

На реальном тесте ценная информация приходит не из ответов на вопросы, а из того, что человек делает молча в первые минуты. Куда смотрит, куда ведёт курсор, где замирает, где хмурится. Если ты в это время говоришь — ты затираешь сигнал собственным голосом.

### Минимальный протокол ведения сессии

• Объясни, что тестируешь продукт, а не человека — буквально этими словами
• Попроси думать вслух, но не дави, если замолкает
• Дай задачу формулировкой пользователя, не своей: «вам нужно записаться к врачу», а не «откройте раздел "Запись"»
• Не подсказывай, даже если больно смотреть. Пауза в 15 секунд кажется вечностью, но именно там живёт инсайт
• Фиксируй не выводы, а наблюдения: «3 секунды искал кнопку "Далее"», а не «навигация плохая»

### Вопросы, которые стоит задавать после задачи

• Что вы ожидали увидеть на этом экране?
• В какой момент стало непонятно?
• Если бы это был ваш реальный сценарий, вы бы продолжили или закрыли?
• Чего здесь не хватает, чтобы вы доверились продукту?

Короткий итог первого блока: тест ломает прототип не потому что прототип плохой, а потому что впервые встречается с контекстом, в котором он будет жить. Чем раньше устроишь эту встречу — тем дешевле обойдутся выводы.

## Разбор находок: как превратить сессию в решения

После пяти-семи сессий у тебя на руках куча заметок, скриншотов и обрывков фраз. На этом этапе большинство команд делает одну из двух ошибок: либо хватается чинить первое попавшееся, либо устраивает большое совещание «обсудить результаты» и тонет в субъективных оценках. Ни то, ни другое не работает.

### Разбери наблюдения по слоям

Перед тем как что-то править, разложи всё, что собрал, по трём слоям. Один и тот же провал может жить на любом из них, и лечится он по-разному.

• Интерфейс: человек не увидел кнопку, не понял лейбл, промахнулся по тач-таргету. Чинится макетом.
• Сценарий: человек дошёл туда, куда мы его не ждали; нашёл короткий путь, о котором мы не думали; застрял там, где у нас «и так понятно». Чинится логикой флоу.
• Модель продукта: человек не понимает, что это за штука, кому она нужна и зачем платить. Никакими кнопками не чинится — это разговор с продактом и маркетингом.

Если перепутать слои, будешь полировать иконки в продукте, у которого сломано позиционирование.

### Считай частоту, а не громкость

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

Сколько людей споткнулось	Что с этим делать
1 из 5–7	Записать, не трогать
2–3 из 5–7	Проверить гипотезой, починить в ближайшем спринте
4+ из 5–7	Чинить сейчас, остальное подождёт

Это грубо, но дисциплинирует. Без такой шкалы команда всегда чинит то, что громче кричал последний участник.

## Типичные ошибки диагностики

### Подменять причину симптомом

Пользователь сказал: «Мне нужна кнопка "Назад" вот здесь». Слабая команда рисует кнопку. Сильная — спрашивает себя, почему он вообще захотел назад. Часто оказывается, что предыдущий экран не дал ему уверенности, и он пошёл проверять. Кнопка тут — пластырь, а лечить надо тот экран.

### Чинить по одному человеку

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

### Лечить там, где удобно, а не там, где болит

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

## Как переносить выводы в макет

### Начни с экранов, где люди молчали

Самые опасные места теста — не там, где пользователь ругался, а там, где он замолчал и начал двигать курсором кругами. Молчание означает, что человек строит свою модель происходящего вместо того, чтобы действовать. В макете эти места требуют не украшения, а ответа на вопрос «что здесь сейчас и что я могу сделать дальше».

### Чеклист правок после теста

• Главное действие на экране визуально доминирует, и это проверено не только на десктопе
• Названия разделов переписаны словами пользователей из стенограмм, а не словами команды
• Пустые состояния отвечают на вопрос «что мне делать прямо сейчас», а не «здесь пока ничего нет»
• Ошибки объясняют, что произошло и как выйти, без «Error 4002»
• Иконки, которые угадывались хуже половины раз, получили подписи
• У каждой правки в файле есть ссылка на конкретное наблюдение, а не «после теста решили»

Последний пункт важнее, чем кажется. Через две недели никто не вспомнит, почему кнопка переехала. Если рядом с правкой нет «двое из пяти искали её внизу», на следующем ревью её передвинут обратно.

### Вопросы для дизайн-ревью перед следующим тестом

• Какую гипотезу мы проверяем именно этой версией макета?
• Что мы готовы услышать и какой ответ нас расстроит?
• Где в макете остались места, которые мы «и так понимаем» — и не проверили?
• Какие правки мы внесли по одному голосу и зачем?
• Что мы сознательно не чиним до следующей итерации, и почему это безопасно?

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

## Когда подключать AI и где он ломается

Соблазн понятный: тест на пять человек дал тебе сто пятьдесят минут записи, расшифровку, заметки в FigJam и кучу скриншотов. Хочется загрузить всё в модель и получить «топ-5 проблем». Иногда это работает, но проваливается чаще, чем кажется.

### Что AI делает хорошо в разборе теста

• Сводит расшифровки в тематические кластеры, когда ты сам уже потерял картину
• Подсвечивает места, где пользователь меняет формулировки задачи (часто это и есть смена ментальной модели)
• Переписывает интерфейсные тексты словами из стенограмм, если ты дашь ему сырые цитаты
• Готовит черновик отчёта для команды по твоей структуре находок

### Что AI делает плохо

• Считает за «инсайт» любую длинную цитату, особенно эмоциональную
• Уверенно придумывает паттерн там, где было одно наблюдение
• Сглаживает противоречия между пользователями, хотя именно противоречия и интересны
• Теряет контекст сценария: видит фразу «не понял», но не видит, что человек уже три минуты тыкал в неактивный элемент

Рабочее правило: AI помогает на этапе сортировки и оформления, но не на этапе решения «что чинить». Кластеризацию делегируй, приоритизацию — нет.

### Безопасный процесс с моделью

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

## Как объяснять решения команде

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

### Структура разбора, которая не превращается в спор

• Сценарий: какую задачу человек пытался решить
• Что увидели: короткое наблюдение, без интерпретации
• Сколько раз повторилось: цифра, пусть и маленькая
• Гипотеза причины: почему это случилось
• Что предлагаем: одно изменение, не три
• Что осознанно не трогаем: и почему это безопасно отложить

Последний пункт обычно забывают, а он снимает половину тревоги у продакта. Когда команда видит, что ты сам разделил «чиним сейчас» и «ждёт следующего цикла», доверие к остальным пунктам растёт.

### Антипаттерны на разборе

• Показывать видео целиком. Никто не пересматривает запись — выбирай тридцатисекундные фрагменты под конкретное наблюдение.
• Начинать с решения. «Я предлагаю переделать шапку» без сценария читается как вкусовщина, даже если за этим пять провалов подряд.
• Спорить о вкусах в реальном времени. Если на ревью всплывает «мне не нравится цвет», уводи в отдельную ветку, не смешивай с находками теста.
• Голосовать за правки. Тест — не демократия. Решения принимает тот, кто отвечает за результат флоу, опираясь на частоту и сценарий.

## Как проверить, что ты сделал тест хорошо

### Чеклист качества разбора

• Для каждой правки в макете есть ссылка на конкретное наблюдение, а не общая отсылка к тесту
• Различены инсайты по интерфейсу и по продукту, и они едут в разные очереди
• Есть хотя бы одна находка, которая противоречит твоей исходной гипотезе — если нет, ты, скорее всего, слышал только удобное
• Список «не чиним сейчас» не пустой и обоснован
• Команда после ревью знает, что попадает в ближайший спринт, а что — нет
• Через две недели ты сможешь восстановить логику решения, не пересматривая записи

### Вопросы себе перед следующим раундом

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

Короткий итог сегмента: продвинутый тест — это не больше респондентов и не более умный инструмент. Это дисциплина на разборе: отделять наблюдение от вывода, вывод от решения, решение от его упаковки для команды. AI и аналитика ускоряют первые шаги, но за последний по-прежнему отвечает живой человек с именем в Jira.

## Чеклист на каждый раунд тестов

Этот список проходишь руками перед тем, как сесть за разбор. Не для красоты — для того, чтобы потом не оправдываться перед собой и командой.

### До теста

• Сценарии записаны как задачи пользователя, а не как «покажите экран Х»
• В прототипе живые только те узлы, которые ты реально готов услышать ломающимися
• Заранее зафиксирована гипотеза, которую тест может опровергнуть — письменно, до первого респондента
• Договорённость с собой: что считается «провалом» сценария, а не «ну он просто не разобрался»
• Запись и расшифровка организованы так, что через месяц ты найдёшь нужный фрагмент за минуту

### Во время теста

• Молчишь дольше, чем хочется — пауза часто вытаскивает настоящую реакцию
• Не подсказываешь словами из интерфейса («а вы видели кнопку Продолжить?»)
• Не объясняешь, «как задумано» — пока человек не закончил сценарий
• Записываешь не только слова, но и где руки/курсор зависли

### После теста

• Каждая находка привязана к конкретной реплике или моменту записи
• Разделены проблемы интерфейса и проблемы продукта — это разные очереди
• Есть список «не чиним сейчас» с обоснованием
• Решения сформулированы как одно изменение на одну находку, а не пакетом

## Анти-паттерны, которые ломают тест задним числом

Тест может пройти хорошо, а ценность — утечь на этапе интерпретации. Ниже — то, что встречается чаще всего.

### «Мы тестировали — значит, обосновано»

Тест становится индульгенцией. Любое спорное решение защищается фразой «так показал юзер-тест», хотя в тесте было два человека и один из них спешил. Если ссылаешься на тест — называй число повторений и сценарий. Если повторение одно — это сигнал к следующему раунду, а не аргумент.

### Перепаковка вкусов в находки

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

### Один респондент — большое решение

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

### Чинить всё подряд

После теста есть искушение взять список из пятнадцати пунктов и проехать по всем. Через спринт макет становится мозаикой компромиссов, а флоу — нет. Лучше две правки, которые ты можешь объяснить, чем пятнадцать, которые ты не сможешь защитить.

### «AI уже всё разобрал»

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

## Вопросы для ревью находок

Эти вопросы задавай не респонденту, а себе и команде, когда разбираете результаты. Они режут половину пустых дискуссий.

• На каком сценарии это случилось и сколько раз повторилось?
• Это проблема интерфейса или проблема продукта — и в какую очередь едет?
• Что мы осознанно не чиним по этой находке и почему это безопасно?
• Какое одно изменение мы делаем — и как поймём через две недели, что оно сработало?
• Есть ли в списке находка, которая ломает нашу исходную гипотезу? Если нет — тест провёл сам себя.
• Какие правки идут по одному голосу и готовы ли мы их защитить через месяц?

## Короткий практический итог

Реальные люди ломают прототип не потому, что он плохой, а потому что у них нет твоего контекста. Это и есть ценность теста — не подтверждение, а потеря контекста, которую можно увидеть со стороны.

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

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