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

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

В человекоцентричном дизайне работа строится как цикл:
изучение контекста использования → определение пользовательских требований → создание дизайн-решений → оценка решений → следующая итерация.

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

Lean UX строится вокруг короткого цикла:
сделать допущения → создать MVP → провести эксперимент → получить обратную связь и новое знание → уточнить допущения.

Здесь MVP – не обязательно полноценный минимальный продукт. Это может быть любая достаточно простая реализация идеи, которая позволяет проверить важное предположение.
Lean UX предполагает:

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

Роль Lean UX – снижать риски до того, как команда вложит значительные ресурсы в разработку.
Он позволяет:

• раньше отбрасывать нежизнеспособные идеи;
• получать proof of concept – подтверждение принципиальной работоспособности концепции;
• получать раннюю обратную связь;
• вносить изменения до полноценного запуска.

Adidas Go – пример того, как прототипирование помогает определить механику продукта до окончательной реализации.

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

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

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

Поэтому техники прототипирования позволяют:

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

Один из основных способов такой проверки – Wizard of Oz.

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

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

Интерфейсом может быть:

• веб-сайт;
• приложение;
• Telegram- или Facebook-бот;
• почтовая рассылка;
• сочетание нескольких каналов.

Людьми можно временно заменить:

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

В эксперименте IBM 1983 года участники диктовали письма якобы голосовому помощнику.

В действительности же ситуация была такой:

• звук с микрофона передавался оператору в другом помещении;
• оператор вручную записывал слова;
• результат возвращался пользователю так, будто его создала система.

Участник исследования не знал о существовании оператора. Это позволяло изучать работу будущего голосового интерфейса до появления полноценной технологии.

На раннем этапе Zappos не требовалась полноценная инфраструктура интернет-магазина.

Основное предположение было гораздо проще:
будут ли люди вообще покупать обувь через интернет без примерки до покупки?
Прототип позволил проверить именно это допущение. В результате команда получила реальные данные о поведении пользователей и подтверждение концепции для инвесторов.

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

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

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

Тест показал:

• положительную реакцию на саму идею;
• пользователи не поняли, что бот работает вручную;
• при этом они жаловались на скорость его ответов;
• команда смогла уточнить и доработать логику будущего продукта.

«Эхо» – концепция приложения для нетоксичной эмоциональной поддержки.
В качестве прототипа использовался Telegram-бот. Исследование длилось неделю, в нём участвовали 25 человек. В ходе теста команда также меняла систему уведомлений.

В результате:

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

Метод требует сопровождения прототипа в реальном времени и поэтому плохо масштабируется.

Основные ограничения:

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

Поэтому Wizard of Oz особенно полезен, когда нужно оценить конкретную продуктовую гипотезу, а не подробно разобраться в пользовательском опыте.

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

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

Консьерж может:

• информировать;
• консультировать;
• помогать;
• менять стратегию взаимодействия по ходу исследования.

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

Консьержский подход можно сочетать с частично работающей системой.
В одном из примеров продукт должен был анализировать дизайн-макеты с помощью LLM и выдавать рекомендации на основе юзабилити-эвристик.

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

Поэтому процесс упростили:

• пользователи вручную отправляли ссылки на макеты;
• команда самостоятельно загружала их в систему;
• получала рекомендации от LLM;
• выгружала результат;
• вручную отправляла его пользователям.
• Таким образом можно тестировать полезность результата, не создавая полноценную техническую инфраструктуру.

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

Участники:

• использовали приложение для измерения физического стресса;
• проходили тест на психологический стресс;
• ежедневно получали одну или несколько техник борьбы со стрессом через личный Telegram-чат;
• в конце дня отвечали на вопросы и давали обратную связь.

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

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

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

Иногда никакой интерфейс вообще не нужен.

В примере Open Snow ценностью продукта является точный прогноз погоды для лыжных курортов.

Вместо создания приложения команда могла сначала вручную:

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

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

Консьержский подход не полностью воспроизводит будущий продукт.

Основные ограничения:

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

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

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

Wizard of Oz, наоборот, стремится максимально имитировать будущий сервис.
Он:

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

Условное обозначение:
Консьерж → понять и сформировать решение.
Wizard of Oz → проверить уже сформулированное решение.

Не всегда необходимо создавать работающий прототип.
Идею можно исследовать через сценарий использования.

В таком исследовании:

1. пользователю показывают сценарий работы будущего решения;
2. его просят сопоставить сценарий со своим опытом;
3. пользователь последовательно комментирует каждую часть;
4. оценивает, насколько ситуация соответствует его реальной жизни;
5. рассказывает о собственных обстоятельствах;
6. критикует идею и делится впечатлениями.

Сценарий может существовать в разных формах:

• текст;
• storyboard;
• lo-fi-прототип;
• последовательность экранов;
• визуальная история.

Результатом становится не просто оценка «нравится / не нравится».

Метод позволяет:

• оценить problem-solution match – соответствует ли решение реальной проблеме;
• обнаружить неизвестные ранее особенности контекста;
• выявить потребности, которые сами пользователи могли раньше не осознавать.

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

Ранжирование идей – групповой метод для сравнения нескольких продуктовых концепций.

Участникам показывают несколько низкодетализированных идей.
После этого они:

• последовательно реагируют на каждую;
• дают оценки;
• комментируют;
• обсуждают идеи друг с другом.
• В конце каждый участник ранжирует варианты от наиболее понравившегося к наименее понравившемуся.

Ранжирование помогает:

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

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

Методы проверки продуктовых идей.

Проверка идеи через имитацию реального использования
Здесь пользователь фактически получает услугу, но её реализация сильно упрощена:

• Wizard of Oz;
• консьержское исследование.

Главный вопрос:
будет ли сама идея работать в реальном взаимодействии?

Обсуждение идеи через артефакт
Пользователь ещё не получает полноценную услугу, а обсуждает её представление:

• совместное прохождение сценариев;
• ранжирование идей;
• lo-fi-прототипы;
• текстовые концепты.

Главный вопрос:
как пользователь понимает и оценивает предполагаемое решение?

Самый простой прототип может вообще не содержать интерфейса.

Можно:

1. описать новый продукт текстом;
2. дать респонденту описание;
3. проверить, правильно ли он понял идею;
4. попросить оценить её.

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

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

Их задача – не выглядеть как финальный продукт, а дать пользователю возможность:

• взаимодействовать с формой;
• выполнить действие;
• оценить принцип работы.

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

В исследовании бытовых практик участники несколько недель пользовались Thermomix – непривычным устройством, требующим изменения привычного процесса приготовления еды.

Они:

• пользовались устройством;
• вели дневники;
• участвовали в интервью.

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

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

Такой исследовательский прототип может:

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

Он создаётся только для изучения новой идеи и после исследования может полностью выбрасываться – это throwaway prototype.
Пример: приложение messageProbe для исследования общения членов семьи, живущих в разных местах. Оно позволяло оставлять сообщения друг другу на общей онлайн-доске.
Целью был не запуск самого messageProbe, а изучение того, как новые технологии могут встроиться в семейное общение.

Не существует универсального прототипа.
Форма прототипирования зависит от того, какое именно неизвестное нужно проверить.

Соответствие вопросов методам:
Будут ли люди пользоваться сервисом?
→ Wizard of Oz.
Какой именно сервис им нужен?
→ консьержское исследование.
Вписывается ли решение в реальную жизнь?
→ совместное прохождение сценариев.
Какая из нескольких идей кажется привлекательнее?
→ ранжирование идей.
Понятна ли вообще концепция?
→ текстовое описание или lo-fi-прототип.
Как люди ведут себя в определённой практике?
→ исследовательский или физический прототип.

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