В среду в 17:40 дизайнер открывает Figma и говорит: «Сценарий почти готов, завтра можно отдавать в разработку».
На экране — выбор тарифа. Карточки аккуратные, кнопка заметная, в правом верхнем углу уже висит комментарий PM: «Только давайте быстрее, релиз в спринте».
Внутри команды всё понятно. Что значит тариф. Почему кнопка называется именно так. Почему после клика будет ещё один шаг подтверждения. Почему права доступа спрятаны во второй экран.
Пользователь этого не знает.
Он видит кнопку «Подключить» и думает: деньги спишутся сейчас или потом? Он видит два похожих тарифа и не понимает, за что доплачивает. Он видит новую настройку и не знает, безопасно ли её включать.
Вот зачем нужно тестирование прототипа до разработки. Не чтобы доказать истину на все времена. А чтобы поймать места, где интерфейс уже сейчас просит у пользователя слишком много доверия.
Пока это один комментарий в Figma, а не неделя переделки фронтенда.
Что мы на самом деле проверяем
Слово «тестирование» легко уводит не туда.
В разработке тестирование часто означает: кнопка нажимается, форма отправляется, ошибка показывается, данные сохраняются. Это важно, но UX-риск появляется раньше.
Когда команда проверяет прототип, она спрашивает другое:
- человек понял, зачем ему этот экран;
- понял, какой шаг главный;
- понял, что произойдёт после клика;
- доверяет ли действию;
- видит ли разницу между вариантами;
- говорит ли интерфейс человеческим языком, а не языком команды.
Технически экран может быть идеальным. Но если пользователь боится нажать на главный CTA, сценарий всё равно слабый.
В теории команда проверяет макет.
На практике команда проверяет ожидание пользователя.
Проверять нужно путь, а не отдельный экран
Плохая проверка звучит так: «Посмотри, нормальный экран?»
Хорошая проверка звучит иначе: «Новый пользователь после пробного периода выбирает тариф для команды. Понимает ли он, какой вариант выбрать и что будет после клика?»
Разница огромная.
Когда мы смотрим только на экран, легко начать обсуждать вкус: цвет кнопки, плотность карточек, порядок блоков. Когда мы смотрим на путь, появляются реальные вопросы:
- откуда человек пришёл;
- что он уже знает;
- какой шаг для него рискованный;
- где он может остановиться;
- что должно стать понятнее без объяснений дизайнера.
Прототип не обязан быть красивой постановкой. Но он должен вести по одному понятному маршруту: старт, выбор, действие, результат.
Если маршрут не читается в Figma, разработка редко спасает ситуацию. Код добавит скорость и состояния. Смысл он за команду не допишет.
Какие UX-риски видно до кода
До разработки не видно всего. Нельзя точно узнать конверсию, реальное поведение, готовность платить или долгосрочное доверие.
Зато уже видно много дорогих промахов.
Неясная ценность. Человек видит функцию, но не понимает, зачем она ему сейчас.
Слабый следующий шаг. В интерфейсе есть кнопка, но неясно, что произойдёт после нажатия.
Тревожное действие. Деньги, удаление, публикация, доступы или права объяснены слишком скупо.
Похожий выбор. Две карточки выглядят одинаково, а разница между ними спрятана в мелком тексте.
Внутренний язык. Команда пишет «расширенные правила доступа», а пользователь хочет понять: кто увидит мой проект?
Лишний шаг. Сценарий просит пройти экран, который ничего не объясняет и не помогает принять решение.
Плохой момент доверия. Продукт просит важное действие, но не отвечает на вопрос: «А это безопасно?»
Это не мелочи. Часто именно они ломают сценарий после релиза.
Не потому что команда плохо работала. А потому что команда слишком хорошо знала продукт.
Как быстро проверить прототип
Начинать лучше не с инструмента. Начинать лучше с рамки.
1. Назовите ситуацию пользователя
Не «проверяем тарифы».
А так: «Владелец небольшой команды закончил пробный период и решает, платить ли за продукт дальше».
Ситуация сразу меняет взгляд. Теперь важны не только карточки тарифа, но и тревога перед оплатой, сравнение вариантов, доверие к следующему шагу.
2. Выберите один главный сценарий
Не пытайтесь за один прогон проверить весь продукт.
Лучше один важный путь:
- выбрать тариф;
- отправить заявку;
- пригласить коллегу;
- настроить доступ;
- отменить опасное действие;
- понять ценность новой фичи.
Чем шире проверка, тем мутнее результат.
3. Уберите устные объяснения
Покажите прототип так, будто рядом нет дизайнера.
Если смысл держится на фразе «ну тут мы потом объясним», это уже сигнал. Пользователь в продакшене тоже не будет сидеть с вашей командой в Zoom.
4. Смотрите на моменты сомнения
Не спрашивайте только «понравилось или нет».
Фиксируйте места, где человек:
- перечитывает текст;
- не понимает разницу между вариантами;
- боится нажать;
- ждёт другого результата;
- не видит следующий шаг;
- говорит: «Наверное, тут имеется в виду…»
Слово «наверное» — маленькая красная лампочка.
5. Разложите риски по цене ошибки
Не каждый комментарий должен тормозить разработку.
Если риск связан с оплатой, доступами, удалением, активацией или ключевой метрикой, чините раньше. Если это слабая подпись в третьем экране, можно поправить по пути.
Цель проверки — не собрать бесконечный список замечаний. Цель — понять, что опасно тащить в код.
Как выбрать метод проверки
Метод зависит от риска.
Если команда просто хочет убрать очевидные шероховатости, хватит самопроверки по чеклисту. Пройдите сценарий без внутренних объяснений и честно спросите: «Что здесь понял бы человек со стороны?»
Если сценарий важный и спорный, полезен экспертный UX-аудит. Внешний взгляд быстрее замечает внутренний язык, слабую обратную связь, тревожные действия и места, где пользователь теряет контроль.
Если нужно быстро сравнить несколько вариантов до разработки, можно использовать AI-респондентов. Это ранний сигнал: какие вопросы повторяются, где сценарий выглядит мутно, какой текст вызывает сомнение. Не доказательство поведения реальных людей, а быстрая проверка слабых мест.
Если ошибка дорогая — деньги, доверие, активация, крупная ставка на фичу — нужны реальные пользователи, данные или A/B-тест. Тут нельзя притворяться, что быстрый аудит заменил исследование.
Рабочее правило простое:
- низкий риск — чеклист;
- средний риск — экспертный взгляд или AI-респонденты;
- высокий риск — реальные пользователи и данные;
- очевидная проблема — чинить сразу, не ждать исследования.
Быстрый аудит не заменяет ресерч. Он помогает не нести в ресерч сырой сценарий с дырой посередине.
Пример: экран тарифа перед разработкой
Вернёмся к тарифу.
В макете есть две карточки: «Команда» и «Бизнес». Внутри команды все знают, что «Бизнес» нужен тем, кто хочет роли, ограничения доступа и отчёты.
На прототипе пользователь видит другое: две похожие карточки, похожие списки возможностей и кнопку «Подключить».
Проблема не в том, что кнопка плохая сама по себе. Проблема в том, что она стоит в тревожном месте.
Человек не понимает:
- это сразу оплата или следующий шаг;
- можно ли отменить;
- чем дорогой тариф реально лучше;
- кто получит доступ после подключения;
- что изменится в текущем аккаунте.
Такой экран можно улучшить без большого редизайна.
Было: «Подключить».
Лучше: «Перейти к подтверждению».
Под кнопкой: «Списание произойдёт на следующем шаге».
Было: «Расширенные правила доступа».
Лучше: «Можно ограничить доступ к проектам по ролям».
Было: две похожие карточки.
Лучше: короткий блок «Что добавится в этом тарифе» рядом с ценой.
Это и есть нормальный результат тестирования прототипа: не большой отчёт ради отчёта, а несколько точных правок, которые снижают страх и путаницу до разработки.
Где здесь может помочь UXDog
UXDog стоит использовать аккуратно: не как «замену пользователям», а как быстрый предварительный аудит сценария, прототипа, текста или интерфейсного риска с AI-респондентами.
Хороший формат задачи:
«Пользователь выбирает тариф после пробного периода. Нужно понять, где он может не понять разницу между вариантами, испугаться оплаты или не увидеть следующий шаг».
После такого прогона команда смотрит не на абстрактную оценку дизайна, а на повторяющиеся сигналы:
- где сценарий выглядит неясным;
- какие вопросы возникают перед кликом;
- какие формулировки звучат внутренним языком;
- какой риск стоит проверить на реальных пользователях;
- что можно исправить прямо в прототипе.
Повторяющийся сигнал — не истина. Но это хороший повод остановиться и посмотреть внимательнее.
Особенно до того, как задача уедет в разработку.
Чеклист перед передачей прототипа
Перед разработкой пройдитесь по короткому списку:
- какую задачу пользователь решает в этом сценарии;
- откуда он пришёл на первый экран;
- какой шаг считается успехом;
- что он должен понять без комментария команды;
- где действие связано с деньгами, данными, доступами или удалением;
- понятно ли, что произойдёт после главной кнопки;
- какие варианты выбора выглядят слишком похожими;
- где текст написан внутренним языком;
- что команда готова поменять после проверки;
- какие вопросы нужно вынести к реальным пользователям.
Плохой вопрос: «Экран нормальный?»
Хороший вопрос: «Понимает ли человек, что произойдёт после клика, и достаточно ли он доверяет этому действию?»
Коротко о терминах
Что такое тестирование прототипа? Это проверка сценария до разработки: понимает ли человек задачу, следующий шаг, ценность действия и последствия клика.
Чем тестирование интерфейса отличается от QA? QA проверяет, работает ли продукт технически. UX-проверка смотрит раньше: понятно ли, что делать, зачем это делать и можно ли доверять результату.
Можно ли проверить прототип без пользователей? Можно найти вероятные UX-риски: непонятный текст, тревожный CTA, похожий выбор, слабое объяснение. Но для доказательства поведения нужны реальные пользователи, данные или A/B-тест.
Когда нужны AI-респонденты? Когда нужно быстро получить ранний сигнал по сценарию, экрану, тексту или прототипу до разработки. Это способ подготовить более сильную итерацию, а не заменить полноценный ресерч.
Что в итоге
Тестирование прототипа до разработки не делает команду медленнее.
Оно убирает дорогую самоуверенность.
Пока сценарий живёт в Figma, его можно быстро поправить: переименовать кнопку, объяснить следующий шаг, показать разницу между тарифами, убрать внутренний язык, добавить момент доверия.
После разработки всё это тоже можно сделать. Просто дороже.
Сначала ловим очевидные UX-риски. Потом проверяем важное глубже.