Время чтения: 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

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

Исследования design fixation показывают, что увиденный пример действительно способен ограничивать поиск решения. В классических экспериментах Дэвида Янссона и Стивена Смита участники продолжали воспроизводить свойства показанных им образцов даже тогда, когда эти свойства были неудачными или прямо противоречили условиям задачи. Авторы назвали это design fixation — фиксацией на уже доступной идее.

Но отсюда не следует, что референсы вредны. Более поздний метаанализ 43 исследований обнаружил гораздо интереснее устроенную картину: примеры действительно уменьшают разнообразие направлений поиска, но одновременно могут повышать качество и новизну отдельных решений. Особенно полезными оказались немногочисленные и необычные примеры.

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

Разница находится в способе его использования.

Ошибка начинается с вопроса «что здесь можно взять?»

Обычная работа с референсом часто начинается визуально.

Нравится сетка. Интересный градиент. Хорошая типографика. Необычно расположена фотография. Можно попробовать похожее.

В этот момент дизайнер уже находится внутри решения другого человека.

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

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

Виноват здесь не тренд как таковой.

Виноват уровень, на котором был прочитан референс.

Мы увидели форму, но не выяснили, почему она появилась.

Полезный референс нужно разбирать назад

Первый шаг метода — мысленно отменить готовое решение.

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

Не нужно спрашивать:

Как здесь использована большая фотография?

Нужно двигаться назад:

Какую проблему решает большая фотография?

Возможно, продукт трудно объяснить словами.

Возможно, его ценность эмоциональна.

Возможно, бренд продаёт материал, фактуру или статус.

Возможно, пользователю важно сначала захотеть объект, а уже потом изучать характеристики.

Тогда референсом становится уже не фотография во весь экран.

Референсом становится принцип:

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

Этот принцип можно перенести куда угодно.

В упаковку.

В выставочное пространство.

В каталог.

В интерфейс.

В видеоролик.

Форма исчезла, а знание осталось.

От поверхности к механизму

Для каждого референса полезно пройти три уровня.

Первый — что я вижу.

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

Второй — что это делает.

Создаёт паузу. Усиливает иерархию. Заставляет задержаться. Уменьшает количество конкурирующих объектов. Помогает сравнить варианты.

Третий — зачем это понадобилось именно здесь.

Какое ограничение, пользовательская задача или позиция бренда породили такое решение?

На третьем уровне референс перестаёт быть картинкой и превращается в знание.

И именно этот уровень стоит переносить в другой проект.

Хороший референс часто находится не в вашей категории

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

Это полезно для изучения нормы.

Но плохо для поиска нового решения.

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

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

Нужно показать сложную иерархию?

Посмотрите не только корпоративные сайты, но и аэропортовую навигацию.

Нужно объяснить долгий процесс?

Посмотрите музейную экспозицию или инструкцию по сборке.

Нужно дать человеку ощущение контроля над сложной системой?

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

Нужно показать изменение во времени?

Посмотрите карты метро разных лет, погодные системы, биржевые графики, спортивную статистику.

Внешне эти объекты могут не иметь ничего общего с вашей задачей.

Но структурно они могут решать ту же проблему.

Это и есть сильный референс.

Собирать нужно не картинки, а причины

Обычная moodboard содержит изображения.

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

Не:

нравится композиция.

А:

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

Не:

хороший минимализм.

А:

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

Не:

интересная типографика.

А:

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

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

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

Механизм забывается гораздо реже.

Один референс опаснее пяти разных

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

Исследования примеров в дизайн-процессе подтверждают, что увиденные решения увеличивают вероятность появления связанных с ними элементов в собственных идеях. При этом разнообразие предложений может снижаться.

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

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

Не для того, чтобы смешать стили.

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

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

Если мы смотрим только на один — перед нами появляется шаблон.

Референсы лучше собирать до формы

Есть ещё одна важная вещь — момент, когда начинается поиск.

Если открыть Pinterest раньше, чем сформулирована задача, платформа охотно предоставит задачу вместе с ответом.

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

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

Для работы с референсами это особенно полезно.

Сначала сформулировать:

что должно измениться у пользователя;

какое противоречие нужно разрешить;

какое ограничение нельзя нарушить;

какое качество решения наиболее важно.

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

Тогда мы ищем не «красивые сайты».

Мы ищем способы справиться с конкретной задачей.

Метод четырёх вопросов

Практически всю работу с референсом можно свести к четырём вопросам.

Что здесь работает?

Не что нравится, а что выполняет функцию.

Почему это работает именно здесь?

Контекст, аудитория, задача, ограничение.

Какой принцип стоит за решением?

Убрать конкретную форму и сформулировать механизм.

Как этот же принцип можно реализовать иначе?

Вот здесь начинается собственный дизайн.

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

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

Принцип — не «горизонтальная карусель».

Принцип:

дать возможность быстро сравнивать множество равноправных объектов, сохраняя текущий контекст.

Теперь решение снова открыто.

Это может быть карусель.

Таблица.

Карта.

Стена изображений.

Фильтр.

Сравнение по параметрам.

Даже разговор с агентом.

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

Отдельно нужно искать анти-референсы

Обычно коллекции состоят только из того, что нравится.

Это ошибка.

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

И обязательно подписывать почему.

Слишком большая свобода выбора.

Слишком много движения.

Форма конкурирует с содержанием.

Эффектный экран разрушает скорость выполнения операции.

Информация раскрывается слишком поздно.

Красота требует от пользователя лишнего действия.

Анти-референс формирует границу проекта.

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

После референсов нужно остаться одному

Есть простой этап, который часто пропускают.

Закрыть референсы.

Не держать Figma рядом с Pinterest, Behance и десятком вкладок.

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

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

Референс должен помочь сформировать внутреннюю модель задачи, а затем временно исчезнуть.

После появления собственного направления к нему можно вернуться и проверить результат.

Но последовательность важна:

сначала понять → потом закрыть → затем проектировать.

ИИ делает этот метод ещё важнее

Генеративные системы резко увеличили доступность референсов.

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

Проблема фиксации от этого не исчезает.

Она ускоряется.

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

Поэтому при работе с ИИ особенно важно разделять генерацию формы и исследование принципов.

Иногда лучший следующий запрос к модели — не:

сделай ещё пять вариантов,

а:

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

Сначала направления.

Потом изображения.

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

Референс должен увеличивать свободу

Это, пожалуй, главный критерий.

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

После плохой работы с референсом остаётся одно:

хочется сделать примерно так же.

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

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

Референс становится инструментом мышления только в тот момент, когда перестаёт диктовать форму.

Источники

David G. Jansson, Steven M. Smith — Design Fixation. Design Studies, 1991. Классическое экспериментальное исследование фиксации на показанном решении.
Design Fixation — ScienceDirect

Ut Na Sio, Kenneth Kotovsky, Jonathan Cagan — Fixation or inspiration? A meta-analytic review of the role of examples on design processes. Design Studies, 2015. Метаанализ 43 исследований о влиянии примеров на разнообразие, новизну и качество решений.
Fixation or inspiration? — ScienceDirect

Linden J. Ball, Bo T. Christensen — Analogical reasoning and mental simulation in design. Design Studies, 2009. Исследование использования аналогий и переноса решений между областями.
Analogical reasoning and mental simulation in design

Özgü Özkan, Fehmi Dogan — Cognitive strategies of analogical reasoning in design. Design Studies, 2013. Сравнение способов использования аналогий дизайнерами разного уровня опыта.
Cognitive strategies of analogical reasoning in design

IDEO — Design Thinking Process. Практический процесс исследования, синтеза, генерации идей, прототипирования и тестирования.
IDEO Design Thinking Process