Привет! На связи команда продуктового дизайна из Samokat.tech: Артур, Максим и Наташа. В этой статье расскажем, как мы начали проводить продуктовые исследования внутренними силами команды. «Что из этого вышло» и «Как внедрить такой подход» – разбираем на конкретных примерах от первого лица.
Представьте: пользователи не замечают блок с кнопками «Выбрать адрес доставки» и «Войти».
Мы думаем, что внимание привлечет картинка, но на деле иллюстрация мешает, провоцирует эффект баннерной слепоты.
О таких проблемах очень хотели бы знать дизайнеры, работающие над сервисом, правда? Суровая реальность: на практике проведением исследований, помогающих выявить подобные трудности занимаются специализированные исследователи из отдельной команды. Дизайнерам и всем заинтересованным приходится дожидаться результатов исследований.
В Samokat.tech мы внедряем исследования в процесс разработки силами команды продуктового дизайна. Изучаем потребности пользователей, проверяем гипотезы, тестируем дизайны – самостоятельно.
Мы убеждены, что такой подход помогает лучше решать задачи пользователей, быстрее создавать по-настоящему нужные фичи и меньше переделывать. А еще так повышается профессиональная ценность линейных специалистов — за счет приобретения новых навыков и расширения кругозора.
В этой статье мы хотим поделиться нашим опытом по части проведения продуктовых исследований силами не исследователей – вспомним матчасть, разберём примеры. Надеемся, будет полезно для дизайнеров и всех людей из продуктовых команд, кто специализируется не на исследованиях, но хотел бы иметь возможность узнавать продуктовые инсайты экспериментальным путем.
Исследования? Своими руками?
Кажется, продуктовому дизайнеру несложно представить себе ситуацию, когда необходимо иметь дело с абстрактным ТЗ, недосконально сформулированными формулировками задач и ожиданиями результата, который «нужен был ещё вчера».
Установку «требований нет, погнали проектировать, а там разберемся» ожидаешь встретить скорее в стартапе, чем в зрелой компании. Но на практике темпы роста бизнеса часто приводят к подобному и в организациях, которые уже давным-давно нашли свой product-market fit. Если делать размеренно и постепенно, можно впасть в иную крайность: «сначала полгода исследований, только потом команда хоть что-то начнет».
Мы в Samokat.tech тоже проходили этот этап. Когда сначала релиз – это долго, а потом множество правок и переделок – это больно.
Наш переход на качественно новый уровень не был одномоментным. Сначала мы стали дотошно интервьюировать всех стейкхолдеров, чтобы выявить потребности. Потом стали исследовать задачи через CJM, опрашивали пользователей и команды. И только после этого начали устраивать исследования и решили звать участников продуктовой команды на встречи, задавать вопросы и вовлекать в процесс.
Многие компании обходятся без всяких исследований, а другие заказывают или проводят их с помощью выделенных специалистов. Мы для себя определили следующие причины всё же делать исследования и именно руками продуктовых дизайнеров:
Больше определенности и понимания, что делать
Бывает довольно некомфортно работать в условиях неопределенности, когда постоянно приходится додумывать и угадывать. Данные исследований дают решениям обоснование, а сам процесс обеспечивает лучшее понимание деталей и контекста.Меньше переделывать
Рискованно делать продукт на непроверенных гипотезах. Решение может получиться неудовлетворительным для пользователя, а время и ресурсы будут уже потрачены. Исследования – возможность лучше понять свою целевую аудиторию, не заставлять пользователей терпеть неудобства, сэкономить на разработке (быстрее сделать нужное, меньше переделывать).Легче презентовать решение
Опираясь на исследования, можно аргументировать заказчикам и стейкхолдерам, почему сделано именно так.
Конечно, внедрение исследований в команду не обходится без трудностей. Команду может смущать увеличение сроков на проектирование. Новые процессы может быть сложно принять – непривычно работать по-другому, кажется, что было «и так нормально». Но стоит команде вовлечься хотя бы в качестве наблюдателей и увидеть первые результаты — дело начинает идти заметно бодрее и легче.
На каком этапе работы над задачей внедрять исследования
На любом. Для разных этапов работы есть разные методы исследований. Универсальное правило тут на наш взгляд: дизайнера стоит привлекать как можно раньше.
Возможные сценарии:
Перед стартом новой задачи
Если бизнес нуждается в новой фиче или продукте, будет здорово получить перед стартом побольше данных. Например, при создании веб-версии Самоката мы провели глубинное исследование, где проверяли, насколько пользователям вообще нужен сайт, ведь все уже и так пользуются приложением. После запуска MVP делали еще несколько предметных и коротких исследований, помогающих протестировать работу продукта. Сайт работает, но исследования продолжаются, чтобы выяснять возможные трудности и улучшать пользовательский опыт.В дорогих и важных проектах
Здесь больше ответственности и рисков, а исследования помогут сработать более точно и эффективно, сократить количество нестыковок с ожиданиями пользователей и клиента.Когда детального ТЗ пока не существует
Бывает, что хотим сделать вещи, для которых не всегда есть время на подробную проработку требований, по множеству разных причин. В этом случае исследование – путь к уменьшению неопределенности.Когда команда разрознена или есть трудности с коммуникациями
Активное участие коллег в исследовании может повысить интерес к продукту, креативность и общую сплоченность.
Выбирайте подходящий момент исходя из своих потребностей и специфики проекта. От этого во многом зависит и метод исследования.
Как выбрать подходящий метод исследования
Подходов множество: глубинные интервью, UX-тесты, опросы. После исследования — этап систематизации результатов. Для этого тоже существуют различные фреймворки, например, метод персон и Jobs To Be Done, CJM. Используя эти данные, дизайнер может начать проектировать.
При выборе подхода мы опираемся на три момента — предмет исследования, количество времени и здравый смысл.
На старте проекта самыми полезными оказываются глубинные интервью, когда мы собираем информацию для решения задачи → Обсуждать и согласовывать решение можно при помощи Customer Journey Map → собирать обратную связь пользователей на готовый дизайн помогают UX-тесты.
Без глубинных интервью не обойтись, когда много вопросов и хочется понять, как люди поступают, почему выбирают один способ поведения, а не другой. Когда слушаешь людей, начинаешь понимать их способ мышления. И уже осознанно принимаешь решения о реализации. Глубинные интервью помогают узнать то, о чем изначально не предполагал.
А если нужно просто понять, насколько удобно сделан блок или кнопка, нет смысла собирать сторонних респондентов и проводить часовые интервью. Можно организовать немодерируемый UX-тест на сотрудниках компании и собрать данные буквально за сутки.
На примере выше мы проверяли на коллегах, насколько понятно и удобно пользоваться правым модулем корзин Самоката. Бросили клич во внутренний чат и за сутки тест прошли около 100 человек. Мы думали, что могут быть проблемы из-за необычной реализации — корзина появляется в правом модуле как поп-ап поверх сайта. Но оказалось, что большинство справляется с этим за 5 секунд без проблем.
Бывает, что пользователи сами не знают, чего хотят — бесполезно спрашивать, что и как сделать. Здесь подойдут А/В-тесты, на которых можно сразу проверить, что лучше работает.
Или на каких-то участках очевидны проблемы, а их причины — нет. Тогда мы собираем все проблемы вместе, ранжируем и решаем, что с ними делать. Например, пользователи не завершают какой-то сценарий, не оплачивают заказ — проблема важная, надо срочно решать. Сами анализируем, выдвигаем гипотезы и тестируем по кругу, пока не находим решение.
А еще есть просто аналитика. Например, как много людей кликают по кнопкам или проходят сценарии. На её основе можно сделать выводы, собрать гипотезы, которые хочется проверить.
Как мы решаем задачи с помощью разных исследований
Есть вещи, которые отражаются на общей удовлетворенности сервисом, а есть те, что влияют на показатели: конверсии и деньги. На разных этапах работы разные задачи и к каждой — свой подход. Вот, как мы комбинировали различные части описанной выше матчасти для решения конкретных задач.
Кейс: глубинные исследования пользователей сайта
Например, мы хотели понимать, зачем люди приходят в Самокат, что им нравится, а что нет, какие у них проблемы и трудности. Последовательность шагов тут была классической:
собрали бриф – зафиксировать наши договоренности о целях исследования;
составили выборку и написали гайд по проведению исследования;
нашли респондентов (в группу вошли те, кто заказывал на мобильном и в десктопном вебе);
провели 10 интервью на 45-60 минут каждое в Zoom по всему сценарию заказа продуктов.
И получили подробный ответ на принципиальный вопрос: когда используют сайт?
В процессе интервью мы выяснили ряд проблем разного уровня критичности.
Например, на главном экране всем понятно, как работает навигационный бар, центральный блок и поиск. Но бывают сложности с поиском нужного товара в наших категориях-подборках — понятно, где искать молоко, а вот с соусами уже сложнее. А еще респонденты вообще не замечали правый блок с кнопками «Выбрать адрес доставки» и «Войти». Мы рассчитывали, что картинка привлечет внимание, но из-за баннерной слепоты ее наоборот не замечали.
Мы опасались, что будет сложно работать со шторкой товара. Оказалось, что никто не испытывал трудностей. Вместо этого проблемой было большое описание состава — почему то товары с большим описанием покупают реже, даже если все компоненты натуральные.
Отдельная история с адресом доставки: когда респонденты доходят до этого этапа заказа, все несколько секунд тратят на осознание того, что видят. В веб-версии в отличие от мобильного приложения, никто не пользуется картой для выбора адреса, его просто вводят вручную.
В блоке с корзиной и профилем в целом проблем не было, кроме одной довольно серьезной: не все понимали, что в каталоге на главной странице – демо-версия всего ассортимента Самоката. А по разным адресам продукты доставляются из разных дарксторов. И при выборе адреса доставки люди не понимали, что произошло, и почему часть выбранного товара не отображается в корзине. Здесь нужна была доработка.
А еще все люди авторизовались только после сбора корзины. При этом половина респондентов думала, что телефон спрашивают для связи с ними на всякий случай, не предполагая, что это и есть авторизация.
Исследование показало, что блокирующих проблем на сайте нет. Самые критические мы убрали сразу же, а моменты, которые вызывают дискомфорт или раздражение, увеличивают время выполнения задач — решаем в рабочем порядке.
Кейс: немодерируемые UX-тесты на сотрудниках и пользователях
Тест первого клика мы провели сначала на сотрудниках Samokat.tech, а потом на реальных пользователях. Проверяли, насколько быстро и удачно пользователи решали основные задачи:
авторизация;
выбор адреса доставки;
изменение адреса доставки;
просмотр состояния заказа;
поиск предыдущих заказов.
Выяснилось, что результаты примерно одинаковые, но нужно учитывать, что количество респондентов было небольшим, поэтому нельзя говорить о статистической значимости результатов.
Выходит, иногда проверять гипотезы на сотрудниках вполне себе допустимо и может существенно ускорить и удешевить процесс исследований. Главное – найти достаточно большое количество респондентов, которые не участвуют в разработке фичей, для которых вы проверяете гипотезы.
Кейс: физические исследования при работе на складе
До пандемии практически все юзабилити-тесты проходили очно. Респондента приглашали в офис, вручали телефон или компьютер, настраивали камеры. В некоторых случаях использовали айтрекеры — камеры для записи движений глаз, по ним можно отследить, куда респондент смотрит чаще всего, а на что вообще не обращает внимание.
Но пандемия показала возможности онлайн-тестов, несмотря на все сложности и ограничения: местоположение респондентов перестало иметь значение, поэтому их круг стал шире, и встречу стало проще организовать. Теперь очные тестирования проводятся гораздо реже. Тем не менее, бывают случаи, когда без них не обойтись.
Например, когда важен контекст, в котором работает пользователь. Это наш случай! Среди наших продуктов – те, что оцифровывают и автоматизируют процесс для работников на складе. Там человек не просто смотрит в телефон — он сканирует штрихкоды, сортирует товары, переставляет коробки, катает тележку.
Как провести такой тест? Порядок действий будет такой же, как у теста в онлайне.
Сначала пишем бриф и обозначаем цель — для чего проводим тест. Затем выписываем отдельные гипотезы, которые хотим проверить. Пишем сценарий теста, готовим кликабельный прототип в Фигме.
Договариваемся с начальством склада, просим выделить нам респондентов. В день тестирования приезжаем на склад, по одному встречаемся с респондентами и проводим краткий инструктаж: кто мы, что нам нужно, и сколько это займет времени. Даем человеку задание и просим озвучивать все свои мысли и намерения — залезть в голову к человеку мы не можем, а информации хочется узнать побольше. После этого начинаем наблюдение.
Сотрудники склада пользуются терминалами сбора данных — по сути это мобильный телефон, только очень прочный. Сотрудник начинает выполнять задание, ходит с девайсом, что-то сканирует, перекладывает, а мы наблюдаем и отмечаем, какая из гипотез подтвердилась, а какая нет. Если человек испытывает затруднения сверх отведенного времени — подсказываем, отмечаем гипотезу как провальную и ведем дальше по сценарию.
Мероприятие проводим на нескольких респондентах → сводим все одну таблицу → анализируем и находим самые проблемные места → думаем, как их можно улучшить → презентуем результаты своей команде → думаем, что из этого берем в работу.
По результатам теста мы решили переделать процесс приемки брака.
Исследователи не нужны?
Внедрение исследований помогло нам быстрее видеть последствия наших решений, делать более точные выводы, а еще показать коллегам, что дизайнеры руководствуются данными, а не ощущениями.
Получается, если делать продуктовые исследования самостоятельно, то профессиональные исследователи не нужны?
Нужны.
Одна из составляющих успеха в нашем случае – коллеги-исследователи организовали трехмесячное обучение для дизайнеров. Все желающие смогли изучить, как правильно проводить интервью, юзабилити-тесты и составлять опросы.
Теперь стараемся планировать загрузку сразу с учетом тестов, которые помогают понять направление действий и масштабы изменений в продуктах. И главное — принимать осознанные решения, точнее попадать в ожидания и потребности пользователей и меньше переделывать.
Общий принцип здесь звучит примерно так: как дизайнеры мы не стали такими же компетентными в исследованиях, как профессиональные исследователи, и более того, у нас нет такой цели. Мы накопили экспертизу, которой достаточно, чтобы децентрализовать и за счёт этого ускорить процесс – существуют исследования, которые мы можем проводить самостоятельно. А коллеги-исследователи выступают тут в качестве центра экспертизы, помогают нам прокачиваться.
Так что вся история выше – не о том, как отменить какую-то роль, а как найти более продуктивный способ работать вместе.
Как у вас в компании и команде организованы продуктовые исследования? Кто за них отвечает? Расскажите в комментариях!
