Прототип — это вопрос, а не уменьшенная версия продукта

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

Время чтения: 7–8 минут

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

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

Хорошее прототипирование начинается не с Figma и даже не с идеи того, что нужно построить. Оно начинается с формулировки неизвестного.

Прототип не обязан изображать весь продукт

Одна из самых полезных работ о прототипировании появилась ещё в 1997 году. Стефани Хоуд и Чарльз Хилл в статье What Do Prototypes Prototype? предложили отказаться от классификации прототипов главным образом по их внешней законченности и вместо этого спрашивать, какую часть проектируемой системы конкретный прототип исследует. Они выделяли три направления: роль продукта в жизни пользователя, его внешний вид и взаимодействие, а также способ технической реализации.

Это различие до сих пор полезнее привычной шкалы low fidelity — high fidelity. Бумажный лист может оказаться очень точным прототипом определённой идеи, а сложная интерактивная модель — плохим прототипом, если непонятно, какое предположение она проверяет.

Предположим, команда проектирует сервис совместного планирования поездок. Необязательно сразу моделировать весь путь от регистрации до оплаты. Если главное неизвестное звучит как «смогут ли несколько человек договориться о варианте без отдельного чата?», можно проверить только механизм коллективного выбора. Всё остальное пока не имеет значения.

Прототип становится меньше, но эксперимент — точнее.

Чем больше прототип, тем больше вопросов он задаёт одновременно

Представим полноценный кликабельный интерфейс нового сервиса. Пользователь запутался и не завершил задачу. Почему?

Он не понял терминологию? Не заметил кнопку? Не доверяет самой идее сервиса? Ему не подходит предложенный сценарий? Структура информации слишком сложна? Или интерфейс просто выглядел настолько незавершённым, что человек не понял, как к нему относиться?

Чем больше переменных одновременно помещено в прототип, тем сложнее интерпретировать результат тестирования.

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

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

Это сдвигает главный вопрос с «что нам прототипировать?» на «что нам сейчас неизвестно?»

Начинать стоит с самого опасного предположения

В проекте почти всегда существует множество неизвестных, но они неодинаково важны.

Можно не знать, какой способ фильтрации удобнее, но это сравнительно локальная проблема. Гораздо опаснее не знать, нужен ли пользователю сам сценарий, вокруг которого строится продукт.

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

Допустим, создаётся сервис, который автоматически составляет дизайнеру подборку референсов. Можно долго тестировать карточки, фильтры и способы сохранения. Но если дизайнеры в реальной работе не доверяют автоматически сформированной подборке и всё равно предпочитают самостоятельно искать источники, интерфейсные улучшения ничего не спасут.

В таком случае первый прототип может вообще не быть интерфейсом. Можно вручную собрать подборку так, будто её создал алгоритм, передать дизайнеру и посмотреть, использует ли он её в работе.

Технически системы ещё нет.

Но главное предположение уже проверяется.

Иногда лучший прототип — это подделка

В дизайне существует полезный соблазн: сначала сделать вещь настоящей, а затем проверить.

Прототипирование позволяет поменять порядок.

Если нужно понять, будет ли человек пользоваться новой услугой, не всегда требуется сначала строить услугу. Иногда достаточно создать ситуацию, в которой человек считает, что она уже существует.

Так работают сценарные прототипы, Wizard of Oz и разные формы service prototyping: часть системы временно выполняется человеком вручную, хотя пользователь взаимодействует с ней как с работающим сервисом.

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

Stanford d.school прямо предлагает использовать «no-build» прототипы, когда создание сложной технологии мешает быстро проверить саму идею. Главное — создать достаточный контекст, чтобы человек мог действовать и реагировать, а команда получила новое знание.

Такой прототип иногда выглядит почти несерьёзно. Но если он отвечает на важный вопрос, он профессиональнее красивого интерфейса, который ничего не проверяет.

Детализация должна соответствовать вопросу

High fidelity часто воспринимается как естественная следующая ступень качества. Чем ближе прототип к продукту, тем вроде бы он лучше.

На практике высокая детализация нужна только тогда, когда предметом проверки действительно является деталь.

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

Nielsen Norman Group рекомендует проводить тестирование уже на ранних стадиях и постепенно повышать точность прототипа по мере развития решения. Причина практическая: если пользовательские исследования отложить до почти завершённой реализации, обнаруженные структурные проблемы становятся значительно дороже в исправлении.

Получается простой принцип:

Не больше.

Лишняя детализация тоже имеет цену.

Красивый прототип сложнее разрушить

У высокой проработки есть ещё одна проблема, уже психологическая.

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

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

Прототипирование работает лучше, когда ошибка остаётся дешёвой.

Stanford d.school подчёркивает ценность быстрого воплощения идей именно потому, что ранняя материализация позволяет обнаружить предположения тогда, когда ещё есть возможность легко изменить направление.

Поэтому грубость раннего прототипа иногда является не недостатком, а защитным механизмом. Она напоминает всей команде: это ещё не решение, это инструмент исследования решения.

Один прототип — один главный вопрос

Практически метод можно начать с одной строки:

После такой формулировки становится намного легче решить, что именно нужно создавать.

Если мы проверяем понимание структуры, прототип должен позволять навигацию.

Если доверие — необходимо достаточно реалистично показать контекст и последствия действия.

Если читаемость упаковки — возможно, понадобится физический объект на реальной полке.

Если саму ценность идеи — интерфейс вообще может оказаться лишним.

Прототип следует за вопросом, а не наоборот.

Потом нужно заранее определить, что будет считаться ответом

Есть ещё один шаг, который часто пропускают.

Команда формулирует гипотезу, проводит тестирование, получает много комментариев и затем начинает интерпретировать их в пользу понравившегося решения.

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

Если проверяем понятность структуры, недостаточно спросить пользователя: «Вам всё понятно?» Нужно дать задачу и наблюдать, может ли он выполнить её без помощи.

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

Прототип ценен тем, что позволяет изучать действие, а не только мнение о возможном действии.

Именно поэтому прототипирование тесно связано с наблюдением.

Не все вопросы нужно задавать пользователю

Есть опасность превратить любой проект в бесконечное пользовательское тестирование.

Но некоторые неизвестные относятся не к пользователю.

Можно прототипировать технологическую реализуемость, организационный процесс, взаимодействие подразделений, производство физического объекта или экономику услуги.

Модель Хоуд и Хилла хороша именно тем, что не сводит прототип только к UI. Прототип может изучать роль будущего решения, его взаимодействие с человеком или техническую реализацию.

Иногда критический вопрос звучит:

Или:

Или:

Все эти вопросы требуют прототипов, хотя пользовательский интерфейс может вообще не участвовать.

Прототип должен уменьшать неопределённость

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

После тестирования команда должна знать что-то, чего не знала раньше.

Не обязательно получить подтверждение идеи. Хороший прототип вполне может закончиться выводом:

Более того, это часто один из самых ценных результатов, если ошибка обнаружена за два дня, а не после шести месяцев разработки.

IDEO в своём современном описании design thinking разделяет создание материальных версий идеи и последующее тестирование именно как способ быстро увидеть, как идея ведёт себя в реальности, получить обратную связь и уточнить направление.

Поэтому количество созданных прототипов само по себе ничего не означает. Важнее другое: сколько неопределённости исчезло после каждого из них.

ИИ делает плохое прототипирование особенно убедительным

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

Для прототипирования это огромная возможность.

И одновременно ловушка.

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

В результате появляется новая форма прежней ошибки: визуальная убедительность начинает подменять доказательство жизнеспособности.

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

Поэтому при работе с генеративными инструментами вопрос «что именно мы сейчас хотим узнать?» становится важнее, а не менее важным.

Скорость создания прототипа не освобождает от метода.

Она делает отсутствие метода быстрее.

Прототип заканчивается не демонстрацией, а решением

После теста должен произойти переход.

Продолжаем.

Меняем направление.

Упрощаем.

Разделяем одну идею на две.

Проверяем следующий риск.

Или закрываем концепцию полностью.

Stanford d.school описывает прототипирование как последовательность экспериментов: сформулировать идею, воплотить её, получить данные, осмыслить результат и принять следующее решение.

Это важное отличие прототипа от презентационного макета.

Презентация стремится убедить.

Прототип должен позволять сомневаться.

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

И возможно, именно поэтому самая полезная формулировка прототипа удивительно проста:

Источники

Stephanie Houde, Charles Hill — What Do Prototypes Prototype? Handbook of Human-Computer Interaction, 1997. Классическая работа о прототипах как инструментах исследования разных аспектов проектируемой системы.
https://doi.org/10.1016/B978-044481862-1/50082-0

Stanford d.school — Experiment Expedition. Метод построения прототипа вокруг конкретного предположения, проведения эксперимента, сбора данных и принятия следующего решения.
https://dschool.stanford.edu/tools/experiment-expedition

Stanford d.school — The No-Build Hack. Метод использования простых сценарных прототипов для проверки идеи без предварительного создания сложной технологии.
https://dschool.stanford.edu/tools/no-build-hack

Stanford d.school — Why do building, sharing, and testing a work in progress help you get to a good solution? Материал о прототипировании как способе обнаружения предположений и раннего получения обратной связи.
https://dlibrary.stanford.edu/questions/why-does-building-and-testing-prototypes-help-you-get-to-a-good-solution

Nielsen Norman Group — Usability 101: Introduction to Usability. Рекомендации начинать пользовательское тестирование рано и повышать точность прототипов постепенно, вместо проверки уже практически реализованного продукта.
https://www.nngroup.com/articles/usability-101-introduction-to-usability/

IDEO — Design Thinking Process. Современное описание последовательности исследования, материализации идей и тестирования как способа обучения на реальном взаимодействии.
https://designthinking.ideo.com/process