Дизайн
ТЗ на прототип: сценарии, исследование и критерии готовности
Как заказать прототип, который проверяет продуктовую гипотезу: сценарии, участники, реальные состояния, тестирование и передача в разработку.
Закажите проверку гипотезы, а не набор красивых экранов
Требования к прототипированию определяют, какое решение команда сможет принять до разработки. Интерактивный макет сам по себе не отвечает на вопрос, понятен ли продукт пользователю и выполним ли сценарий. Начните с неопределённости: человек не находит нужную услугу, путается в тарифах, не понимает следующий шаг или не может исправить ошибку. Запишите, что нужно наблюдать, чтобы подтвердить проблему и выбрать решение. Тогда количество экранов становится следствием задачи, а не единственным предметом договора.
Разделите три возможных результата: согласование структуры, проверку взаимодействия и передачу поведения разработчикам. Для структуры может хватить схемы и простых набросков. Для проверки сложного ввода потребуется интерактивность и реалистичные данные. Для передачи в разработку нужны состояния, правила переходов и описание ограничений. Не требуйте одинаковой детализации для всех целей: дорогая визуальная полировка ранней гипотезы затрудняет изменения, а слишком условный макет не позволяет проверить поведение, зависящее от реального ввода.
В руководстве GOV.UK о прототипах различаются подходы от бумажных набросков до кода; кодовый вариант помогает воспроизвести реалистичное взаимодействие. Это не означает, что любой проект обязательно начинать с программирования. В брифе укажите, какое свойство необходимо проверить и почему выбранного уровня точности достаточно. Отдельно зафиксируйте, что прототип не является готовым рабочим сервисом. Его успешная демонстрация не подтверждает безопасность, производительность, интеграции и надёжность будущего продукта.
Опишите людей и условия использования
Сегменты участников должны различаться поведением, влияющим на сценарий. Для личного кабинета важны новый и постоянный покупатель, человек с одним заказом и с несколькими, пользователь телефона и сотрудник с рабочего компьютера. Возраст сам по себе редко объясняет проблему навигации. Приложите реальные задачи, частоту использования, ограничения устройства и доступную информацию. Если гипотеза касается специалиста, не заменяйте его случайным знакомым только ради удобства набора участников и быстрого завершения проверки.
Для каждого сценария задайте исходное состояние. Пользователь уже авторизован или впервые пришёл по ссылке? У него есть номер заказа, документ, фотография или только общее описание задачи? Какие сведения он помнит, а какие может найти отдельно? Эти детали влияют на результат сильнее, чем декоративная точность карточки. Условие «введите код» выглядит простым, пока не выясняется, что человек не понимает, откуда код должен прийти и можно ли вернуться к предыдущему действию.
Опишите контекст проверки: спокойная встреча, короткое действие на ходу, слабая связь, ограниченное время или использование вспомогательных технологий. Не следует искусственно усложнять все сценарии, но важные реальные ограничения необходимо воспроизвести. Если продукт предназначен для мобильной работы, проверка только на большом мониторе не даёт достаточных оснований для вывода. Сохраните перечень условий, которые не удалось проверить, чтобы команда не распространяла результат на ситуации, отсутствовавшие в исследовании.
Соберите сценарии с альтернативами и ошибками
Начните с одного полного пути от потребности до наблюдаемого результата. Например, покупатель находит прошлый заказ, выбирает нужный товар и понимает, можно ли повторить покупку. Затем добавьте развилки: товар отсутствует, адрес изменился, цена стала другой, в заказе несколько отправлений. Такой учебный пример показывает, почему прототип нельзя ограничить последовательностью идеальных экранов. Пользователь должен видеть последствия выбора и возможность исправить действие, иначе проверяется только умение нажимать подсвеченные кнопки.
Для каждой развилки укажите, что известно системе и что необходимо уточнить у человека. Не задавайте повторно вопрос, ответ на который уже есть в предыдущем шаге. Определите состояние после возврата назад: сохраняются ли введённые данные, сбрасывается ли фильтр, остаётся ли выбранный объект. Эти правила часто пропускают в кликабельном макете, а разработчики принимают решения уже во время реализации. Бриф должен выделять такие места как обязательные для согласования, даже если они не требуют отдельного красивого экрана.
Включите пустое состояние, загрузку, ошибку и недостаток прав там, где они влияют на путь. Прототип может имитировать эти ситуации, но участник должен понимать происходящее без пояснения модератора. Вместо общего сообщения «что-то пошло не так» проверьте понятный следующий шаг: повторить безопасный запрос, сохранить черновик или обратиться к сотруднику. Не обещайте в макете действие, которое будущая система технически не поддерживает, пока это ограничение не обсуждено с разработчиком.
Согласуйте содержание и уровень реалистичности
Используйте правдоподобные, но обезличенные данные. Длинные названия, разные суммы, похожие позиции и неполные описания обнаруживают проблемы, которые скрывает идеальный демонстрационный набор. Для таблицы нужны не только три аккуратные строки, но и случаи, влияющие на сортировку и выбор. При этом не переносите личную переписку клиентов в общедоступный файл прототипа. Подготовьте безопасные примеры заранее и сохраните объяснение, какие свойства реальных данных они воспроизводят.
Тексты кнопок и ошибок входят в проверяемое поведение. «Продолжить», «Сохранить» и «Отправить» обозначают разные последствия. Если нажатие создаёт обязательство, передаёт заявку или меняет данные, участник должен это понимать. В брифе перечислите формулировки, которые требуют согласования владельца процесса. Не оставляйте ключевые места заполнителями: пользователь не сможет оценить непонятный тариф или состав услуги, если вместо них стоят случайные слова. Декоративный контент допустим только там, где он не влияет на решение.
Зафиксируйте, какие элементы существующей дизайн-системы используются без изменения. Размеры кнопок, поля, типографика и состояния должны соответствовать продукту, если задача касается его развития. Новый визуальный стиль может исказить проверку: люди реагируют на непривычное оформление вместо исследуемого поведения. При создании нового продукта сначала согласуйте достаточный набор компонентов, а не весь брендбук. Прототип должен быть достаточно правдоподобным для задачи, сохраняя возможность быстро и недорого менять спорное решение.
Подготовьте исследование без подсказок в задании
Задание участнику описывает жизненную цель, а не маршрут по интерфейсу. «Найдите документы по последнему заказу» полезнее инструкции «откройте вкладку заказы и нажмите документы». Во втором случае проверяется выполнение команды модератора. Руководство GOV.UK по модерируемому тестированию предлагает наблюдать, как люди выполняют задачи, и исследовать возникающие трудности. В собственном плане заранее определите, когда модератор может помочь и как эта помощь будет отражена в результатах, чтобы не считать подсказанный путь самостоятельным успехом.
Согласуйте критерии наблюдения: завершение задачи, неверный выбор, возвраты, необходимость помощи и понимание результата. Время выполнения полезно только вместе с контекстом. Человек может действовать быстро, но ошибиться в заказе, или медленнее, потому что внимательно проверяет важную информацию. Не сводите вывод к одному среднему числу. Сохраняйте конкретное действие, место затруднения и объяснение участника. Оценка «нравится» дополняет наблюдение, но не заменяет доказательство, что нужная задача выполнена правильно.
Количество участников выбирайте под разнообразие сценариев и риск решения, а не по универсальной формуле. Небольшая качественная проверка помогает обнаружить проблемы, но не доказывает точную долю пользователей с каждой трудностью. Если нужно сравнить варианты количественно, заранее обсудите метод и достаточность выборки. В отчёте разделите наблюдаемое и предполагаемое: «три участника не заметили действие» является фактом этой сессии, а «большинство клиентов не увидит кнопку» требует дополнительных оснований.
Сделайте результаты пригодными для решения
Каждое замечание должно содержать сценарий, наблюдение, последствие и предложенное изменение. «Навигация неудобная» слишком широко. «Участник открыл архив вместо действующего заказа, потому что не заметил дату» позволяет обсудить конкретную правку. Приложите фрагмент записи или обезличенный скриншот, если это разрешено условиями исследования. Не превращайте отчёт в коллекцию цитат без анализа: команда должна понимать, какие проблемы препятствуют задаче и какие свидетельства поддерживают выбранный приоритет.
Разделите изменения на необходимые до разработки, требующие дополнительной проверки и косметические. Ошибка, из-за которой человек выбирает чужой объект или неверно понимает платёж, имеет другое значение, чем предпочтение оттенка кнопки. Для каждого решения назначьте владельца и срок. Если проблема остаётся открытой, она должна быть видна в передаче. Нельзя считать сценарий согласованным только потому, что обсуждение закончилось и файл получил статус «финальный» без проверки внесённых изменений.
Повторная проверка должна отвечать на исходный вопрос. После изменения навигации предложите участнику аналогичную задачу с другими данными, чтобы снизить влияние запомненного пути. Не обязательно заново исследовать каждую неизменившуюся часть продукта; выберите затронутые сценарии и связанные развилки. Запишите версию прототипа, состав участников и условия. Тогда команда сможет отличить улучшение решения от различий в заданиях или подготовленности людей, участвовавших в двух последовательных раундах исследования.
Передайте разработчикам поведение и ограничения
Комплект передачи включает карту сценариев, редактируемый файл, перечень компонентов, состояния и правила переходов. Для каждого важного поля нужны ограничения ввода и последствия ошибки. Для асинхронного действия — ожидание, успех, отказ и повтор. Если прототип использует заранее подготовленный ответ, пометьте это явно. Разработчик должен видеть, где показана реальная логика, а где только визуальная имитация. Иначе удобная демонстрационная условность незаметно превратится в неподтверждённое обещание будущего продукта.
Обсудите техническую осуществимость до утверждения сложного сценария. Нужные данные могут отсутствовать в API, обновляться с задержкой или требовать отдельного разрешения. Не нужно проектировать всю архитектуру ради прототипа, но ключевые зависимости следует проверить. В реестре ограничений укажите источник, владельца уточнения и влияние на интерфейс. Если мгновенное подтверждение невозможно, прототип должен честно показывать ожидание, а не рисовать завершение операции, которое система пока не умеет достоверно определить.
Определите, какие материалы входят в передачу прав и сопровождение. Нужны доступ к исходнику, перечень используемых шрифтов и изображений, согласованный формат экспорта и история ключевых решений. Если файл остаётся только в личном аккаунте исполнителя, дальнейшая работа зависит от его доступности. Приложите короткую инструкцию: как открыть сценарий, какие данные использовать и какие области не проверялись. Это сокращает повторные вопросы и позволяет новой команде продолжить работу без реконструкции смысла по картинкам.
Примите прототип по исходным вопросам
На приёмке вернитесь к гипотезам из начала брифа. Для каждой должно быть решение: подтверждена, опровергнута или данных недостаточно. Последний вариант допустим и полезен, если описан следующий шаг. Прототипирование снижает неопределённость, но не обязано доказывать успех любой первоначальной идеи. Отказ от неработающего сценария до разработки может быть правильным результатом. Важно, чтобы он основывался на наблюдении и ограничениях, а не на личных предпочтениях самого громкого участника обсуждения.
Проверьте файл на устройствах, для которых он предназначен, и убедитесь, что ссылки открываются у принимающей стороны. Сценарии должны стартовать из понятного состояния, а ошибки переходов не мешать воспроизвести результаты исследования. Сверьте список передаваемых материалов с договорённостью. Неработающая ссылка на прототип или отсутствие редактируемого исходника — конкретный дефект поставки, даже если презентация прошла удачно и изображения экранов выглядят аккуратно. Передача должна позволять независимо повторить согласованные проверки.
Заполняемый бриф в источниках статьи помогает связать гипотезу, аудиторию, сценарий, наблюдение и решение. Приложите к нему примеры реальных задач и ограничения будущей реализации. Такой документ полезнее требования «нарисовать двадцать экранов», потому что объясняет назначение каждого результата. После приёмки у команды остаётся проверенная основа для разработки и список оставшихся вопросов. Это даёт возможность оценивать следующий этап по понятному объёму, сохраняя различие между изученным поведением и ещё непроверенными предположениями.
Источники
- Making prototypes
GOV.UK Service Manual / доступ 2026-10-18
Первичный источник для соответствующих принципов и технических свойств. Структура требований и учебные примеры подготовлены редакцией; конкретная конфигурация проверяется отдельно.
- Using moderated usability testing
GOV.UK Service Manual / доступ 2026-10-18
Первичный источник для соответствующих принципов и технических свойств. Структура требований и учебные примеры подготовлены редакцией; конкретная конфигурация проверяется отдельно.
- Скачать заполняемый бриф / ТЗ (.txt)
Малевич — практическое приложение / доступ 2026-10-18
Сохраните файл и заполните данные проекта, открытые решения и критерии приёмки.
FAQ
Обязательно ли делать прототип визуально похожим на готовый продукт?
Нет. Детализация зависит от проверяемого вопроса. Для структуры может хватить простого сценария, а для восприятия содержания или мобильного взаимодействия понадобятся реалистичные данные и состояния.
Сколько экранов нужно указать в ТЗ на прототип?
Лучше зафиксировать сценарии и состояния, а затем оценить необходимые экраны. Число макетов само по себе не показывает, можно ли проверить отказ, ошибку, возврат и завершение задачи.
Что считается результатом проверки прототипа?
Наблюдения о действиях участников, выявленные затруднения, подтверждённые и неподтверждённые предположения, а также решения о дальнейших изменениях. Одобрение внешнего вида не заменяет проверку выполнения задачи.
