Существует множество статей и вдохновляющих видео о прототипировании продуктов. Сделал, показал аудитории, исправил ошибки. В этом идеальном мире приложения и макеты проходят итерацию за итерацией, отбрасывая лишнее и становясь лучше. В реальности все работает немного не так. Олег Левчук, продуктовый менеджер Яндекс.Карт, рассказывает о прототипировании в полевых условиях, объясняет, каких ошибок оно позволяет избежать, и делится опытом создания прототипов, которые действительно помогут сделать продукт лучше.

Cтолкновение с реальностью

Если вы смотрели видео или читали статьи о разработке и прототипировании, то уже слышали о триаде «make,show,learn» — «сделал, показал, вынес уроки» . После просмотра такого вдохновляющее видео вы закрываете ноутбук и говорите: «Я жил неправильно, теперь я буду все прототипировать» .

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

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

Или вы сделали прототип и ждете обратную связь, а мнения настолько разные (одним нравится все, другими ничего), что извлечь урок решительно невозможно. Сюрпризы поджидают и на этапе работы над ошибками. Пока вы думаете, какие гипотезы еще попробовать, к вам приходит начальник и говорит: «Все должно быть сделано через два месяца». В такой момент у команды наступает всеобъемлющий learn, и вы с воодушевлением приступаете к работе, забыв о прототипах.

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

В основе прототипирования лежит осознание, что на вашу работу нужно взглянуть со стороны 

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

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

Облекайте идеи в видимую форму

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

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

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

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

Моя цепочка прототипирования выглядит так: идея — предмет — кликабельный макет — живые данные — эксперимент.

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

На каждом этапе можно увидеть ошибки и не тащить их за собой вплоть до разработки.

Не спешите доверять результатам тестирования

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

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

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

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

Смотрите видео-лекции Академии Яндекса на Youtube.