Сегодня дизайнер не принимает решения только на основе своего опыта и вкуса. Самым важным критерием успеха будущего проекта становятся данные исследований. С их помощью дизайнер понимает, на какие метрики продукта повлияет макет, будет ли удобно пользователю работать с обновлениями, а также какие бизнес-задачи будут решены при помощи красивого дизайна.
Однако исследования аудитории до сих пор проводятся не всегда — иногда на них экономят или считают неважными. Олег Рудаков, директор по развитию направления аналитики в AGIMA, поделился опытом и рассказал, почему важно проводить исследования и что бывает, если ими пренебречь. Олег — преподаватель курса «Проектирование интерфейсов».
Во-первых, «все персонажи являются вымышленными, и любое совпадение с реально живущими или жившими людьми случайно». И тем более никогда не были связаны с работой автора этой статьи.
Во-вторых, исследование нужно не всем продуктам и не в 100% случаев. Например, если перед проектом стоит задача «сделать красиво» и нет никаких критериев эффективности продукта — не нужно тратить время на исследование, лучше потратить его на обсуждение задачи и выяснение того, что такое «красиво».
Качественные и количественные методы получения информации о пользователях и их поведении или взаимодействии с продуктами.
Примеры количественных методов:
Примеры качественных методов:
Ценность исследования — в выявлении реальных причин и сложностей пользователей при взаимодействии с продуктом. При исправлении найденных недостатков можно управляемо и осмысленно повысить эффективность продукта.
Кроме того, это даёт возможность приоритизировать бэклог продукта, чтобы сфокусироваться на выполнении задач, которые будут больше влиять на конечную эффективность продукта.
У дизайнеров и проектировщиков есть свои приёмы и очень часто их работа основана не на результатах исследования, а на их опыте, насмотренности или чувстве прекрасного. Однако у всех участников команды свои опыт, своя насмотренность и своё чувство прекрасного. Поэтому без исследования при любом споре команды о том, как должна выглядеть та или иная функциональность, победителем будет тот, чей голос больше весит. Объективных данных нет ни у одного участника спора, а следовательно и аргументов.
Другой часто встречающийся паттерн поведения при разработке продукта — копирование уже существующих и известных продуктов. С одной стороны, логично переиспользовать общие паттерны поведения пользователя. Например, расположить корзину интернет-магазина в правом верхнем углу страницы или вынести в табы мобильного приложения основные разделы и размещать их в нижней части экрана. С другой стороны, не нужно бездумно копировать все решения — возможно, не все они работают.
Из-за этого случаются ситуации, когда в свет выходят проекты с неоднозначными решениями — неработающими, неудобными. Обычно это выясняется на этапе сбора данных систем веб- или мобильной аналитики в уже готовом продукте, когда отключать его или удалять нет смысла, ведь в него вложили деньги и силы.
Поэтому в продукте остаётся эдакий чемодан без ручки, который кочует из версии в версию продукта потому, что «пользователи к этому привыкли».
Расскажу про несколько выдуманных примеров, когда уже готовое решение оказалось неудобным или ненужным пользователю. Моя цель — помочь задуматься о том, что дизайнеру или проектировщику для создания действительно качественного продукта чаще всего не обойтись без исследований.
Представим себе классифайд сайт. Пользователи заводят свои объявления, вносят основную информацию по товару и добавляют фото. Наверняка, вы сами пользовались подобными сайтами или просто заходили посмотреть, есть ли там что-то интересное из товаров.
Один такой сайт решил стать лучше и дать пользователям больше возможностей для упрощения подбора товаров. Для этого команда разработала и добавила на сайт две фичи: возможность сравнения товаров в одной категории и расширенные фильтры, в которых пользователи могли выбрать десяток дополнительных критериев отбора товаров, кроме стандартных (цвет, размер, цена, год производства и другие).
Решение кажется вполне логичным, поскольку все крупные интернет-магазины дают такие же возможности. А продаются и там, и там одинаковые товары. Плюс кажется, что технически сложные товары удобно выбирать, используя список сравнения.
После запуска фич их разметили системами аналитики и по событиям применения фильтров и списков товаров расширенной электронной торговли Google Analytics увидели, что почти никто не использует новую функциональность.
Затем решили провести исследование — онлайн-опрос аудитории на сайте об их целях и задачах работы с магазином, опыте покупок категорий товаров и вообще пользования сайтом.
Проведённый опрос показал интересные результаты: ключевой сегмент сайта — те, кто уже знают, что они хотят купить и какой товар им нужен. Поэтому из всех представленных товаров они выбирают по цене и состоянию, рассматривая буквально пару моделей. Для отбора таких товаров им не нужны сложные фильтры и они не пользуются функцией сравнения.
Конечно, ничего плохого не произошло. Добавленные опции оставили на сайте, так как вреда они не приносили. Только вот на разработку потратили время команды, а бизнес-показатели магазина не улучшили.
Как можно было поступить лучше
Команда могла узнать отношение пользователей к изменениям на этапе принятия решения о разработке. Это мог быть тот же онлайн-опрос на сайте. Он бы дал понимание опыта предыдущих покупок и потребностей пользователей в новой функциональности.
Также подошёл бы формат глубинных интервью с пользователями сайта, но по сравнению с опросом позволил бы узнать мотивы и запросы пользователей детальнее. Но мне больше нравится вариант опроса, поскольку это количественный метод исследования, который позволяет получить более широкие данные.
На волне цифровой трансформации инвестиционная компания (название не созвучно ни с каким банком и состоит не из трёх букв) решила разработать мобильное приложение для клиентов. В нём они могли бы просматривать информацию о своём портфеле, проводить сделки и изучать новости по интересующей теме от самой компании.
У конкурентов компании уже были мобильные приложения, но разница в том, что конкуренты всегда работали с менее платежеспособной аудиторией, которая составляет большинство. Эта аудитория — новички в сфере инвестиций, и для них дополнительные материалы по теме важны.
После передачи приложения в промышленную эксплуатацию была запущена рекламная кампания для продвижения среди текущих и потенциальных клиентов. По результатам исследования и анализа рентабельности инвестиций в рекламу определили, что привлечение новых клиентов совершенно нерентабельно. Стоимость привлечения высокая из-за конкуренции, а доход от клиентов небольшой, поскольку они проводят мало сделок и комиссия с них не окупает привлечение.
В результате реклама была быстро остановлена и приток пользователей в приложение стал равен притоку новых клиентов в компанию. Текущим клиентам стали отправлять рассылки и рассказывать о приложении в офисах и на сайте. Таким образом, приложение вместо удобной и интересной фичи для привлечения стало просто инструментом для работы с текущими клиентами.
Можно ли было предусмотреть такой результат — да. 5% клиентов компании давали 95% дохода. Причём эти клиенты никогда сами не проводили операции и взаимодействовали только со своими менеджерами на стороне компании. Всю отчётность для них привозили менеджеры и показывали её в распечатанном виде. Логично, что при такой модели новое приложение никак не затронуло основных, приносящих деньги клиентов. И тем более не привлекло бы таких же новых клиентов.
Как можно было поступить лучше
В этом кейсе нет необходимости в исследовании аудитории обычными способами. Для начала я бы не стал делить аудиторию на новых и текущих клиентов в рамках создания приложения. Новые и текущие клиенты есть у любого продукта. И я вижу целью разработки приложения скорее создание удобного инструмента для удержания текущих клиентов, чтобы они не пробовали, что есть у конкурентов.
Тогда команда бы увидела, что на лояльность текущих, приносящих деньги пользователей приложение никак не влияет.
Дополнительно помог бы расчёт юнит-экономики привлечения новых пользователей, чтобы увидеть сходимость экономики с учётом медиаплана.
Представим себе лендинг конференции. Структура лендинга сверху вниз:
Расположение блоков на странице кажется логичным: сначала пользователи должны изучить важную информацию и только потом записываться на конференцию. На деле же выяснилось, что структура сайта категорически неудобна. С таким расположением блоков после запуска лендинга оказалось, что конверсия в заявку слишком низкая, чтобы успеть собрать полный зал за оставшееся до мероприятия время.
Работу над проектом разделили на две части. Одна команда занималась анализом трафика на сайт, а вторая — анализом самого интерфейса. Посмотрели на данные в Яндекс.Метрике, которые вызвали сомнения в эффективности структуры страницы, — в глаза бросилась карта скроллинга.
Дальше решили провести A/B/N-тестирование, при котором на странице меняли местами форму заявки с другими блоками контента. Почему начали с формы? На лендинге была простая навигация, она не вызывала сложностей. Самих спикеров и их темы менять уже было поздно. Из возможных вариантов оставалась только сама структура страницы и расположение формы заявки.
В исследовании смотрели, из какой формы пользователи отправляют заявку на регистрацию. В итоге самая высокая конверсия была у лендинга со следующей структурой:
Как можно было поступить лучше
Организаторам конференции можно было провести исследование по итогам прошлого мероприятия. Например, вместе с полезными материалами разослать по участникам опрос, в котором спрашивали бы о причинах принятия решения о покупке билетов.
Дополнительно на старте продаж билетов такой опрос можно было провести с прошлыми клиентами по телефону, чтобы задать более детальные вопросы. Исследование простое, но оно дало бы хорошие результаты для понимания структуры будущих конференций.
Представим себе сайт небольшой страховой компании (не входит в топ-10 по продажам). А точнее представим калькулятор для расчёта размера страховки выезжающих за рубеж. После того, как логика и дизайн калькулятора проработаны, мы понимаем, что необходимо написать подсказки к полям и отработать ошибки полей ввода. Это поможет пользователям разобраться и увеличит конверсию, ради которой всё и было сделано.
Поскольку некоторые детали процесса страхования понятны только профессионалу, тексты подсказок напишет продакт-менеджер этого калькулятора — он лучше всех понимает продукт. Из-за этого в текстах появляются выражения «работа с повышенным риском», «досрочное возвращение застрахованного в страну постоянного проживания», «спорт» или «страхование от несчастного случая».
А для части пунктов никаких подсказок нет, ведь тому, кто их пишет, сразу понятно, что подразумевается под возрастом путешественника, и он точно разделяет «возраст» на дату покупки страховки и дату поездки. К сожалению, обычные пользователи не понимают этих формулировок или ошибаются в их трактовке.
После публикации подсказок некоторые клиенты писали в техническую поддержку, а кто-то сильно ругался, когда наступал страховой случай. А в полисе были ошибки из-за недостатка информации при заполнении.
В этом кейсе комплексного исследования не требовалось. Команде дизайнеров было сразу понятно, что сложные пункты нужно подробно объяснить. Поэтому проводили A/B-тесты, чтобы понять, как лучше описать подсказки.
Как можно было поступить лучше
Создателям стоило сразу задуматься о том, чтобы везде дать пользователям понятные подсказки. Проблема в том, что обычно разработчики очень глубоко погружены в тему продукта и им кажется, что всем вокруг также понятно всё. Но они не целевая аудитория продукта — нужно было провести юзабилити-тестирование прототипов. Или хотя бы одуматься, когда в поддержку начали сыпаться такого рода вопросы.
Исследование, проведённое до создания дизайна и разработки, может помочь получить требуемый результат или выяснить, что нужно или не нужно разрабатывать и как сделать функциональность более удобной для пользователя.
Бывают случаи, когда исследование излишне: нет ресурсов, времени или задача не влияет на критичные бизнес-показатели. Однако даже в таких случаях лучше провести хотя бы минимальное исследование, пусть даже коридорный опрос, чтобы проверить получившийся результат. Когда от дизайна зависит удобство использования продукта, лучше опираться на объективные данные, которые собрали перед началом работы.
Надеюсь, что приведённые примеры подтолкнут вас узнать больше об исследованиях пользовательского опыта для задач дизайна и чаще использовать их в работе. Успехов!
Однако исследования аудитории до сих пор проводятся не всегда — иногда на них экономят или считают неважными. Олег Рудаков, директор по развитию направления аналитики в AGIMA, поделился опытом и рассказал, почему важно проводить исследования и что бывает, если ими пренебречь. Олег — преподаватель курса «Проектирование интерфейсов».
Небольшой дисклеймер
Во-первых, «все персонажи являются вымышленными, и любое совпадение с реально живущими или жившими людьми случайно». И тем более никогда не были связаны с работой автора этой статьи.
Во-вторых, исследование нужно не всем продуктам и не в 100% случаев. Например, если перед проектом стоит задача «сделать красиво» и нет никаких критериев эффективности продукта — не нужно тратить время на исследование, лучше потратить его на обсуждение задачи и выяснение того, что такое «красиво».
Что понимаю под исследованием аудитории
Качественные и количественные методы получения информации о пользователях и их поведении или взаимодействии с продуктами.
Примеры количественных методов:
- Анализ данных систем веб- и мобильной аналитики.
- Онлайн- и офлайн-опросы пользователей продукта или респондентов в панели.
- Карточная сортировка.
Примеры качественных методов:
- Глубинное интервью пользователей.
- Модерируемое или не модерируемое юзабилити-тестирование респондентов.
- Дневниковые исследования.
Ценность исследования — в выявлении реальных причин и сложностей пользователей при взаимодействии с продуктом. При исправлении найденных недостатков можно управляемо и осмысленно повысить эффективность продукта.
Кроме того, это даёт возможность приоритизировать бэклог продукта, чтобы сфокусироваться на выполнении задач, которые будут больше влиять на конечную эффективность продукта.
Почему не всегда исследуют пользователя до разработки дизайна
У дизайнеров и проектировщиков есть свои приёмы и очень часто их работа основана не на результатах исследования, а на их опыте, насмотренности или чувстве прекрасного. Однако у всех участников команды свои опыт, своя насмотренность и своё чувство прекрасного. Поэтому без исследования при любом споре команды о том, как должна выглядеть та или иная функциональность, победителем будет тот, чей голос больше весит. Объективных данных нет ни у одного участника спора, а следовательно и аргументов.
Другой часто встречающийся паттерн поведения при разработке продукта — копирование уже существующих и известных продуктов. С одной стороны, логично переиспользовать общие паттерны поведения пользователя. Например, расположить корзину интернет-магазина в правом верхнем углу страницы или вынести в табы мобильного приложения основные разделы и размещать их в нижней части экрана. С другой стороны, не нужно бездумно копировать все решения — возможно, не все они работают.
Из-за этого случаются ситуации, когда в свет выходят проекты с неоднозначными решениями — неработающими, неудобными. Обычно это выясняется на этапе сбора данных систем веб- или мобильной аналитики в уже готовом продукте, когда отключать его или удалять нет смысла, ведь в него вложили деньги и силы.
Поэтому в продукте остаётся эдакий чемодан без ручки, который кочует из версии в версию продукта потому, что «пользователи к этому привыкли».
Расскажу про несколько выдуманных примеров, когда уже готовое решение оказалось неудобным или ненужным пользователю. Моя цель — помочь задуматься о том, что дизайнеру или проектировщику для создания действительно качественного продукта чаще всего не обойтись без исследований.
Ненужная функциональность
Антикейс №1 — возможность сравнения товаров в одной категории и расширенные фильтры для интернет-магазина
Представим себе классифайд сайт. Пользователи заводят свои объявления, вносят основную информацию по товару и добавляют фото. Наверняка, вы сами пользовались подобными сайтами или просто заходили посмотреть, есть ли там что-то интересное из товаров.
Один такой сайт решил стать лучше и дать пользователям больше возможностей для упрощения подбора товаров. Для этого команда разработала и добавила на сайт две фичи: возможность сравнения товаров в одной категории и расширенные фильтры, в которых пользователи могли выбрать десяток дополнительных критериев отбора товаров, кроме стандартных (цвет, размер, цена, год производства и другие).
Решение кажется вполне логичным, поскольку все крупные интернет-магазины дают такие же возможности. А продаются и там, и там одинаковые товары. Плюс кажется, что технически сложные товары удобно выбирать, используя список сравнения.
После запуска фич их разметили системами аналитики и по событиям применения фильтров и списков товаров расширенной электронной торговли Google Analytics увидели, что почти никто не использует новую функциональность.
Затем решили провести исследование — онлайн-опрос аудитории на сайте об их целях и задачах работы с магазином, опыте покупок категорий товаров и вообще пользования сайтом.
Проведённый опрос показал интересные результаты: ключевой сегмент сайта — те, кто уже знают, что они хотят купить и какой товар им нужен. Поэтому из всех представленных товаров они выбирают по цене и состоянию, рассматривая буквально пару моделей. Для отбора таких товаров им не нужны сложные фильтры и они не пользуются функцией сравнения.
Конечно, ничего плохого не произошло. Добавленные опции оставили на сайте, так как вреда они не приносили. Только вот на разработку потратили время команды, а бизнес-показатели магазина не улучшили.
Как можно было поступить лучше
Команда могла узнать отношение пользователей к изменениям на этапе принятия решения о разработке. Это мог быть тот же онлайн-опрос на сайте. Он бы дал понимание опыта предыдущих покупок и потребностей пользователей в новой функциональности.
Также подошёл бы формат глубинных интервью с пользователями сайта, но по сравнению с опросом позволил бы узнать мотивы и запросы пользователей детальнее. Но мне больше нравится вариант опроса, поскольку это количественный метод исследования, который позволяет получить более широкие данные.
Антикейс №2 — мобильное приложение для банковских клиентов
На волне цифровой трансформации инвестиционная компания (название не созвучно ни с каким банком и состоит не из трёх букв) решила разработать мобильное приложение для клиентов. В нём они могли бы просматривать информацию о своём портфеле, проводить сделки и изучать новости по интересующей теме от самой компании.
У конкурентов компании уже были мобильные приложения, но разница в том, что конкуренты всегда работали с менее платежеспособной аудиторией, которая составляет большинство. Эта аудитория — новички в сфере инвестиций, и для них дополнительные материалы по теме важны.
После передачи приложения в промышленную эксплуатацию была запущена рекламная кампания для продвижения среди текущих и потенциальных клиентов. По результатам исследования и анализа рентабельности инвестиций в рекламу определили, что привлечение новых клиентов совершенно нерентабельно. Стоимость привлечения высокая из-за конкуренции, а доход от клиентов небольшой, поскольку они проводят мало сделок и комиссия с них не окупает привлечение.
В результате реклама была быстро остановлена и приток пользователей в приложение стал равен притоку новых клиентов в компанию. Текущим клиентам стали отправлять рассылки и рассказывать о приложении в офисах и на сайте. Таким образом, приложение вместо удобной и интересной фичи для привлечения стало просто инструментом для работы с текущими клиентами.
Можно ли было предусмотреть такой результат — да. 5% клиентов компании давали 95% дохода. Причём эти клиенты никогда сами не проводили операции и взаимодействовали только со своими менеджерами на стороне компании. Всю отчётность для них привозили менеджеры и показывали её в распечатанном виде. Логично, что при такой модели новое приложение никак не затронуло основных, приносящих деньги клиентов. И тем более не привлекло бы таких же новых клиентов.
Как можно было поступить лучше
В этом кейсе нет необходимости в исследовании аудитории обычными способами. Для начала я бы не стал делить аудиторию на новых и текущих клиентов в рамках создания приложения. Новые и текущие клиенты есть у любого продукта. И я вижу целью разработки приложения скорее создание удобного инструмента для удержания текущих клиентов, чтобы они не пробовали, что есть у конкурентов.
Перед тем, как разрабатывать приложение, компании нужно было проанализировать структуру прихода средств по типам клиентов.
Тогда команда бы увидела, что на лояльность текущих, приносящих деньги пользователей приложение никак не влияет.
Дополнительно помог бы расчёт юнит-экономики привлечения новых пользователей, чтобы увидеть сходимость экономики с учётом медиаплана.
Неудобная функциональность
Антикейс №1 — неудачная структура лендинга
Представим себе лендинг конференции. Структура лендинга сверху вниз:
- большой баннер с логотипом, названием и датами проведения;
- топ-10 спикеров с фото (известные всем кто в теме);
- баннер;
- ещё 30 спикеров с фото;
- форма заявки на покупку билета;
- полная программа мероприятия;
- карта проезда;
- форма заявки на покупку билета;
- логотипы партнёров.
Расположение блоков на странице кажется логичным: сначала пользователи должны изучить важную информацию и только потом записываться на конференцию. На деле же выяснилось, что структура сайта категорически неудобна. С таким расположением блоков после запуска лендинга оказалось, что конверсия в заявку слишком низкая, чтобы успеть собрать полный зал за оставшееся до мероприятия время.
Работу над проектом разделили на две части. Одна команда занималась анализом трафика на сайт, а вторая — анализом самого интерфейса. Посмотрели на данные в Яндекс.Метрике, которые вызвали сомнения в эффективности структуры страницы, — в глаза бросилась карта скроллинга.
Дальше решили провести A/B/N-тестирование, при котором на странице меняли местами форму заявки с другими блоками контента. Почему начали с формы? На лендинге была простая навигация, она не вызывала сложностей. Самих спикеров и их темы менять уже было поздно. Из возможных вариантов оставалась только сама структура страницы и расположение формы заявки.
В исследовании смотрели, из какой формы пользователи отправляют заявку на регистрацию. В итоге самая высокая конверсия была у лендинга со следующей структурой:
- большой баннер с логотипом, названием и датами проведения;
- топ-10 спикеров с фото;
- форма заявки на покупку билета;
- всё остальное.
Аудитории было интересно послушать топовых спикеров, и им было неважно, кто ещё будет выступать и какие именно будут темы докладов. Поэтому на лендинге конференции форму регистрации подняли выше, после чего конверсия сильно выросла.
Как можно было поступить лучше
Организаторам конференции можно было провести исследование по итогам прошлого мероприятия. Например, вместе с полезными материалами разослать по участникам опрос, в котором спрашивали бы о причинах принятия решения о покупке билетов.
Дополнительно на старте продаж билетов такой опрос можно было провести с прошлыми клиентами по телефону, чтобы задать более детальные вопросы. Исследование простое, но оно дало бы хорошие результаты для понимания структуры будущих конференций.
Антикейс №2 — калькулятор для расчёта размера страховки
Представим себе сайт небольшой страховой компании (не входит в топ-10 по продажам). А точнее представим калькулятор для расчёта размера страховки выезжающих за рубеж. После того, как логика и дизайн калькулятора проработаны, мы понимаем, что необходимо написать подсказки к полям и отработать ошибки полей ввода. Это поможет пользователям разобраться и увеличит конверсию, ради которой всё и было сделано.
Поскольку некоторые детали процесса страхования понятны только профессионалу, тексты подсказок напишет продакт-менеджер этого калькулятора — он лучше всех понимает продукт. Из-за этого в текстах появляются выражения «работа с повышенным риском», «досрочное возвращение застрахованного в страну постоянного проживания», «спорт» или «страхование от несчастного случая».
А для части пунктов никаких подсказок нет, ведь тому, кто их пишет, сразу понятно, что подразумевается под возрастом путешественника, и он точно разделяет «возраст» на дату покупки страховки и дату поездки. К сожалению, обычные пользователи не понимают этих формулировок или ошибаются в их трактовке.
После публикации подсказок некоторые клиенты писали в техническую поддержку, а кто-то сильно ругался, когда наступал страховой случай. А в полисе были ошибки из-за недостатка информации при заполнении.
Мы провели A/B-тестирование и после анализа запросов пользователей в техподдержку добавили для сложных полей подсказки. В результате за счёт кропотливой проработки текстов подсказок удалось увеличить конверсию на 10%.
В этом кейсе комплексного исследования не требовалось. Команде дизайнеров было сразу понятно, что сложные пункты нужно подробно объяснить. Поэтому проводили A/B-тесты, чтобы понять, как лучше описать подсказки.
Как можно было поступить лучше
Создателям стоило сразу задуматься о том, чтобы везде дать пользователям понятные подсказки. Проблема в том, что обычно разработчики очень глубоко погружены в тему продукта и им кажется, что всем вокруг также понятно всё. Но они не целевая аудитория продукта — нужно было провести юзабилити-тестирование прототипов. Или хотя бы одуматься, когда в поддержку начали сыпаться такого рода вопросы.
Резюмируем
Исследование, проведённое до создания дизайна и разработки, может помочь получить требуемый результат или выяснить, что нужно или не нужно разрабатывать и как сделать функциональность более удобной для пользователя.
Бывают случаи, когда исследование излишне: нет ресурсов, времени или задача не влияет на критичные бизнес-показатели. Однако даже в таких случаях лучше провести хотя бы минимальное исследование, пусть даже коридорный опрос, чтобы проверить получившийся результат. Когда от дизайна зависит удобство использования продукта, лучше опираться на объективные данные, которые собрали перед началом работы.
Надеюсь, что приведённые примеры подтолкнут вас узнать больше об исследованиях пользовательского опыта для задач дизайна и чаще использовать их в работе. Успехов!
