Старайтесь не придумывать новые идеи, обходитесь теми, что уже имеются.

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

На маркерной доске должны быть отражены все необходимые детали, чтобы в четверг при создании прототипа никто не задавал вопросов типа: «А что дальше?» или «Что происходит в данный момент?». Но при этом постарайтесь не перегружать сториборд деталями. Не нужно стремиться сделать каждый «кадр» идеальным и проработать все до одного мелкие нюансы. Достаточно сказать себе: «Тот, кто будет завтра создавать прототип, сам решит, как это сделать» – и двигаться вперед.

Заполнение сториборда может оказаться непростым делом, поскольку в первой половине дня вы и так уже приняли целую серию решений, израсходовав на это массу энергии. Чтобы облегчить себе задачу, почаще просите Распорядителя принимать необходимые по ходу заполнения сториборда тактические решения. В «спринте», проводившемся в компании Slack, роль «Художника» исполнял Брейден, однако окончательные решения принимала Мёрси. И пусть для нее это было дополнительной нагрузкой, зато все происходило быстро и без излишних колебаний.

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

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

Убедитесь, что ваш прототип можно протестировать за 15 минут. Может показаться, что этого очень мало, особенно если учесть, что при тестировании интервью с каждым потенциальным потребителем продолжается 60 минут. Но вы должны дать участникам возможность порассуждать вслух и ответить на ваши вопросы (не говоря уже о времени, которое понадобится в начале интервью для вводных замечаний и в конце – для подведения итогов). В общем, в действительности 15 минут – это не 15 минут, а больше. Есть и еще одно практическое соображение, почему необходимо установить именно такой лимит. Когда время ограничено, вы вынуждены фокусироваться на наиболее существенных аспектах итогового решения – и не включать в него больше элементов, чем сможете реализовать в прототипе (как показывает опыт, каждый «кадр» сториборда эквивалентен примерно одной минуте при тестировании).