Тихий скетчинг

Работа Product Manager подразумевает постоянную генерацию решений. Когда выявлена проблема целевой аудитории, и перед будущим продуктом (либо его частью) поставлена цель, наступает время придумать такую реализацию, которая эту проблему для пользователя успешно решит.

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

1.Коллективное обсуждение. Участники собираются в переговорке, кто-то один выходит к маркерной доске, и начинается обсуждение:

— А что бы мы хотели сделать?
— Я предлагаю, чтобы пользователь точно мог логиниться через соцсети!
— Обязательно нужно спрашивать телефон!
— Давайте сделаем классные анимации!

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

Частый сценарий: 2/3 встречи уходят на обсуждение 25% задуманного. Затем все понимают, что прошло много времени, и ничего не сделано, и «экспрессом» пробегают оставшиеся кейсы, глубоко в них не погружаясь.

Такой подход не эффективен, потому что, во-первых, получается неравномерная глубина проработки задачи (от начала встречи к концу), и во-вторых, он отнимает уйму времени.

Кроме того, низкая эффективность мозговых штурмов и групповых совещаний доказана научно. Еще в 1958 году ученые из Йельского университета провели серию экспериментов, которая показала, что количество и качество идей, достигнутых путем «брейншторма», ниже, чем если бы люди думали по-одиночке.

2.Делегирование. Задача отдается дизайнеру, который сразу отрисовывает ее в UI, основываясь на тех данных, которые у него есть.

Далее PO принимает работу, «полностью доверяя профессионалу», и задача уходит в разработку.

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

Тихий скетчинг

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

Суть метода в том, чтобы объяснив команде задачу, попросить всех потратить 5-10 минут на скетчинг — простые наброски будущего решения на бумагу.

Процесс проходит циклически в 1-2 круга.

Шаг 1. 7-15 мин. Объяснить команде цель и задачи, которые решаются продуктом.

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

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

Шаг 2. 5-10 мин. Скетчинг.

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

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

Скетчем может быть как один экран интерфейса сайта/приложения, так и их последовательность. Здесь нет никаких рамок, наоборот — чем менее будет ограничен участник, тем более креативные решения можно будет получить на выходе.

Через 10 минут у каждого члена команды будет лежать несколько листочков бумаги с его вариантом решения.

Шаг 3. 5-10 мин. Презентации.

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

После рассказа участники могут в течение еще 1-2 минут позадавать вопросы. Важно: это не критика или обсуждение, это лишь наводящие вопросы, чтобы все смогли лучше понять замысел автора решения.

После того как все участники рассказали о своих решениях, проводится еще один раунд скетчинга.

Шаг 4. 5-10 мин. Скетчинг (раунд 2).

Все повторяется, только теперь участники уже видели предложения коллег, подчерпнули здравые мысли и усовершенствуют свои варианты. Кто-то может сделать полностью новый вариант — это не страшно.

Шаг 5. 5-10 мин. Презентации (раунд 2).

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

Шаг 6. 7-10 минут.

Выработка единой концепции. Фасилитатор, стоя у доски, рисует целевой вариант решения, который основан на всех состоявшихся обсуждениях. Как правило, этот этап проходит быстро и без долгих дискуссий, т.к. все вопросы уже были сняты перед этим.

Члены команды могут активно комментировать — это только помогает процессу.

Шаг 7. Финиш.

Спустя всего 1-2 часа команды есть хорошо проработанный UX будущего решения. В нем учтены мнения и опыт нескольких профессионалов.

Если предмет встречи — крупный кусок функционала или полностью новый продукт, то я обычно убираю 2-й раунд скетчинга и презентаций. Так удается за 2 часа проработать 3-4 больших самостоятельных части продукта.

Шаги 8,9… Прототипирование и тестирование.

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

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

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

Подход «тихого скетчинга» можно использовать в любых продуктовых задачах, и не только в ИТ-продуктах. Команда GV консультирует десятки портфельных компаний, которые создают в том числе роботов, кофейни, магазины и т.п. И везде применяет одну и ту же методологию — SPRINT, частью которого является скетчинг.

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

А как вы генерите решения?

P.S. Авторы SPRINT называют методологию «Working alone together» и рекомендуют тратить на скетчинг несколько часов. Это приемлемо в рамках работы по SPRINT, но для повседневных продуктовых задач подходит вариант с короткими итерациями, о котором я рассказал выше.