«Выхлопом дизайн-мышления спокойно могло быть ничего». Как ZEO Lab искали идею для продукта

Меня зовут Наташа Никитюк. Мне, как и любому продакт-менеджеру, интересно, как в Украине придумывают и тестируют разные продукты — особенно ориентированные на зарубежные рынки.
О подходе design thinking (дизайн-мышление), который позволяет это сделать, написано очень много. Но применяя этот подход в реальном бизнесе, сталкиваешься с вопросами, на которые нет ответа в Google.
В октябре 2017 года компания ZEO Alliance совместно с Yes&Design открыли в Киеве ZEO Lab — центр создания идей и прототипов новых IТ-продуктов по методике Design Thinking. Команда проекта получила задачу, над которой работала в течение следующих 6 месяцев.
Одним из участников был Богдан Нановский. Он прошел с командой ZEO Lab все 5 этапов design thinking: empathy, defining, ideation, prototyping, testing. Сейчас Богдан занимается развитием FigLeaf — продукта ZEO Alliance, созданного, в том числе, по результатам этого полугодичного эксперимента.
Я поговорила с ним о том, как проходил проект: от обучения команды до оформления результатов.

Зачем запустили проект и как собирали команду

Изначально ZEO Lab появился как research-проект. В то время перед ZEO Alliance стояла задача по развитию существующего продукта — антивирусного приложения MacKeeper. А топ-менеджмент ZEO как раз увлекся фреймворком design thinking.
Этот подход активно используют в работе мировые компании: IBM, General Electric, Samsung, Facebook, Google, P&G. Но в Украине о нем тогда почти не знали — ровно до того момента, пока ZEO не начал его промоутировать, набирая себе команду под новый проект: ездили в Харьков, Днепр, Одессу. Но в итоге почти вся команда получилась из Киева.
Изначально команда должна была состоять из 6 человек: дизайнер, продакт-менеджер, два девелопера, аналитик и маркетолог. В результате их вышло 8 — взяли еще одного продакта и специалиста по социальным исследованиям.

Тимбилдинг и обучение

Перед началом работы ребята из ZEO Lab не были знакомы. Поэтому вместо стандартного onboarding-процесса к формированию команды подошли серьезнее. Первый рабочий день прошел вне офиса ZEO за командопостроением.

Процесс тимбилдинга включал в себя:

1. Упражнения, позволяющие открыться и сблизиться. «Например, мы должны были рассказать про три события из жизни, которые сформировали нас как личностей. Доходило до слез: у кого-то умерла бабушка, у кого-то погиб близкий человек. Закончилось все тем, что мы сидели коленка к коленке. Со стороны это выглядело как какая-то секта, но было круто», — вспоминает Богдан Нановский.
2. Check-in/check-out. Суть check-in в том, что каждый день по приходу на работу нужно рассказывать, как у вас дела. Check-out — то же самое, только перед уходом домой. Если кого-то нет в офисе — его набирают по телефону или Skype. Это не стендап — вы не говорите о работе. Только о своем состоянии и настроении.
«От check-out мы в итоге отказались — они отнимают много времени. А вот check-in оставили — это реально офигенный инструмент, — говорит Богдан. — Ты приходишь в 11 утра, рассказываешь, как у тебя дела, слушаешь остальных и сразу понимаешь, кого сегодня не напрягать».
Одним из этапов отбора в Zeo Lab был двухдневный воркшоп, где смоделировали все 5 фаз, существующих во фреймворке (тематика не была связана с реальной задачей). Поэтому с понятием design thinking все были знакомы.

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

«Весь design thinking базируется на челлендже. Ты не приходишь делать что-то — ты приходишь решать проблему, — объясняет Нановский. — Наш челлендж звучал так: как мы можем помочь людям адаптировать технологии? На этом вводные на работу команды из 8 человек на ближайшие полгода заканчивались».

Подготовку к работе вели в двух направлениях:

1. Дизайн-спринты — те же 5 этапов design thinking, но осуществляемые за 5 дней.
2. Изучение проблемы — в рамках общей темы команда исследовала существующие проблемы.

Помимо прочего, на протяжении всего проекта команду сопровождали внешние консультанты. Они помогали команде с теоретической частью и поясняли различные методики перед началом каждого этапа design thinking. Процесс обучения был беспрерывным — все 6 месяцев проекта.

Первый этап — эмпатия (empathy)

Этап эмпатии — это общение с конечным потребителем, попытка проникнуться его проблемой, прочувствовать его опыт и осознать его мотивацию.
Целевая аудитория ZEO Lab находилась не в Украине — в основном это США, Канада и Великобритания. Поэтому к глубинным интервью готовились в 2 раза тщательнее. Команда разбилась по парам и начала готовиться к поездке.

Поиск реcпондентов

«Находясь в Украине, нужно было найти иностранцев, которые согласятся пустить тебя к себе домой и провести 4 часа, отвечая на твои вопросы. Мы платили им за это, но опыт какой-то стремный: прилетают какие-то люди из Украины, что-то от тебя хотят, спрашивают что-то про технологии», — рассказывает Богдан Нановский.
Процесс поиска респондентов состоял из таких элементов:

• Отбор по социально-демографическим критериям — решили ориентироваться на образованных, семейных, обеспеченных людей любого возраста. В том числе охватили детскую аудиторию, поскольку планировали создать продукт на года — спустя какое-то время дети подросли бы и тоже начали пользоваться нашим продуктом.
• Сетап кампании — в случае ZEO Lab это был в основном Facebook, потому что там легко настраивать таргетинг. Также мы пробовали использовать Couchsurfing и Craigslist, но эти каналы не сработали.
• Мотивация респондентов — оплата интервью. Сумма зависела от того, проводили ли интервью дома у респондента и можно ли было пообщаться с его семьей.
• Скрининг — нужно было прозвонить потенциальных респондентов, чтобы убедиться, что человек адекватный. Социально ожидаемые ответы, люди, которые целенаправленно зарабатывают деньги с помощью таких программ — таких претендентов отсекали.

Разработка вопросов для интервью

Речь не о скрипте разговора, а о проработке разогревающих (warming up) вопросов, отстраненных тем, которые можно обсудить (small talks) и вопросов, которые интересовали нас непосредственно в рамках проекта. Ребята знали, как начнут беседу, как подойдут к теме технологий и о чем им нужно поговорить.

Тренировки в Киеве

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

Интервьюирование

План был такой: за полторы недели нужно было провести 30 интервью в 4 городах (Лондон, Торонто, Нью-Йорк, Сан-Франциско). В конце ноября 2017 все разбились по парам и разъехались.

Правило #1. Проводить интервью вдвоем

Правило основано на вполне очевидных причинах:

• Безопасность.
• Один человек интервьюирует, второй — делает заметки на ноутбуке.
• Второй человек также постоянно подключается к интервью, если понимает, что первый что-то упустил.

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

Правило #2. Желательно проводить интервью дома

На это тоже есть несколько причин:

• Люди часто говорят одно, а делают другое. Богдан и другие участники убедились в этом на практике: «Один из первых вопросов был “Какие девайсы вы используете?”. Люди стандартно называли мобильный телефон, ноутбук и, может быть, что-то третье. А начинаешь вертеть головой по сторонам — у человека тут “Алекса”, тут плазма 70 дюймов, тут какой-то DVD-шник. И ты такой: стоп, а вот это что? И он: ну, да, я не знал, что это вас интересует».
• В домашней обстановке респонденты чувствуют себя более открыто. Богдан рассказывает, с чего начинались их интервью: «Прежде чем перейти к главной теме, мы их разогревали: шутили, рассказывали об Украине, интересовались их хобби. В итоге, к основной части интервью мы походили спустя минут 40 общения. К этому моменту мы успевали подружиться с ними».

Правило #3. Больше практики

Есть несколько правил, которые помогут провести качественное интервью:

• Правило «5 почему» — спрашивать «почему» 5 раз подряд, пока не узнаете настоящую мотивацию человека.
• Не «фреймить» — не задавать рамки и не подсказывать возможные ответы. Лучше просто слушать, что скажет сам респондент.
• Добиваться ответа, уточнять, просить навести примеры.
• Не делиться собственным мнением.

Интервью проводили в несколько волн (по 2-4 интервью в каждой). После первой волны все синхронизировались и делились инсайтами. Мы начали понимать, что никакой проблемы с адаптацией технологий нет. Зато появлялись другие инсайты, которые повторялись от города к городу. Так ребята начали что-то нащупывать.
После синхронизации команда разработала новые вопросы для интервью — во время второй волны они продолжали общаться об адаптации технологий, но говорили уже на специфические темы, которые их интересовали. После второй серии интервью пары вернулись в Киев.

Второй этап — определение проблемы (defining)

Команда привезла около 30 интервью. Каждое из них длилось 3-4 часа, в сумме — больше 100 часов записи. К каждому интервью были заметки. Кроме того, пары коротко записывали на диктофон, кто что запомнил. Но этого все равно оказалось мало.
Помимо необходимости обработать весь массив информации, нужно было вложить этот массив остальным участникам команды, чтобы они почувствовали, будто сами проводили это интервью.

Третий этап — создание идеи (ideation)

После недельного перерыва команда начала исследовать выбранные темы — проводили research в Google, смотрели статистику и изучали все, что можно было найти. Для каждой темы делали большие борды в RealtimeBoard (сейчас — Miro) — добавляли кучу стикеров, цитаты с Amazon, любые статьи, исследования, статистику.
Дальше нужно было придумать, как решать боли из интервью и проблемы, которые обнаружили через интернет-research. Мы использовали разные методики ideation — от обычного брейншторминга до генерации идей под ограничениями (например, как бы вы решили эту проблему, если бы у вас был всего $1, или если бы вы жили в 2200 году).
Правил на этом этапе всего два:

• Не критиковать идеи (стараться не делать этого даже «про себя»).
• «Надстраивать» — один участник озвучивает идею, остальные дополняют.

После нескольких итераций получились сотни идей. Следующим этапом было прототипирование, поэтому нужно выбирать. У каждого участника было 5 «голосов». Чтобы проголосовать, нужно было поставить точку на стикере с идеей.

Четвертый этап — прототипирование (prototyping)

Для демонстрации решений команда выбрала инструмент story board. Технически это выглядело как некликабельные интерфейсы в Google Slides. В результате получилось 27 стори-бордов.
Сначала эти прототипы показывали людям по Skype — как тем, с кем проводили интервью, так и другим людям. «Прикольно было показывать именно тем, с которыми уже общались, потому что эту проблему мы достали именно от них. А теперь предлагаем им ее решение», — говорит Богдан Нановский.

На следующей презентации борду показали конкретные идеи, над которыми команда хотела работать. В итоге выбрали privacy: во-первых, потому что тема перспективная, во-вторых — к тому моменту в компании уже год работали над privacy-проектом (команда ZEO Lab об этом раньше не знала). Было логично реализовать эти идеи в работе ZEO Alliance.

Пятый этап — тестирование (testing)

На этом этапе все началось почти с начала — команда изучала вопросы privacy, дорабатывала story boards, проводила интервью с респондентами. Но цель была создать более реальный, рабочий прототип, чтобы поехать и еще раз его протестировать.
«В поля» поехала только половина команды. Новые интервью проводили почти три недели. План был такой: протестировать прототип, отправить фидбек в Киев, где за 2-3 дня его доработают и провести следующую итерацию тестирования.

Интервью на этом этапе отличались от этапа empathy: теперь был готов рабочий прототип и можно было наблюдать за тем, как с ним взаимодействуют пользователи.

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

В итоге Zeo Lab принес два результата: хорошую команду и IT-решение, на которое у компании есть планы.

Что дальше?

Команда, которая раньше работала в ZEO Lab, сейчас ответственна за UX в ZEO Alliance. Они продолжают использовать дизайн-мышление и обучают ему других.
На данном этапе эта команда дает инсайты и вводные остальным командам, валидирует, проверяет какие-то решения. Иногда для валидации работают дизайн-спринты (они занимают неделю), иногда может требоваться больше времени — все зависит от задачи. Например, недавно ребята полностью переделали UX продукта за месяц.
Тем временем, в компании продолжают развивать поход design thinking. Это вызывает необходимость решения нескольких непростых задач.

Челлендж #1. Масштабирование подхода

Масштабировать подход на всю компанию уже пробовали, но пока не получилось. Среди основных причин — невозможность системно обучить сразу всю команду, как это было в ZEO Lab, так как у команд есть текущие бизнес-задачи.

«Нужно понимать, что это дорогой эксперимент, и дело не только в деньгах. Дело в том, получишь ли ты вообще какой-то выхлоп. Серьезно, выхлопом design-thinking команды спокойно может быть НИЧЕГО», — объясняет Богдан.

Челлендж #2. Координация design thinking и agile-команд

Один из выводов команды состоит в том, что design thinking — подход рабочий, но не самодостаточный. За ним должен следовать какой-то lean startup или сразу agile. Очень хорошо придумывать идеи, прототипировать их, узнавать качественный фидбек, используя design thinking. Но дальше должна включаться более классическая продуктовая работа.

Большой вызов для ZEO сегодня — скоординировать команды, работающие по design thinking и agile, потому что иногда они разговаривают на разных языках.

Например, результатом работы команды design thinking может быть прототип. Они могут дать прототип и сказать — вот вам, мы сделали. А команда, работающая по agile, привыкла к тому, что у них есть user story, от которой они отталкиваются. Так, недавно ребята потратили месяц на то, чтобы переделать новый UX продукта и 2 месяца, чтобы перевести все это в требования.

Читайте нас в Telegram