Момент, когда прототип наконец выглядит законченным, часто воспринимается командой как естественная точка перехода к разработке. Экраны собраны, переходы настроены, основные действия пользователя можно прокликать от начала до конца. Кажется, что следующий логичный шаг — передать макеты разработчикам и начинать реализацию.
На практике именно здесь я бы не торопился.
В работе с исследованиями и анализом данных я регулярно сталкиваюсь с ситуацией, когда «готовый прототип» означает совершенно разные вещи для разных участников команды. Для дизайнера это может быть завершённый набор экранов и компонентов. Для продакт-менеджера — отражение согласованной продуктовой логики. Для разработчика готовность начинается там, где понятны состояния интерфейса, ограничения, источники данных и поведение системы в нестандартных ситуациях. А для пользователя всё это вообще не имеет значения, если он не понимает, куда нажать и как решить свою задачу.
Поэтому я предпочитаю считать готовым не тот прототип, в котором больше нечего дорисовывать, а тот, вокруг которого снята критическая неопределённость. Команда понимает основные пользовательские сценарии, знает, какие предположения уже проверены, видит оставшиеся риски и может объяснить, почему выбранное решение стоит реализовывать именно в таком виде.
Визуальная завершённость здесь легко вводит в заблуждение. Аккуратный интерфейс создаёт ощущение определённости даже тогда, когда за ним остаются непроверенные гипотезы. Пользователь может иначе понимать навигацию, пропускать важное действие или ожидать другого результата после нажатия кнопки. Иногда такие проблемы обнаруживаются только после запуска продукта — когда изменение сценария затрагивает уже не несколько экранов в прототипе, а интерфейс, бизнес-логику, аналитику и написанный код.
Часть этой неопределённости можно снять ещё до разработки. Например, дать пользователям пройти ключевой сценарий на прототипе, наблюдать за их действиями, а затем собрать структурированную обратную связь через Тестограф. При этом важно не просто спросить, понравился ли интерфейс. Гораздо полезнее выяснить, понял ли человек задачу, смог ли самостоятельно пройти сценарий, где сомневался и совпал ли полученный результат с его ожиданиями.
Эта статья предназначена прежде всего для продуктовых менеджеров, UX/UI-дизайнеров, основателей цифровых продуктов и разработчиков, которые участвуют в принятии решения о переходе от прототипа к реализации. Мы разберём этот переход не как формальную передачу макетов, а как отдельную точку принятия решения.
Я предлагаю смотреть на готовность прототипа сразу с нескольких сторон: понятны ли пользовательские сценарии, проверены ли наиболее рискованные предположения, проработаны ли состояния и исключения, одинаково ли команда понимает поведение продукта и остаются ли вопросы, ответы на которые могут существенно изменить решение уже во время разработки.
И здесь не нужна иллюзия абсолютной определённости. Проверить заранее каждую деталь невозможно, да и не всегда рационально. Задача перед стартом разработки другая: понять, какие неизвестные ещё остались и насколько дорого будет ошибиться в каждой из них.
Именно с этой позиции дальше разберём, когда прототип действительно можно считать готовым к разработке, что стоит проверить до передачи макетов и в каких случаях дополнительное исследование экономит команде значительно больше времени, чем занимает.
Когда я оцениваю готовность прототипа, меня в первую очередь интересует не количество отрисованных экранов, а количество вопросов, которые разработчикам придётся самостоятельно решать во время реализации. Чем больше таких вопросов остаётся, тем меньше прототип похож на готовое описание продукта.
Это не означает, что дизайнер должен заранее описать каждую техническую деталь. Но пользовательская логика должна быть достаточно определённой, чтобы разработчик не был вынужден додумывать поведение продукта.
Основной сценарий должен работать целиком
Начать стоит с самого важного пользовательского пути. Если мы разрабатываем сервис бронирования, недостаточно показать экран выбора услуги и красивую форму подтверждения. Нужно понимать весь путь: от входа в сценарий до момента, когда пользователь получил ожидаемый результат.
Полезно пройти прототип именно так, как его будет проходить человек, который впервые видит продукт. Не объяснять, куда нажимать, не пропускать очевидные для команды этапы и не исходить из того, что пользователь уже знает внутреннюю логику сервиса.
На этом этапе часто обнаруживаются довольно простые проблемы. Например, после выполнения действия непонятно, произошло ли оно успешно. Или пользователь может вернуться на предыдущий шаг, но команда не определила, сохранятся ли введённые данные. Или один и тот же объект можно открыть несколькими способами, а дальнейшее поведение интерфейса предусмотрено только для одного из них.
Если подобные вопросы возникают при просмотре прототипа, с большой вероятностью они возникнут и у разработчиков.
Одних идеальных сценариев недостаточно
В прототипах есть естественная склонность показывать продукт в его лучшем состоянии: данные загрузились, пользователь всё заполнил правильно, сервер ответил, нужный объект существует, доступ разрешён.
Реальный продукт работает иначе.
Что произойдёт, если поиск ничего не найдёт? Как выглядит форма после ошибки? Можно ли отправить её повторно? Что увидит пользователь без необходимых прав доступа? Что произойдёт при удалении объекта? Как интерфейс сообщает, что данные ещё загружаются?
Именно такие состояния я советую обсуждать до разработки хотя бы для критичных сценариев.
Не обязательно превращать прототип в энциклопедию всех возможных ошибок. Здесь полезнее ориентироваться на последствия. Если неопределённое состояние может заблокировать пользователя, привести к потере данных или потребовать изменения основной логики интерфейса, его лучше проработать заранее.
Нужно определить не только экраны, но и правила
Одна из распространённых проблем возникает, когда макет хорошо отвечает на вопрос «как это выглядит», но почти не отвечает на вопрос «как это работает».
Допустим, в интерфейсе есть кнопка «Продолжить». На макете всё понятно: пользователь нажимает её и переходит на следующий экран. Но разработчику может понадобиться гораздо больше информации. Какие поля обязательны? Когда кнопка становится активной? Что происходит при некорректных данных? Можно ли вернуться назад? Сохраняется ли введённая информация? Что произойдёт при повторной отправке?
По отдельности эти вопросы кажутся небольшими. В сумме они и образуют поведение продукта.
Поэтому перед разработкой я рекомендую проверять прототип не только как последовательность экранов, но и как набор правил. Если команда может показать состояние интерфейса, но не может объяснить условия его появления, решение ещё требует уточнения.
Не всё нужно доводить до абсолютной определённости
Обратная крайность — пытаться закрыть в прототипе вообще все возможные ситуации. Такой подход способен надолго задержать разработку, не дав сопоставимой пользы.
Я использую более практичный принцип: чем дороже потенциальное изменение после начала разработки, тем раньше стоит снять неопределённость.
Например, текст подсказки внутри поля обычно можно скорректировать позднее без серьёзных последствий. А изменение структуры регистрации, модели ролей пользователей или последовательности оформления заказа может затронуть сразу несколько частей продукта. Такие решения лучше не оставлять на момент, когда разработка уже идёт.
Особенно внимательно я бы относился к предположениям о поведении пользователей. Фраза «здесь всем будет понятно» — это не подтверждение гипотезы. Если от понимания конкретного элемента зависит прохождение ключевого сценария, его имеет смысл проверить до реализации.
Для этого не всегда требуется масштабное исследование. Иногда достаточно дать прототип нескольким представителям целевой аудитории, поставить перед ними конкретную задачу и посмотреть, как они её выполняют. После прохождения сценария можно собрать ответы через онлайн-опрос, чтобы сопоставить наблюдаемое поведение с тем, как сами участники оценивают понятность решения.
Это важное различие. Пользователь может сказать, что интерфейс понятный, и при этом во время тестирования несколько раз ошибиться или долго искать нужное действие. Поэтому я не советую принимать решение только на основании ответа «всё понятно».
Главный вопрос перед передачей прототипа
Есть простой способ посмотреть на его готовность: представить, что завтра дизайнер и продакт-менеджер становятся недоступны на несколько дней, а разработчики начинают работу только по переданным материалам.
Сколько решений им придётся принять самостоятельно?
Если речь идёт о небольших технических деталях реализации — это нормальная ситуация. Если же разработчику приходится решать, что должен увидеть пользователь, какое действие является правильным, как обрабатывать важные состояния или что вообще происходит после определённого шага, значит, часть продуктового проектирования фактически перенесена на этап разработки.
Поэтому готовность прототипа я бы определял не количеством завершённых макетов. Гораздо важнее, насколько однозначно из них следует поведение продукта и насколько хорошо команда понимает оставшиеся неопределённости.
После этого можно переходить к следующей проверке — перестать рассматривать прототип экран за экраном и пройти его целиком через реальные пользовательские сценарии.
Один из самых полезных приёмов перед передачей прототипа в разработку — перестать на некоторое время смотреть на него как на набор экранов.
При обсуждении макетов команда обычно движется последовательно: открывает главный экран, затем форму, карточку объекта, настройки, личный кабинет. Каждый экран рассматривается отдельно, обсуждаются элементы, тексты, расположение кнопок. В результате отдельные части интерфейса могут выглядеть вполне убедительно, но проблемы появляются между ними.
Пользователь ведь не приходит в продукт ради конкретного экрана. Он приходит с задачей: зарегистрироваться, оформить заказ, создать проект, отправить заявку, найти информацию, изменить тариф или получить результат. Поэтому и прототип перед разработкой полезно проверять через такие задачи.
Пройдите путь от намерения до результата
Представим, что мы тестируем прототип сервиса, в котором пользователь должен создать проект и пригласить коллег. Проверять отдельно форму создания проекта и отдельно окно приглашения недостаточно.
Лучше сформулировать задачу целиком: «Вы впервые открыли сервис и хотите создать новый проект, а затем предоставить доступ двум коллегам».
После этого стоит пройти весь путь без сокращений.
В таком формате становятся заметны проблемы, которые практически невозможно увидеть при обсуждении отдельных макетов. Пользователь успешно создаёт проект, но после этого не понимает, где приглашать участников. Или приглашение отправлено, но интерфейс не сообщает об этом достаточно явно. Или человек случайно закрывает окно и не знает, сохранились ли внесённые изменения.
Каждый экран сам по себе может быть спроектирован правильно. Ошибка находится в связи между ними.
Поэтому для основных функций продукта я рекомендую определить конечную цель пользователя и проверить, существует ли понятный непрерывный путь от точки входа до этой цели.
Основного пути тоже недостаточно
В прототипе часто демонстрируется так называемый счастливый путь: пользователь делает именно то, что от него ожидает команда.
Но реальные люди отклоняются от запланированной последовательности. Они возвращаются назад, нажимают не ту кнопку, меняют решение, пропускают необязательные поля, закрывают окна, пытаются повторить действие или начинают сценарий не с того места, которое предусмотрели дизайнеры.
Нет необходимости прототипировать каждую потенциальную комбинацию действий. Однако для важных сценариев стоит рассмотреть хотя бы три направления: ожидаемый путь, альтернативный путь и ситуацию, когда что-то идёт не по плану.
Например, если пользователь оформляет заявку, команда уже продумала успешную отправку. Но что произойдёт, если он захочет изменить данные перед подтверждением? А если вернётся на предыдущий этап? Если обязательное поле осталось пустым? Если заявка уже была отправлена?
Такие вопросы помогают обнаруживать не столько недостающие экраны, сколько недостающие решения.
Обращайте внимание на места, где требуется догадка
При тестировании прототипов меня особенно интересуют моменты, когда человек останавливается.
Пауза сама по себе ещё не говорит о проблеме. Но если участники исследования регулярно задерживаются в одном месте, возвращаются назад или пробуют несколько элементов подряд, это повод изучить участок сценария подробнее.
При этом прямой вопрос «Вам понятно, что здесь делать?» даёт довольно слабые данные. Человек может ответить утвердительно из вежливости или потому, что после нескольких попыток действительно разобрался.
Гораздо полезнее дать конкретную задачу и наблюдать, что произойдёт без подсказки. Например: «Вы хотите изменить адрес доставки уже созданного заказа. Покажите, как бы вы это сделали».
После выполнения задания можно уточнить, что участник ожидал увидеть, почему выбрал конкретное действие и в какой момент испытывал сомнения. Если исследование проводится удалённо, дополнительные оценки и комментарии удобно собирать через форму обратной связи.
Здесь я обычно разделяю два источника данных: что пользователь сделал и что он рассказал о своём опыте. Они дополняют друг друга, но не заменяют.
Не проектируйте по одному пользователю
После первых тестов возникает другая опасность: воспринимать каждую трудность участника как доказательство того, что интерфейс необходимо менять.
Если один человек не нашёл функцию, причин может быть много. Возможно, проблема действительно в интерфейсе. Возможно, человек невнимательно прочитал текст. Возможно, сценарий для него нетипичен. А возможно, само задание исследования было сформулировано неудачно.
Поэтому полезнее искать повторяющиеся паттерны.
Если несколько участников независимо друг от друга останавливаются в одном месте, ожидают одинакового поведения или совершают одну и ту же ошибку, сигнал становится значительно сильнее.
И здесь особенно важно заранее определить, что именно мы хотим проверить. Не «нравится ли пользователям новый прототип», а, например, «могут ли новые пользователи самостоятельно найти функцию экспорта и выгрузить результат без дополнительной инструкции».
Чем конкретнее исследовательский вопрос, тем проще интерпретировать полученные данные и решить, требуется ли изменение перед разработкой.
Проверка сценария должна заканчиваться решением
Само по себе тестирование прототипа не делает его лучше. Ценность появляется тогда, когда команда понимает, что делать с результатами.
После проверки каждого критичного сценария я бы фиксировал три вещи: что подтвердилось, где обнаружена проблема и насколько эта проблема влияет на возможность пользователя достичь цели.
Если человек немного дольше искал второстепенную настройку, это не обязательно причина откладывать разработку. Если же большинство участников не может самостоятельно завершить основное действие, запуск реализации такого сценария создаёт вполне предсказуемый риск последующей переделки.
Поэтому перед разработкой нам важно не доказать, что прототип идеален. Нужно убедиться, что основные пользовательские пути понятны, критические препятствия обнаружены, а оставшиеся спорные моменты команда видит и принимает осознанно.
Следующий вопрос возникает естественным образом: какие именно гипотезы стоит проверять на пользователях ещё на стадии прототипа и когда такое исследование действительно оправдывает затраченное время.
Есть соблазн отложить пользовательское исследование до момента, когда продукт можно будет показать «как следует»: с настоящими данными, работающими функциями и аккуратно реализованным интерфейсом. Проблема в том, что к этому моменту стоимость изменений становится заметно выше.
Для проверки многих продуктовых гипотез работающий продукт вообще не нужен. Если нас интересует, понимает ли пользователь структуру сервиса, может ли найти нужную функцию, правильно ли воспринимает последовательность действий или ожидает ли определённый результат после нажатия кнопки, достаточно интерактивного прототипа.
При этом слишком раннее тестирование тоже бывает малоэффективным. Если половина переходов отсутствует, элементы постоянно меняются, а исследователь вынужден объяснять участнику, что «здесь пока ничего не работает», мы начинаем проверять ограничения прототипа вместо самого решения.
Я обычно ориентируюсь на простой критерий: прототип готов к пользовательской проверке, когда человек может пройти исследуемый сценарий без постоянной помощи со стороны команды.
Сначала определяем, что именно хотим узнать
Формулировка «давайте покажем прототип пользователям» сама по себе не является планом исследования.
До приглашения участников стоит определить, какое решение будет принято на основании полученных результатов. Например, команда сомневается между двумя вариантами регистрации. Или хочет понять, смогут ли новые пользователи самостоятельно создать первый проект. Или предполагает, что после изменения навигации нужную функцию станет проще находить.
Тогда исследование строится вокруг конкретной неопределённости.
Это помогает избежать одной из распространённых ошибок — сбора большого количества мнений, которые потом сложно превратить в продуктовые решения. Участники могут обсуждать цвета, формулировки, размеры элементов и собственные пожелания, хотя команда на самом деле хотела проверить понятность основного сценария.
Поэтому перед исследованием я советую закончить фразу:
Если продолжение сформулировать сложно, вероятно, исследовательский вопрос пока слишком широкий.
Не спрашивайте пользователя, хороший ли у вас интерфейс
В исследованиях прототипов вопросы иногда звучат примерно так: «Насколько удобным вам кажется новый интерфейс?» или «Понравился ли вам этот вариант?»
Такие оценки можно собирать, но я бы не делал их основой решения о готовности прототипа.
Пользователь способен поставить высокую оценку интерфейсу и при этом не выполнить ключевую задачу. И наоборот: человек может критиковать внешний вид, но быстро и без ошибок пройти нужный сценарий.
Если наша цель — проверить готовность конкретного пользовательского пути, полезнее сначала поставить задачу и посмотреть на поведение участника. Смог ли он начать действие без подсказки? Где остановился? Возвращался ли назад? Правильно ли понял результат? Потребовалась ли помощь?
А уже после выполнения сценария можно задавать уточняющие вопросы.
Например, вместо «Всё было понятно?» я предпочитаю спрашивать: «В какой момент вы больше всего сомневались, что делать дальше?» Такой вопрос не предполагает, что проблема обязательно существовала, но позволяет участнику вспомнить конкретный эпизод.
Наблюдение и опрос решают разные задачи
При проверке прототипа я стараюсь не противопоставлять качественные и количественные методы.
Наблюдение помогает увидеть, что произошло. Последующий опрос помогает лучше понять, как участник воспринимал происходящее.
Допустим, человек довольно долго ищет кнопку создания нового проекта, но в итоговой анкете оценивает понятность интерфейса на 9 из 10. Если посмотреть только на оценку, можно решить, что проблемы нет. Если учитывать поведение, появляется повод разобраться, почему поиск занял столько времени.
Обратная ситуация тоже возможна: пользователь быстро проходит сценарий, но ставит низкую оценку удобству. Тогда стоит выяснить, что именно повлияло на впечатление. Возможно, проблема находится вообще за пределами проверяемого сценария.
Для удалённых исследований удобно собрать ответы участников через Тестограф. В одной анкете можно сочетать шкальные вопросы с открытыми, чтобы получить как сопоставимые оценки, так и комментарии участников.
Но количество вопросов здесь не должно становиться самоцелью. После тестирования прототипа человек уже потратил время и внимание на выполнение задания. Длинная анкета в конце исследования часто даёт менее содержательные ответы просто из-за усталости.
Поэтому я предпочитаю собирать только те данные, которые действительно понадобятся при принятии решения.
Несколько интервью не всегда дают достаточную картину
Небольшое число пользовательских сессий хорошо помогает обнаруживать проблемы и формировать гипотезы. Но иногда после них возникает другой вопрос: насколько наблюдаемая проблема характерна для более широкой аудитории?
Предположим, два участника из нескольких тестов не поняли новую терминологию в интерфейсе. Это важный сигнал, но его ещё нужно интерпретировать. Термин действительно непонятен большинству потенциальных пользователей или трудность возникла у конкретных участников из-за их опыта?
В таких случаях качественное исследование можно дополнить опросом более широкой выборки. Он не заменяет наблюдение за использованием прототипа, зато позволяет проверить распространённость отдельных мнений, ожиданий или предпочтений.
Здесь важно не пытаться получить количественное подтверждение каждой находки. Если проблема очевидно блокирует критический сценарий, иногда разумнее сразу исправить её и провести повторную проверку.
Исследование должно уменьшать неопределённость
Перед каждым дополнительным тестом я задаю себе вопрос: изменится ли наше решение в зависимости от результата?
Если при любом ответе команда всё равно собирается реализовывать интерфейс именно в текущем виде, исследование вряд ли принесёт много пользы. Мы рискуем собирать данные ради подтверждения уже принятого решения.
Если же существуют два или несколько реалистичных вариантов дальнейших действий, проверка становится гораздо ценнее.
Хорошее исследование прототипа не обязательно заканчивается фразой «пользователям всё понравилось». Иногда лучший результат — обнаружить до разработки, что важная гипотеза не подтверждается.
Исправить несколько экранов и повторить сценарий значительно проще, чем прийти к тому же выводу после реализации функциональности.
Но после исследования остаётся ещё одна сложная задача: понять, достаточно ли полученных результатов, чтобы двигаться дальше. Именно этому будет посвящена следующая часть.
После нескольких пользовательских тестов редко возникает идеально однозначная картина. Один участник прошёл сценарий без затруднений, другой остановился на определённом шаге, третий справился, но предложил полностью изменить навигацию. В ответах на опрос тоже могут одновременно встречаться высокие оценки и довольно критичные комментарии.
На этом этапе главная задача команды — не собрать как можно больше замечаний, а правильно определить их вес.
В своей работе с результатами исследований я стараюсь отделять факт от его интерпретации. «Три участника пытались нажать на заголовок вместо кнопки» — наблюдение. «Пользователям непонятен интерфейс» — уже вывод, причём довольно широкий. Чем раньше эти два уровня смешиваются, тем выше риск изменить прототип по неправильной причине.
Отсутствие жалоб ещё ничего не доказывает
Один из слабых критериев успешного тестирования звучит так: «Пользователи ничего плохого не сказали».
Во время исследования участники далеко не всегда сообщают о каждом затруднении. Они могут считать ошибку собственной невнимательностью, не хотеть критиковать работу команды или просто забыть о небольшой проблеме к моменту финального обсуждения.
Поэтому я рекомендую в первую очередь смотреть на выполнение задачи.
Если пользователь должен был самостоятельно изменить настройки и сделал это без подсказок, результат намного информативнее ответа «Да, всё удобно». Если же он несколько минут искал нужный раздел, дважды возвращался назад, получил подсказку модератора, а после этого поставил интерфейсу высокую оценку, именно поведение должно получить больший вес при анализе.
Оценки и комментарии важны, но их стоит рассматривать вместе с тем, что происходило во время выполнения сценария.
Не все проблемы одинаково важны
После тестирования может появиться несколько десятков наблюдений. Исправлять их в порядке поступления — не лучшая стратегия.
Я обычно начинаю с последствий для пользователя.
Критической можно считать проблему, из-за которой человек не способен завершить основной сценарий без посторонней помощи или совершает действие с серьёзными последствиями, не понимая этого.
Следующий уровень — заметные затруднения. Пользователь достигает цели, но делает лишние действия, долго ищет функцию, неоднократно возвращается назад или неправильно интерпретирует элементы интерфейса.
Наконец, остаются субъективные пожелания: изменить расположение элемента, добавить дополнительную возможность, использовать другую формулировку или реализовать привычный конкретному участнику вариант.
Последняя группа особенно опасна тем, что такие комментарии часто звучат очень конкретно: «Перенесите эту кнопку сюда» или «Здесь нужен отдельный раздел». Команде легко воспринять готовое предложение как готовое решение.
Но пользователь хорошо знает собственную проблему и значительно хуже — ограничения продукта, техническую архитектуру и поведение других сегментов аудитории. Поэтому за предложением я стараюсь найти исходную потребность. Не «куда пользователь предлагает перенести кнопку», а «почему он искал действие именно там».
Ищите повторяемость, но не превращайте её в единственный критерий
Если несколько независимых участников сталкиваются с одинаковой трудностью, это сильный сигнал. Особенно когда они совершают похожие действия или одинаково объясняют свои ожидания.
Однако правило «исправляем только то, что встретилось несколько раз» тоже может привести к ошибке.
Некоторые проблемы возникают редко, но имеют высокую цену. Например, один участник обнаружил сценарий, при котором можно случайно потерять введённые данные. Ждать, пока ещё несколько пользователей повторят тот же путь, необязательно.
Поэтому при оценке результатов я смотрю одновременно на повторяемость и последствия. Чем серьёзнее потенциальный ущерб для пользовательского сценария, тем меньше подтверждений может потребоваться для пересмотра решения.
Заранее определённые критерии помогают избежать споров
Интерпретировать исследование значительно проще, если ещё до его начала команда договорилась, какой результат будет считаться приемлемым.
Например, для ключевого сценария можно заранее определить, что участник должен выполнить задачу без прямой подсказки модератора. Для другого исследования важнее проверить правильность понимания терминологии или ожидаемый результат определённого действия.
Тогда после тестирования команда сравнивает данные не с собственными впечатлениями, а с заранее сформулированным ожиданием.
Если дополнительно проводится количественный опрос, аналогичный принцип можно применять к его результатам. В Тестографе ответы можно собирать в единой структуре, чтобы затем сравнивать оценки разных групп респондентов и анализировать открытые комментарии вместе с количественными показателями.
При этом я бы избегал универсальной цифры вроде «если 80% довольны, прототип готов». У разных продуктов слишком разная цена ошибки. Для второстепенной настройки определённый уровень затруднений может быть приемлем. Для оплаты, регистрации или восстановления доступа требования будут совершенно другими.
Когда можно остановить тестирование
Пользовательское исследование практически всегда позволяет найти что-то ещё. Если продолжать проверку до полного отсутствия замечаний, разработка может не начаться никогда.
Поэтому вопрос должен звучать не «остались ли проблемы?», а «остались ли проблемы, из-за которых сейчас неразумно начинать реализацию?».
Я считаю хорошим сигналом ситуацию, когда ключевые сценарии выполняются без критических препятствий, основные закономерности в поведении пользователей уже понятны, а новые сессии преимущественно повторяют известные наблюдения.
Оставшиеся замечания при этом можно разделить на те, которые нужно исправить до разработки, и те, которые допустимо проверить уже на работающем продукте.
Таким образом, успешное тестирование прототипа — это не доказательство его безупречности. Это состояние, при котором команда достаточно хорошо понимает основные риски и может объяснить, почему оставшаяся неопределённость приемлема.
После этого готовность к разработке нужно проверить уже внутри самой команды: убедиться, что дизайнеры, продуктовые специалисты и разработчики одинаково понимают, какой продукт должен получиться и как он должен вести себя в основных сценариях.
Даже хорошо протестированный прототип может оказаться неготовым к разработке, если участники команды понимают его по-разному.
На встрече это не всегда заметно. Дизайнер показывает сценарий, продакт-менеджер подтверждает логику, разработчики задают несколько вопросов — кажется, что все договорились. Расхождения обнаруживаются позже, когда нужно реализовать конкретное поведение.
Например, в прототипе пользователь удаляет объект нажатием одной кнопки. Дизайнер предполагает, что после этого появится возможность отменить действие. Продакт-менеджер считает удаление окончательным. Разработчик ожидает окно подтверждения. Пока существует только прототип, это небольшой вопрос. После начала реализации каждый вариант уже означает разную логику продукта.
Поэтому перед стартом я рекомендую провести не презентацию готового дизайна, а совместный разбор основных сценариев.
У команды должно быть одинаковое понимание продукта
Разработчикам полезно видеть прототип не только в виде набора макетов и спецификаций. Им нужен контекст: какую задачу решает пользователь, почему сценарий устроен именно так и какие решения были приняты после исследования.
Это особенно важно там, где прототип допускает несколько трактовок.
Если разработчик знает только конечный вариант экрана, любое неописанное состояние приходится восстанавливать по логике самостоятельно. Если он понимает пользовательскую задачу и ограничения, вероятность случайного изменения сценария значительно ниже.
Я бы прошёл вместе с командой несколько наиболее важных путей от начала до конца и по ходу обсуждения фиксировал вопросы. Обычно именно разработчики находят ситуации, которые не проявились во время дизайна: повторную отправку запроса, конфликт данных, отсутствие соединения, ограничения прав доступа или невозможность выполнить действие в определённом состоянии.
Это не означает, что техническая команда должна заново проектировать интерфейс. Её участие помогает проверить, насколько задуманное поведение продукта вообще определено и реализуемо.
Технические ограничения лучше обнаружить до передачи макетов
Некоторые решения прекрасно работают в прототипе, потому что прототипу не приходится работать с реальными данными.
В нём информация появляется мгновенно, поиск всегда возвращает аккуратный результат, интеграция отвечает без задержки, а пользователь никогда не сталкивается с конфликтом изменений.
Перед разработкой полезно проверить места, где дизайн опирается на подобные допущения.
Особенно внимательно я бы посмотрел на внешние интеграции, загрузку больших объёмов данных, ограничения API, работу с файлами, авторизацию и синхронизацию между пользователями. Если техническое ограничение способно изменить сам пользовательский сценарий, узнать о нём желательно до начала реализации.
Иногда после такого обсуждения оказывается, что первоначальный вариант возможен, но требует несоразмерно больших ресурсов. Тогда команда может заранее выбрать более простое решение и при необходимости проверить его на пользователях.
Это намного дешевле, чем обнаружить ограничение после реализации половины сценария.
Контент и данные — тоже часть прототипа
Отдельная категория неопределённости появляется из-за условного содержимого макетов.
Дизайнер использует короткое имя пользователя, аккуратное название проекта и три строки текста. В реальном продукте имя может быть длинным, описание — отсутствовать, а вместо трёх объектов в списке окажется несколько сотен.
Поэтому я рекомендую перед разработкой посмотреть на интерфейс с точки зрения реальных данных.
Откуда они появляются? Какие поля обязательны? Что может отсутствовать? Какой объём считается нормальным? Может ли один пользователь видеть информацию, недоступную другому? Что произойдёт, если данные изменятся одновременно в двух местах?
Не на каждый вопрос должен отвечать дизайнер. Важно другое: команда должна увидеть такие вопросы до того, как ответы на них окажутся случайно зашиты в код.
Особого внимания требуют роли и права доступа
Если в продукте существуют разные типы пользователей, одного прототипа «для обычного пользователя» часто недостаточно.
Администратор, владелец проекта, приглашённый сотрудник и пользователь с ограниченными правами могут видеть один и тот же экран совершенно по-разному. Одному доступно редактирование, другому — только просмотр, третьему определённый раздел вообще не должен отображаться.
Неопределённость здесь особенно неприятна, потому что права доступа затрагивают не только интерфейс, но и внутреннюю логику продукта.
До разработки желательно хотя бы определить основные роли и понять, какие действия разрешены каждой из них в критичных сценариях. Детали можно уточнять позднее, но базовая модель доступа должна быть согласована.
Решения нужно фиксировать вместе с причинами
После обсуждения прототипа часто остаётся множество небольших договорённостей. Через неделю участники помнят само решение, но уже не всегда помнят, почему оно было принято.
Я считаю полезным фиксировать не только итог — например, «оставляем один вариант регистрации», — но и короткую причину. Это может быть техническое ограничение, результат пользовательского тестирования, бизнес-требование или сознательное упрощение первой версии продукта.
Такая практика особенно помогает, когда к проекту подключаются новые люди. Им не приходится заново проходить всю историю обсуждений или предлагать вариант, который команда уже проверила и отклонила.
В итоге перед разработкой нам нужна не абсолютная документация каждого пикселя, а согласованная модель продукта. Команда должна понимать основные сценарии, ограничения, состояния, данные и причины наиболее важных решений.
Если этого понимания нет, разработка всё равно начнёт отвечать на оставшиеся вопросы — только ответы будут появляться уже внутри кода.
А это приводит нас к следующей теме: сколько на самом деле может стоить слишком ранний старт разработки и почему небольшая неопределённость в прототипе иногда превращается в весьма дорогую переделку.
Фраза «разберёмся по ходу разработки» сама по себе не означает, что команда допускает ошибку. Некоторые решения действительно нет смысла принимать заранее. Проблема начинается, когда «по ходу» предстоит разобраться не с деталями реализации, а с базовой логикой продукта.
В этом случае разработка незаметно превращается в продолжение проектирования, только эксперименты теперь проводятся не в прототипе, а в коде.
Я бы оценивал риск раннего старта не количеством нерешённых вопросов, а их влиянием. Десять небольших уточнений по текстам могут оказаться дешевле одного вопроса о том, как должен работать основной пользовательский сценарий.
Маленькое изменение интерфейса не всегда означает маленькую переделку
В прототипе поменять последовательность из четырёх шагов на три относительно просто. После начала разработки та же корректировка может затронуть гораздо больше компонентов.
Представим, что команда реализует регистрацию в несколько этапов, а пользовательские тесты позже показывают: люди не понимают, зачем на первом шаге запрашивается часть информации, и отказываются продолжать.
На уровне прототипа можно перестроить последовательность, изменить формулировки и снова проверить сценарий. В работающем продукте изменение потенциально затрагивает интерфейс, валидацию, сохранение промежуточных данных, события аналитики, серверную логику и тесты.
Чем глубже решение встроено в продукт, тем больше связанных элементов приходится пересматривать.
Поэтому до разработки особенно полезно проверять не всё подряд, а решения с высокой стоимостью последующего изменения.
Непроверенная гипотеза не становится фактом после реализации
Иногда команда долго обсуждает продуктовую гипотезу, выбирает наиболее убедительный вариант и начинает разработку. Постепенно первоначальное предположение начинает восприниматься как установленный факт.
Например:
На основании этого предположения проектируется отдельный сценарий, создаётся интерфейс сравнения, определяется структура данных, пишется логика. После запуска выясняется, что функцией почти не пользуются или используют совсем не так, как предполагала команда.
Проблема здесь не в том, что гипотеза оказалась неверной. Ошибочные предположения неизбежны в продуктовой работе. Проблема возникает, если относительно дешёвую гипотезу можно было проверить раньше, но команда сразу выбрала наиболее дорогой способ проверки — полноценную разработку.
Перед стартом я поэтому советую выписать несколько наиболее важных предположений, на которых держится решение. Если одно из них окажется неверным, придётся ли существенно менять продукт? Если да, стоит подумать, можно ли получить дополнительные данные уже на прототипе.
Позднее исследование иногда превращается в подтверждение решения
Есть ещё один эффект, который я наблюдаю при работе с исследованиями. Чем больше ресурсов уже вложено в определённый вариант, тем сложнее команде объективно воспринимать данные, которые ему противоречат.
Когда функция существует только в прототипе, критический результат пользовательского теста воспринимается относительно спокойно: меняем решение и проверяем снова.
Когда над той же функцией несколько недель работали дизайнеры и разработчики, ситуация меняется. Появляется естественное желание объяснить негативные результаты особенностями выборки, неправильным использованием или тем, что пользователям просто нужно привыкнуть.
Поэтому исследование, проведённое слишком поздно, рискует превратиться из инструмента принятия решения в инструмент его подтверждения.
Это одна из причин, почему я предпочитаю формулировать исследовательский вопрос до получения данных. Команда должна заранее понимать, какой результат заставит её пересмотреть решение. Тогда интерпретировать результаты значительно проще.
Но исследовать заранее нужно не всё
Из сказанного легко сделать противоположный вывод: перед разработкой необходимо проверить каждое предположение. На практике это тоже дорого и неэффективно.
Я использую простой ориентир:
Если изменение можно быстро внести после запуска, а ошибка не блокирует пользователя, подробное исследование до разработки может стоить дороже самой потенциальной переделки.
Если же решение затрагивает основной сценарий, архитектуру, модель данных, оплату, регистрацию или другую сложную часть продукта, дополнительная проверка становится намного более оправданной.
Поэтому задача команды — не устранить всю неопределённость. Нужно правильно выбрать неопределённость, с которой допустимо идти в разработку.
Разработка тоже может быть способом проверки гипотезы
Иногда работающий продукт действительно необходим, чтобы получить достоверный ответ. Прототип не всегда позволяет проверить производительность, длительное использование, реальные платежи, взаимодействие с живыми данными или поведение пользователей спустя несколько недель.
В таком случае начинать разработку при наличии неопределённости вполне разумно.
Но важно назвать вещи своими именами: мы не считаем гипотезу подтверждённой — мы сознательно переходим к более дорогому этапу её проверки, потому что более дешёвого способа получить нужные данные недостаточно.
Такой подход меняет отношение к первой реализации. Вместо попытки сразу построить окончательную версию команда может ограничить объём разработки и быстрее получить данные, необходимые для следующего решения.
Цена раннего старта определяется не тем, что прототип был «недостаточно идеальным». Она появляется, когда дорогостоящие продуктовые вопросы остаются незамеченными или воспринимаются как уже решённые.
Поэтому перед передачей прототипа полезно провести ещё одну финальную проверку: какие вопросы действительно закрыты, какие риски команда принимает сознательно и что ещё способно заставить нас существенно изменить решение. Этому и будет посвящена следующая глава.
К моменту финальной проверки у команды обычно уже накоплено достаточно информации: есть прототип, результаты обсуждений, пользовательские наблюдения, технические комментарии и список решений, которые принимались по ходу работы. Теперь важно не провести ещё один большой этап согласования, а собрать всё это в один ответ: можем ли мы начинать разработку с приемлемым уровнем неопределённости?
Я не рекомендую превращать такую проверку в формальную приёмку, где готовность определяется количеством поставленных галочек. Один незакрытый вопрос иногда важнее двадцати выполненных пунктов.
Поэтому вместо длинного чек-листа я использую несколько направлений проверки.
Пользователь может пройти основной сценарий
Первое и самое очевидное условие: ключевой путь существует не только в голове команды.
Пользователь понимает, откуда его начать, какие действия выполнить и что произойдёт в результате. Если прототип тестировался, у нас есть не только внутреннее убеждение, но и наблюдения за тем, как представители аудитории справляются с задачей.
Особое внимание стоит уделить моментам выбора. Если в определённой точке пользователю предлагается несколько вариантов, должно быть понятно, чем они отличаются и к каким последствиям приводят.
При этом наличие небольших затруднений ещё не делает прототип неготовым. Важнее понять, мешают ли они достижению основной цели и насколько дорого будет исправить их позднее.
Команда знает, какие гипотезы остаются непроверенными
Мне кажется важным различать две ситуации: «мы этого не знаем» и «мы знаем, что этого пока не знаем».
Во втором случае неопределённостью уже можно управлять.
Например, команда понимает, что пока не знает, будут ли пользователи активно применять дополнительный фильтр. При этом его реализация относительно проста и не меняет основной сценарий. Такой риск вполне можно принять и проверить после запуска.
Совсем другая ситуация — неизвестно, понимают ли пользователи принцип выбора тарифа, а от него зависит структура оплаты и значительная часть интерфейса. Оставлять такую гипотезу без проверки намного опаснее.
Поэтому перед стартом разработки я рекомендую прямо сформулировать основные непроверенные предположения и для каждого определить последствия ошибки.
Уже одно это упражнение хорошо показывает, действительно ли прототип готов.
Основные состояния не требуют от разработчиков продуктовых решений
Следующий вопрос: что произойдёт за пределами идеального сценария?
Не обязательно заранее рисовать десятки вариантов каждого экрана. Но для важных действий должны быть определены хотя бы принципиальные состояния: успешное выполнение, ожидание, отсутствие данных, ошибка и невозможность совершить действие.
Если в процессе реализации разработчику приходится самостоятельно решать, что показать пользователю после ошибки или разрешить ли определённое действие, это уже не просто техническая деталь.
Особенно важно заранее разобраться с ситуациями, которые способны привести к потере данных, неправильному действию или тупику в пользовательском сценарии.
Техническая команда видела прототип до начала оценки работ
Передача готовых макетов разработчикам как финального документа — не самый удачный момент для первого технического обсуждения.
К этому времени полезно уже знать, существуют ли ограничения, способные изменить пользовательский опыт. Если разработка зависит от внешнего API, сложной обработки данных, специфической авторизации или других технических условий, эти вопросы должны быть хотя бы обозначены.
Я бы обязательно прошёл ключевые сценарии вместе с разработчиком до окончательной фиксации объёма работ. Иногда десятиминутное обсуждение обнаруживает предположение, которое дизайнер и продакт-менеджер просто не могли увидеть со своей стороны.
У исследования должна быть точка остановки
После первых тестов почти всегда хочется проверить ещё что-нибудь. Изменили формулировку — можно протестировать её. Перенесли кнопку — хорошо бы проверить снова. Появился новый комментарий — можно собрать дополнительную выборку.
Если не определить момент остановки, исследование легко превращается в бесконечную оптимизацию ещё не существующего продукта.
В своей работе я считаю достаточным основанием для движения дальше ситуацию, когда критические пользовательские сценарии понятны, повторяющиеся серьёзные проблемы устранены или осознанно приняты, а дополнительное исследование уже вряд ли изменит решение о базовой логике продукта.
После этого часть вопросов разумнее проверять на работающей версии.
Иногда начать разработку с риском — правильное решение
Готовность прототипа не означает отсутствие неизвестных.
Допустим, команда выбирает между двумя вариантами второстепенной функции. Оба понятны пользователям, техническая стоимость изменения невелика, а достоверные данные можно получить только после запуска. Продолжать исследование прототипа в такой ситуации необязательно.
Можно выбрать один вариант, зафиксировать гипотезу и заранее определить, какие данные после запуска помогут её проверить.
Это принципиально отличается от ситуации, когда команда просто игнорирует неопределённость. Здесь риск известен, оценён и принят сознательно.
Где заканчивается полезная проверка
Перед окончательной передачей прототипа я предлагаю задать команде несколько вопросов:
Это тот случай, когда небольшого списка достаточно. Его задача — не гарантировать отсутствие будущих изменений. Такой гарантии в продуктовой разработке всё равно не существует.
Задача финальной проверки — убедиться, что команда начинает разработку не потому, что «макеты закончились», а потому, что наиболее дорогая неопределённость уже снята или принята осознанно.
И если после этой проверки остаются вопросы, которые способны полностью изменить основной сценарий, я бы вернулся к прототипу. Если же оставшиеся неизвестные дешевле и точнее проверяются на работающем продукте, дальнейшая полировка макетов начинает приносить всё меньше пользы.
На этом этапе прототип действительно можно считать готовым к разработке.
Граница между прототипированием и разработкой редко бывает такой чёткой, как кажется в проектном плане. Нельзя определить готовность по количеству экранов, завершённости дизайн-системы или отсутствию комментариев в макетах.
Для меня гораздо более полезный критерий — уровень неопределённости, с которым команда переходит к реализации.
К этому моменту мы должны понимать, какую задачу решает пользователь, как он проходит основные сценарии и где может столкнуться с затруднениями. Важные продуктовые предположения должны быть либо проверены, либо явно зафиксированы как гипотезы, которые команда сознательно собирается проверять позднее.
То же относится к технической стороне. Разработчики не обязаны получить описание каждой мелочи, но они не должны самостоятельно придумывать продуктовую логику там, где прототип оставляет пробелы.
При этом я не считаю правильной целью стремление устранить все неизвестные до написания первой строки кода. Это невозможно и, скорее всего, экономически нецелесообразно. Некоторые ответы появляются только при использовании реального продукта: на настоящих данных, с реальной аудиторией и в течение достаточно длительного времени.
Поэтому перед стартом разработки полезнее задать другой вопрос: что произойдёт, если наше текущее предположение окажется неверным?
Если ответ — «изменим текст или небольшой элемент интерфейса», возможно, гипотезу вполне допустимо оставить до запуска. Если придётся перестраивать ключевой сценарий, менять модель данных или переделывать значительную часть уже реализованной функциональности, дополнительная проверка прототипа может оказаться гораздо дешевле.
Именно здесь исследования дают команде практическое преимущество. Их задача не в том, чтобы получить одобрение пользователей перед разработкой. Хорошее исследование помогает обнаружить расхождение между тем, как команда представляет поведение человека, и тем, что человек действительно делает.
Иногда для этого достаточно нескольких наблюдений за прохождением прототипа. Иногда нужны интервью. В других случаях качественные наблюдения стоит дополнить количественным опросом, чтобы проверить, насколько обнаруженная закономерность характерна для более широкой аудитории.
При этом метод исследования всегда должен следовать за вопросом, а не наоборот. Не стоит проводить опрос только потому, что его легко запустить, или организовывать интервью, если команде на самом деле нужно сравнить ответы большой группы пользователей.
Как сотрудник Тестографа, занимающийся анализом данных и методологией опросов, я особенно внимательно отношусь к моменту, когда исследование превращается в формальность. Если команда уже приняла решение и никакой результат не способен его изменить, сбор дополнительной обратной связи вряд ли принесёт пользу.
Гораздо продуктивнее проводить проверку тогда, когда пространство для решения ещё существует.
В результате хороший прототип перед разработкой — это не обязательно идеально отполированный макет. Это достаточно определённая модель будущего продукта, на которой команда уже проверила наиболее рискованные предположения, обнаружила критические проблемы и договорилась о поведении основных сценариев.
Разработка после этого всё равно принесёт новые вопросы. Пользователи всё равно найдут ситуации, которые команда не предусмотрела. Некоторые гипотезы всё равно окажутся ошибочными.
Разница в другом: наиболее дорогие ошибки мы постарались обнаружить тогда, когда для их исправления требовалось изменить прототип, а не готовый продукт.
Поэтому я бы определил момент готовности довольно просто: прототип можно передавать в разработку, когда оставшиеся неизвестные уже не являются случайными слепыми зонами, а представляют собой понятные и осознанно принятые риски.
В таком случае команда не пытается доказать, что придумала идеальное решение. Она делает более полезную вещь — начинает разработку, понимая, что уже известно, что ещё предстоит проверить и почему следующий этап действительно стоит начинать сейчас.