{"id":13654,"url":"\/distributions\/13654\/click?bit=1&hash=7a7aa21667aefd656b6233efba962ecbef616dfd5ac100a493b4b5899b23ff1f","title":"\u041c\u044b \u043f\u043e\u043f\u0440\u043e\u0441\u0438\u043b\u0438 \u0440\u043e\u0434\u0438\u0442\u0435\u043b\u0435\u0439 \u043e\u0431\u044a\u044f\u0441\u043d\u0438\u0442\u044c, \u043a\u0442\u043e \u0442\u0430\u043a\u0438\u0435 \u00ab\u043a\u0440\u0435\u0430\u0442\u043e\u0440\u00bb \u0438 \u00ab\u043f\u0440\u043e\u0434\u0430\u043a\u0442\u00bb","buttonText":"\u0421\u043c\u043e\u0442\u0440\u0435\u0442\u044c","imageUuid":"32086418-934b-5de5-a4ef-6425a84c490a","isPaidAndBannersEnabled":false}
Дизайн
True Engineering

Как UX-исследования избавляют от дорогих ошибок в продуктах

UX-исследования позволяют команде проверить базовые продуктовые гипотезы на самом раннем этапе, еще до того, как к процессу подключаются разработчики. В результате команда может скорректировать подход к UX «на стадии котлована», когда исправление ошибки не заставит перестраивать все здание. Рассказываем, как мы проводим UX-исследования в True Engineering и что для них нужно.

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

Когда речь идет о сложных сервисах, команде нужно понимать, какой сценарий будет интуитивно понятным для клиентов. Участников исследования погружают в контекст и предлагают решить задачу. Далее нужно пронаблюдать за его действиями – логика пользователей может сильно отличаться от представлений разработчиков, и это нормально. Нужно выяснить, почему человек действует так или иначе, что его мотивирует, а что мешает.

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

Важно понимать, что в UX-тестированиях не бывает «плохих» или неправильных ответов. С определенной точки зрения, можно сказать, что чем хуже человек справляется с тестом, тем лучше для нас – значит, мы выявляем максимум проблем, с которыми реальные пользователи уже не столкнутся. Но это вовсе не означает, что мы даем респондентам неработающие прототипы.

Итог UX-исследования – карта взаимодействия пользователя с продуктом (Customer Journey Map). Она объединяет в себе все впечатления клиента от продукта, его пожелания на каждом шаге сценария. Оформляется примерно так – слева описание целевого пользователя, далее собраны полезные данные о клиентском опыте по каждому этапу его «путешествия»:

Методы исследования

На ранних стадиях разработки лучше всего использовать качественные исследования, которые отвечают на вопросы «как» и «почему». Как пользователь идет по сценарию? Почему он открывает именно эту шторку, чтобы найти нужную информацию? Как ему будет удобно добраться до настроек? Почему другой вариант окажется неудобным? Технологии качественных исследований бывают разные: глубинные интервью, фокус-группы, и т.д. Для наших целей больше всего подходит метод модерируемого юзабилити-тестирования:

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

Модератор в любой может задать респонденту вопрос, уточнить что-то, пообщаться после проведения теста. Чем больше правильных и своевременных вопросов будет задано, тем более эффективными и ценными будут результаты теста. Юзабилити-тесты можно проводить и без участия модератора, но – тогда результаты будут менее глубокими.Метод позволяет быстро получить первую обратную связь от потенциальных или реальных клиентов. А если продукт уже работает, понять, что можно улучшить.Теперь о том, как строится такое исследование.

Формулируем цель и гипотезы

Цель – это ключевой вопрос, на который мы хотим ответить. Он может быть общим, например, пользователи справляются с оформлением страховки через приложение – да/нет. Или частным: оформление не занимает больше 15 минут, пользователи обращают внимание на некое специальное условия и т.д. Цель затем раскладывается на гипотезы, которые мы проверяем по ходу исследования.Примеры гипотез – клиент понимает, за что отвечает вот эта кнопка, знает, как на том экране нужно выбрать нужные ему условия, замечает, как тот или иной фактор влияет на цену и т.д. Из этих небольших вопросов складывается главный ответ, который задается в цели исследования.

Определяем метрики исследования

  • Успешность выполнения задания. Пользователь справился с заданием практически без проблем – 100%; столкнулся с проблемами, но в итоге справился – 50%; – не справился с заданием – 0%.
  • Субъективная оценка простоты шага. Сам пользователь выставляет оценку от 1 до 5 баллов и дает аргументацию. Именно здесь, как правило, мы получаем самую ценную информацию – респонденты указывают нам на самые удачные UX-решения и делятся впечатлениями о том, что было удобно, а что – не очень.
  • Частота возникновения проблем. Составляется по итогам тестирования – мы считаем, какие возникли сложности и как часто возникают.

Подбираем аудиторию

В подборе респондентов значение имеют пол, возраст, город проживания, достаток, опыт работы с ИТ-сервисами, используемое устройство. Разумеется, для чистоты эксперимента мы не привлекаем людей из команды разработки и сферы ИТ. И стараемся максимально попадать в целевую аудиторию – тестировать премиальные сервисы на студентах бессмысленно.Интересно, что для качественного исследования достаточно 5-8 респондентов. UX-эксперты выяснили, что если увеличивать число участников, то выявляемые трудности начинают повторяться, так что новой информации исследователь уже не получит. Зато в количественных исследованиях счет респондентов должен идти на десятки, а то и сотни.

Создаем контекст

Мы не просто даем респондентам прототип приложения, а создаем некую картинку, чтобы они почувствовали себя на месте будущих пользователей. Например: «Ты выдвигаешься на работу, садишься в свою машину. Тебе нужно воспользоваться дорожным сервисом, который ты вчера себе скачал. Твои действия?»Контекст влияет на опыт взаимодействия с продуктом. Важно, чтобы созданный контекст был максимально близок к реальным историям клиентов, т.к. в зависимости от ситуации, сценарии использования могут отличаться.

Готовим скрипт

Сценарий исследования для всех участников одинаковый. Модератор дает вводные о том, как будет проходить тест, рассказывает о продукте, погружает в контекст.В сценарий входят задания, которые нужно выполнить респонденту, и вопросы для модератора, которые он должен задать на каждом шаге. Очень важно, чтобы формулировки не направляли пользователя к тем или иным функциям напрямую – нужно, чтобы он сам искал техническое решение для своей задачи.То есть мы не говорим респонденту: «Вам нужно отключить услугу в настройках. Как вы будете это делать?». Вместо этого задание звучит примерно так: «Вы поэкспериментировали с услугой и поняли, что сейчас она для вас не актуальна. Ваши действия?» Тогда пользователь должен сам понять, что это нужно сделать в настройках, самостоятельно зайти туда и найти нужную опцию. Если у него не получится это сделать, это сигнал для дизайнеров.

Собираем и анализируем результаты

Когда все интервью позади, мы собираем всю информацию от респондентов в единую базу. Чтобы понять, было ли исследование успешным, нужно ответить на следующие вопросы:

  • Удалось ли подтвердить или опровергнуть гипотезы? Группируем ответы по гипотезам, удостоверяемся, что мы собрали достаточно информации по каждому пункту.
  • Какие участки сценария оказались для пользователей самыми удобными, а где было больше проблем? Опять же, сейчас мы не задумываемся о том, почему это произошло и что с этим делать – только факты.
  • О каких трудностях они говорили по ходу теста? Готовим список всех моментов, которые были непонятными, неочевидных шагов и тупиков. Плюс субъективные оценки простоты с аргументацией и прочими комментариями.

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

С этой информацией перед глазами мы получаем комплексную информацию о том, как обстоят дела в сценарии. И можем формировать предложения по улучшению. Теперь мы понимаем, какие у продукта проблемы, можем их приоритизировать.Более того, мы можем оценить, окупится ли на данном этапе доработка сложного сценария или от него можно отказаться. Еще один пример из нашего опыта – по итогам UX-исследования принципиально нового продукта выяснилось, что пользователи не могут разобраться с одним из двух базовых режимов работы. Мы предложили заказчику исключить этот режим из MVP, чтобы сосредоточиться сейчас на одном сценарии, а второй доработать на следующем этапе проекта.

Чек-лист для старта UX-исследования

Чтобы протестировать UX нового продукта, команде нужна следующая информация:

  • Описание продукта. Что именно мы будем тестировать?
  • Цели исследования. На что повлияют его результаты? Какие решения будет принимать команда с полученной информацией?
  • Сценарий. Какие шаги проходит пользователь на пути к своей цели? Один продукт может включать любое количество сценариев.
  • Гипотезы и вопросы. Какие сомнения у команды есть? Что хочется прояснить в сценариях? Какие есть предположения о проблемных местах в интерфейсе? Какие важные вопросы сейчас без ответа?
  • Кто пользователи. Какие пользователи интересны в контексте этого исследования (роль, особенности организации, отрасль, активность в сервисе)? Какие задачи они решают в сервисе? Есть ли лояльные пользователи и их контакты?
  • Сроки. К какому сроку важно получить информацию, иначе будет поздно?

Ответить на все эти вопросы продуктовой команде не составит труда. А дальше дело техники UX-экспертов – они подберут нужные методы, сформируют группу респондентов, проведут исследование и помогут правильно интерпретировать результаты.

0
10 комментариев
Написать комментарий...
Михаил Нежник

Полезно, спасибо, как раз учусь на UX/UI дизайнера, хочу уже найти работу и радоваться, но пока ещё только прохожу курсы и читаю статьи :)

Ответить
Развернуть ветку
Евгений Кирюхин

Спасибо за статью!

Ответить
Развернуть ветку
Анастасия Залипутина

Подскажите, пожалуйста, название сервиса из первого скриншота

Ответить
Развернуть ветку
Михаил Ивченко
Ответить
Развернуть ветку
Сергій Зеленський

Неужели всем этим кто-то в реале занимается?

Ответить
Развернуть ветку
Вениамин Мустафин

Всегда было интересно мнение экспертов, насколько качественней результат дает проектирование интерфейса через исследование респондентов в сравнении с тем, когда нормальный дизайнер проектирует интерфейс на основе того же конкурентного анализа и данных, которые он собрал о ЦА?

Вот пришел к вам человек, вы его посадили за стол, дали ноутбук и дали цель — «Оформить страховку через форму на сайте». Для респондента это просто задание — дойти до последнего шага формы и нажать на последнюю кнопку. Да еще и под наблюдением модератора, который будет его отвлекать от интерфейса. Но это же совсем не те условия, в которых реальный пользователь будет взаимодействовать с интерфейсом. Да и цель эта не его, а навязанная.

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

Ответить
Развернуть ветку
Константин Березин

Исследования, как правило, нужны в сложных продуктах, к примеру финтех. Там настолько сложные флоу и их так много, что одним необдуманным действием, ты можешь сломать сценарии к хренам. То, о чем вы говорите, подходит для какой-нибудь студии, которая делает условный сайт "Пластиковые окна в Воронеже". Там да, ничего такого не нужно, и обычный дизайнер сможет решить большинство проблем. Но посади такого в продуктовку, он банально даже не поймет с чего начинать без изучения cjm (я так понимаю, вы считаете, что и этот инструмент лишний). 
PS Вы сказали про модератора, который будет отвлекать респондента. Для таких ситуаций предусмотрены дневниковые и этнографические исследования. В чем проблема?))

Ответить
Развернуть ветку
Вениамин Мустафин

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

Вы говорите про сложные продукты. Я согласен, но в статье я не увидел ни одной отсылки к сложности продукта. Не раз сталкивался с дизайнерами, которые после прочтения статей пытались запихнуть оверхедные инструменты в проект, потому что "ну так написано же".

Ответить
Развернуть ветку
Константин Березин

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

Ответить
Развернуть ветку
Алексей Чижов

Как раз искал материал по UX анализу. Благодарю за статью!

Ответить
Развернуть ветку
Читать все 10 комментариев
null