В прошлом году я прочитал книгу «Спринт. Как разработать и протестировать новый продукт всего за пять дней». Это книга-методичка, в которой описывается быстрый и проверенный формат тестирования идей — дизайн-спринт. Авторы рекомендуют выбирать рискованные и дорогие в разработке гипотезы, которые могут быть потенциально перспективными.
Захотелось попробовать этот фреймворк, но в продуктовой разработке подобные задачи попадаются довольно редко. И когда подходящая идея у нас появилась, я предложил проверить её способом, описанным в книге. Это был двойной эксперимент: с одной стороны, возможность протестировать формат дизайн-спринта и понять, можно ли его использовать для наших гипотез, с другой — проверить саму гипотезу.
В статье фокусируюсь на самом подходе и расскажу, как мы проводили эксперимент, о наших впечатлениях, инсайтах и ошибках. Поделюсь выводами, насколько фреймворк хорош для быстрого тестирования идей в продуктовой компании.
Подготовительный этап
Авторы пишут, что перед началом дизайн-спринта нужно сформулировать идею, собрать команду, определить время и место.
Идея
Выбирать что-то онлайн — дело не быстрое, особенно если впервые сталкиваешься с интерфейсом продукта. Ещё дольше приходится выбирать что-то, когда людей много: надо договариваться, учитывать предпочтения друг друга.
Пицца — продукт, который часто заказывают на компанию и по какому-то поводу: день рождения, корпоратив и другие праздники. А значит, помимо еды людям надо позаботиться о создании определённой атмосферы. Так у нас появилась идея создать предложение «под ключ»: готовый набор еды на компанию с сопутствующими товарами, которые можно выгодно купить в одном месте.
Мы захотели проверить, есть ли смысл предлагать готовый набор еды на компанию с сопутствующими товарами, которые можно выгодно купить в одном месте.
Адаптация процесса и планирование
В первый день авторы предлагают определить долгосрочную цель и вопросы для спринта, создать карту на маркерной доске и собрать мнения экспертов. Второй и третий следует посвятить наброску и выбору решений. В четвёртый день составляется прототип решения, и пятый остаётся для проведения интервью с потенциальными потребителями и его анализа.
Тут наша задача усложнилась, потому что пяти дней у нас тоже не было. Наша People&Process lead Мария Кручинина буквально за день прочитала книгу и помогла адаптировать под нас весь процесс, сократив его до трёх дней. Для максимально глубокого погружения договорились о жёстком правиле не отвлекаться ни на какие гаджеты и другие задачи и три дня работать офлайн в одной переговорке.
Команда
Чтобы провести этот сложный эксперимент, нужна мотивированная, компактная и кросс-функциональная команда. В ней должно быть достаточное количество заряженных идей людей с разными и необходимыми компетенциями. Авторы книги рекомендуют собирать команду из 7 человек.
Нас было шестеро:
модератор/фасилитатор,
«десайдер» (принимает финальное решение),
эксперт по клиентскому опыту,
маркетолог,
аналитик,
дизайнер.
Можно было бы добавить ещё кого-нибудь (например, эксперта по финансам или разработчика), но мы не стали.
Главная ценность такого разношёрстного состава команды – возможность посмотреть на проблему и решение с разных сторон. Определённо, каждый из нас смог внести своё видение и своей вклад в эксперимент. Но это потребовало времени и некоторых усилий.
День первый
Кто мы?
В таком составе команда ещё никогда не работала — некоторые вообще видели друг друга впервые. Поэтому начали с лёгкого «разогрева» (ice breaking), чтобы лучше познакомиться и сблизиться. Формат может быть любой, лишь бы помогал всем участникам расслабиться и чувствовать себя комфортно. Мы, например, рассказывали, в чём наша суперсила и какую пользу каждый из нас принесёт в этом трёхдневном спринте.
Чего мы хотим?
С единым контекстом вышла неувязочка. Как оказалось, каждый по-своему понимал суть проблемы и возможное решение.
Чтобы выровнять общий контекст, задали себе вопрос: «Какую долгосрочную цель мы ставим в рамках нашего спринта?». Важно, чтобы цель была именно долгосрочной и мотивирующей.
Когда сформулировали общую цель, составили список вопросов, на которые хотелось бы ответить к концу третьего дня. Их получилось целых 8 и, конечно же, все они казались очень важными.
Но это ловушка. На самом деле достаточно сфокусироваться на трёх-четырёх главных вопросах. В этом и есть прелесть этого фреймворка: он постоянно сужает выбор и фокусирует. Для этого у каждого в команде есть голос, а у дейсадера всегда в два раза больше голосов. Такой механизм позволяет не застревать на мелочах — он напомнил мне принцип Парето. Я, кстати, перечитал все вопросы, от которых мы в итоге отказались, и вижу, что мы действительно не потеряли ничего супер важного.
За время нашего эксперимента нас неоднократно заносило в сторону от основной идеи, а порой возникали серьёзные разногласия. На помощь всегда приходил артефакт, который мы получили в конце первого дня
На этом этапе складывается ощущение, что этого достаточно и можно начинать креативить, но авторы предлагают взглянуть на проблему ещё с одной стороны — экспертной.
Знаете, мы и сами своего рода эксперты
Команда «спринтеров» закрывает разные экспертизы и это позволяет подсветить проблемы с разных сторон. Но даже их компетенций может быть недостаточно.
Тут в книге предлагают перед началом активной работы над идеей провести интервью с «экспертами». Это люди, которые могут знать какие-то тонкости в контексте задачи. Например, стейкхолдер или руководитель направления. Чем сложнее идея, тем более нестандартные эксперты могут понадобиться.
Мы никого не звали, чтобы сэкономить время. К тому же наша идея была довольно понятной и в команде хватало знаний по теме, поэтому мы сами и выступили «экспертами». Внешние эксперты для нашей задачи дали бы не так много ценности, как могли бы дать для другой.
Чтобы «говорить на одном языке», мы визуализировали карту пути клиента — верхнеуровневые этапы, которые будут проходить наши будущие респонденты на тесте. Этапы надо сокращать, пока их не останется 3-4. Это нужно для фокуса, так как на проверку множества сценариев времени просто не хватит.
Сам спросил — сам ответил
Процесс выглядит просто: эксперты по очереди выходят и, глядя на карту, рассказывают всё, что знают по проблеме спринта. Остальные могут что-то уточнять по ходу. Чтобы было легче рассказывать, вывешиваются 5-6 общих вопросов, которые могут помочь с повествованием, например: «Что уже было реализовано раньше?».
В процессе рассказа слушатели фиксируют заметки в формате «как мы можем» (КММ). Это любопытный подход, который переворачивает все проблемы, упомянутые экспертом, в формулировку вопроса. Например, эксперт по дизайну говорит, что часто новую функциональность просто не видят. Тогда вопрос в формате КММ будет выглядеть так: «Как мы можем сделать, чтобы пользователи обратили внимание на новую функциональность?». После всех интервью участники показывают друг другу вопросы в формате КММ, группируют повторы и голосуют за ключевые. Финалистов добавляют на карту пути клиента рядом с соответствующим этапом.
Остаётся финальный штрих. Глядя на все артефакты (цель, вопросы и риски), десайдер формулирует критерии успешности теста. Всё , к концу первого дня у нас есть исчерпывающая информация на оставшиеся дни.
День второй
«Я художник, я так вижу»
Под конец первого дня у нас было верхнеуровневое понимание пути клиента при взаимодействии с будущим прототипом. Получилось два крупных блока: базовые настройки и кастомизация. Теперь каждому нужно было сделать презентацию с примерами реализации подобных шагов в других продуктах, не обязательно связанных с заказом еды.
Всё, что мы нашли по этой теме, использовали для вдохновения и в начале второго дня поделились друг с другом. Во время рассказов делали быстрые зарисовки удачных решений, чтобы всё было на виду.
Следующие два часа каждый работал самостоятельно, но в едином ритме. Мы проделали несколько креативных упражнений, чтобы в итоге получить скетч-раскадровку своего решения. Например, в одном из заданий нужно было за 8 минут нарисовать 8 вариантов идеи. Поскольку времени на детальную проработку нет, мозг может выдать нестандартные решения.
Все 8 итоговых рисунков мы анонимно развесили на стене и молча рассматривали каждый вариант, отмечая понравившиеся детали решения. Затем модератор пытался описать, как он понимает суть нарисованного, а в конце рассказа автор решения мог дополнить. Такая «секретность» позволила избежать предвзятости.
В конце дня нас ожидала, как оказалось, самая сложная часть — договориться, как будет выглядеть итоговый эскиз, по которому на следующий день будет собираться прототип. Мы долго спорили, не всем нравился итоговый вариант, приходилось несколько раз прерываться. Нарисовать финальный прототип во многом удалось потому, что мы ещё раз обратилась к долгосрочной цели и вопросам спринта — без них могли бы ещё долго спорить.
За последний час совместно нарисовали на стене дизайн прототипа и, ужасно уставшие, разошлись по домам в предвкушении последнего дня.
День третий
Красивые — налево, умные — направо
Последний день мы начали с определения ролей и очерчивания фронта работ. У нас получилось два больших блока: разработка прототипа и дизайн самого эксперимента. В каждом из блоков было много своих мелких подзадач, предстояло продумать всё до мелочей. Команды разошлись по разным комнатам и начали творить. После обеда мы наметили чекпойнт, чтобы свериться, что каждая из групп идёт в нужном направлении.
Разработка прототипа
В группе «разработчиков» главная роль была у дизайнера. Он собирал в Фигме кликабельный прототип эскиза, который мы вместе нарисовали день назад на стене. Другим ребятам нужно было решить, какие сценарии анимировать, а какие оставлять статичными. Под каждый интерактивный сценарий команда определяла логику и создавала контент (картинки, описания, копирайт). Через час стало понятно, что заложить в «Фигме» все сценарии будет очень долго и мы не успеем. Посмотрев в очередной раз на нашу долгосрочную цель, мы решили упростить прототип, отрезав большой кусок. Эту часть придётся проверять статично.
Тут стоит отметить, в чём разница статичных и анимированных частей прототипа. Поскольку «спринт» предполагает быструю проверку идеи, то большинство функционала не должно работать. Если клиент нажимает на неработающий (статичный) элемент интерфейса, то его надо спросить, что он хотел сделать и какой результат ожидал получить, а после этого сказать, какой результат он получил бы по задумке разработчика. Сценарий, который проверяет основную гипотезу, нужно делать анимированным, чтобы клиент почувствовал «магию» от решения.
Кстати, именно в этот день мы полноценно почувствовали силу кросс-функциональной команды. Ребята воспользовались своими маркетинговыми и бизнес-скиллами, чтобы прототип получился правдоподобным по составу и цене продуктов.
Пока часть команды занималась разработкой прототипа, остальные занялись дизайном самого теста. Сначала описали формат исследования, затем провалились в детали.
Подготовка исследования
У нас было 5 групп респондентов, от 3 до 8 человек в каждой. Мы решили, что сможем вести два потока групп параллельно (по 3 члена нашей команды на каждую группу), а потом все вместе возьмём самую многочисленную компанию.
В каждой мини-команде был один интервьюер (тот, кто будет проводить тест) и 2 наблюдателя (те, кто будет записывать всё, что говорят респонденты).
Исследование строили так: сначала группе надо будет сделать заказ на свою компанию по новому прототипу, потом то же самое — в текущем приложении Додо Пиццы. После этого мы зададим вопросы про опыт заказа и отпустим респондентов есть пиццу.
Кстати, перед началом теста мы хотели погрузить ребят в максимально реальную обстановку заказа — даже говорили, что им надо будет сейчас самим оплачивать свой заказ и ждать, пока курьер привезёт пиццу.
По итогам теста нам нужно сделать вывод об успешности нашей идеи готовых наборов на компанию. Для этого мы сформулировали критерии успешности для каждой гипотезы спринта и написали вопросы для интервьюера, ответы на которые помогли бы нам с выводами. Чтобы ведущему исследования было проще, подготовили сценарий проведения теста.
Для наблюдателей мы сделали фреймы в Миро, чтобы записывать комментарии по ходу теста. Задача наблюдателей была записывать максимально точно, буквально до цитат респондентов. Впоследствии эти записи предстояло структурировать.
Отдельно продумали, как будет устроена техническая часть. Интервьюер запускал видеозвонок со своего телефона, шарил экран и запускал запись, наблюдатели подключались к звонку со своих ноутбуков, чтобы видеть, как респонденты взаимодействуют с прототипом, параллельно вели заметки в Миро.
На словах всё звучало довольно просто — на деле, конечно же, многое пошло не так.
Планировать – хорошо
Когда прототип и дизайн исследования были готовы, мы решили устроить генеральный прогон. Для этого написали в офисный чат и пригласили поучаствовать добровольцев в репетиции нашего теста.
По ходу прогона вскрылись откровенные проблемы: где-то скрипт интервью был немного кривой, где-то было недостаточно правдоподобности, где-то не хватало вопросов. Да и в целом всем участникам команды стало понятнее, как лучше строить беседу с группой. Зато с технической стороны всё было хорошо. В общем, прогон — это обязательный пункт, очень прибавляет уверенности.
В хорошем настроении, мы взяли часик отдыха и стали ждать, когда придут реальные участники теста. Ну а дальше мы столкнулись с реальностью.
Подстраиваться под ситуацию — ещё лучше!
Респондентов мы собирали в офисе. За пару минут до начала пришёл всего один человек. Мы поняли, что наш тайминг поедет, потому что делать интервью короче не имеет смысла, так как это скажется на качестве исследования. Проблема была в том, что у нас был довольно плотный тайминг и после первых групп должны были прийти следующие компании. Причём, скорее всего, голодные, так как мы звали их заказать пиццу. И длительная задержка могла повлиять на их настрой.
Также между группами мы хотели сделать короткое обсуждение результатов друг с другом, но из-за задержки пришлось отказаться от этого. Поэтому до самого конца исследования мы не знали, у кого как идут дела.
Ещё в процессе оказалось, что очень многое зависит от настроя группы. Какие-то компании почувствовали себя подопытными и вели себя не совсем естественно, а кому-то, наоборот, удалось максимально расслабиться, что позволило нам наблюдать за людьми в подходящей среде.
К 10 вечера мы встретились друг с другом и по горячим следам обменялись экспресс-фидбэком по процессу. Ну а после, уставшие, но довольные, отправились по домам переваривать результаты.
Выводы
Нам удалось сжать срок до 3 дней вместо 5 и пройти по ключевым этапам фреймворка, описанного в книге. Этого времени хватило, чтобы покреативить, но и в космос не улететь. Фокусирующие вопросы помогали договариваться и продвигаться к цели.
Получилось собрать настоящую кросс-функциональную команду и сработаться. Сейчас даже есть ощущение, что следующий эксперимент таким составом получилось бы организовать ещё круче. Думаю, что во многом это произошло из-за полностью офлайн-формата и полной вовлечённости с 10 до 18 (окей, в последний день до самой ночи).
Но и нюансы свои тоже есть. Важно, чтобы каждый участник спринта верил в идею, которая будет проверяться. Мы столкнулись с тем, что один из нас был недостаточно замотивирован, из-за чего не раскрыл весь свой потенциал и превратился больше просто в исполнителя.
Изначальную гипотезу подтвердить не удалось, но мы получили много информации для других гипотез и исследований. А если бы пошли с этой идей сразу в разработку, то даже по самым приблизительным расчётам потратили бы в 5 раз больше денег и в 10 раз больше времени.
Само исследование надо строить по-другому, в два этапа: сначала на текущем варианте, потом, после фидбэка клиентов, делать и показывать новый.
10 инсайтов, чтобы дизайн-спринт удался
Начинать готовиться в первый раз надо хотя бы за пару недель.
Не смешивать два теста в одном. Мы тестировали текущий функционал и новый. Правильнее было бы разнести на два исследования: сначала протестировать проблему, потом — решение.
Не смешивать две гипотезы. Мы хотели и готовые решения потестировать, и дополнительные продукты под ситуации клиентов. В итоге вторую гипотезу не получилось нормально проверить.
Равномерно распределять нагрузку. В первый день у нас осталось много сил, а в третий — наоборот.
Сам тест на клиентах лучше планировать на отдельный день.
Закладывать время на задержки. У нас поехал тайминг исследования и мы не смогли обмениваться впечатлениями между тестами.
Стоит лучше настраивать респондентов как до самого теста, так и создавать атмосферу во время.
Иметь пул реальных клиентов, которых можно звать на такие тесты. У нас было мало времени на подготовку и мы звали своих знакомых, это могло исказить результат исследования.
Стараться сделать хорошо главный сценарий. Лучше пользоваться не Фигмой, а другими no code инструментами или даже разработчика привлечь на один день. Чем более сырой прототип показывается, тем более отдалённый от реальности опыт получает клиент, что влияет на фидбэк.
Все участники должны верить в идею — это важно для успеха команды в спринте.
Полезные ссылки: