Тихий скетчинг: как за одну встречу найти решение по продукту
Материал руководителя по мобильным продуктам «Сбербанка» для юридических лиц Кирилла Гурбанова.
В избранное
В избранном
Одним из самых неожиданных профессиональных открытий 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, но для повседневных продуктовых задач подходит вариант с короткими итерациями, о котором я рассказал выше.
#дизайн #разработка
© vc.ru
