Тихий скетчинг: как за одну встречу найти решение по продукту

Материал руководителя по мобильным продуктам «Сбербанка» для юридических лиц Кирилла Гурбанова.

Одним из самых неожиданных профессиональных открытий 2017 года для меня стала техника «тихого скетчинга» для решения продуктовых задач. Сначала я подсмотрел её на конференции Mind The Product London во время одного из воркшопов, а затем нашёл её упоминание в книге Sprint от Google Ventures.

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

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

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

— А что бы мы хотели сделать?

— Я предлагаю, чтобы пользователь точно мог регистрироваться через соцсети.

— Обязательно нужно спрашивать телефон.

— Давайте сделаем классные анимации.

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

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

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

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

Задача отдаётся дизайнеру, который сразу отрисовывает её в интерфейсе, основываясь на тех данных, которые у него есть.

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

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

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

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

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

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

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

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

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

Шаг второй: 5-10 минут. Скетчинг.

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

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

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

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

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

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

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

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

Шаг четвёртый: 5-10 минут. Скетчинг (второй раунд).

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

Шаг пятый: 5-10 минут. Презентации (второй раунд).

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

Шаг шестой: 7-10 минут. Выработка единой концепции.

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

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

Шаг седьмой: Финиш.

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

Восьмой и девятый шаги: Прототипирование и тестирование.

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

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

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

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

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

#дизайн #разработка