На основании каких параметров оценивается критичность ошибки в юзабилити тестировании
Юзабилити тестирование
Когда тестировать
Вы должны тестировать рано и часто. Тестирование удобства позволяет команде дизайнеров и разработчиков выявить проблемы до того, как спрограммирован код. Чем раньше эти проблемы будут найдены и зафиксированы, тем меньше средств понадобится на их устранение.
Вам не нужна специальная лаборатория для проведения теста на удобство. Вы можете успешно провести юзабилити-тестирование при любом из представленных ниже условии:
Что вы узнаете?
Вы узнаете, могут ли участники теста успешно выполнять определённые рутинные задачи и как много времени им на это требуется. Вы узнаете, насколько участники удовлетворены работой с вашим сайтом. В целом, вы сможете выяснить, какие изменения необходимо сделать для того, чтобы повысить эффективность работы пользователя с вашим сайтом. Вы также можете узнать, отвечает ли ваш сайт требованиям юзабилити.
Четыре вещи, которые нужно иметь в виду
1. Необходимо тестировать сайт, а НЕ пользователей
Вы должны убедить участников, что тестируют не их. Вы должны дать им понять, что они помогают Вам протестировать прототип или веб-сайт.
2. Показатели выполнения и субъективные показатели
Учитываются как показатели выполнения заданий пользователями, так и их собственная субъективная оценка продукта. К показателям выполнения заданий относятся: успешность выполнения задания, время выполнения, ошибки и т.д. Субъективные показатели включают в себя: удовлетворённость пользователя работой с продуктом и рейтинги того, насколько было удобно и легко пользоваться продуктом.
Результаты выполнения заданий и субъективная оценка пользователей не всегда совпадают. Зачастую пользователи плохо справляются с поставленными задачами, но их субъективные оценки очень высоки. И наоборот, пользователи могут хорошо выполнить задания, но дать невысокую субъективную оценку продукту.
3. Используйте то, что Вы узнали
Юзабилити-тестирование проводится не просто «для галочки» в графике проектных работ. На основе результатов юзабилити-тестирования команда должна сделать соответствующие выводы, установить приоритеты и внести изменения в прототип или сайт.
4. Найдите лучшее решение
Стоимость
Стоимость зависит от размера сайта, того, какой объём необходимо протестировать, сколько разных типов участников Вы хотите привлечь для тестирования и от того, насколько формально Вы хотите провести тестирование. Помните, что планировать бюджет нужно исходя не только из одного теста. Для того чтобы Ваш сайт отвечал требованиям удобства, необходимо проводить тестирование повторно.
Рассмотрим составляющие бюджета на юзабилити-тестирование:
Затраты на привлечение специалистов включают оплату работы штатных сотрудников или платежи нанятой фирме. Более дешёвым и менее трудоёмким является вариант разработки пользовательской базы данных либо привлечение рекрутинговой фирмы для проведения тестирования. Также нужно учитывать затраты на вознаграждения участникам тестирования.
Если у вас нет специального оборудования, Вам придется потратиться на аренду специального помещения и/или другой техники.
Если Вы решили заняться продвижением Вашего сайта, напишите нам.
Юзабилити-тестирование по шагам или оценка дизайна HCD
Перепроектирование сайта
Когда стоит проводить юзабилити-тестирование и что ему предшествует?
В случае уже разработанного сайта вопрос о проведении юзабилити-тестирования возникает, когда вы почувствовали или обнаружили, что с сайтом что-то не так. В любом случае необходимо установить Google analytics (книга: Google Analytics. Профессиональный анализ посещаемости веб-сайтов) или другой сервис для аналитики посещения сайта. О том, почему следует устанавливать такой сервис, я рассказывать не буду, так как тема уже давно исчерпана и не рекомендует устанавливать подобные сервисы только ленивый. После установки Google analytics у вас уже появляются конкретные данные о статистике посещений, местах входа и выхода посетителей сайта и другая информация.
Следующим шагом должно быть определение KPI (Wikipedia: Key Performance Indicators — ключевые показатели эффективности). Необходимо проанализировать, что важно для бизнеса, определить цели, которые должны быть достигнуты сайтам.
Пример: для кого-то это могут быть заказы товара, для кого-то обращения через форму обратной связи с какими-либо вопросами и т.д.
Если до этого момента рекомендации носили обязательный характер, то есть в любом случае данные шаги помогут в развитии и продвижении сайта, то далее уже идут рекомендации, в случае если вы действительно поняли, что сайт не эффективен.
Третьим шагом является уже непосредственное определение проблемных страниц и функций. Просто проводить юзабилити-тестирование неэффективно, необходимо понять, где возникают проблемы, на какой странице, с какой функцией, а потом уже проводить тестирование для определения, что именно не так на странице и как это решить. Опять же поможет Google analytics, тут можно определить, с каких страниц уходят пользователи, какие страницы игнорируются, и какие функции не используются.
Подготовка к юзабилити-тестированию
Итак, на данный момент уже определено, что сайту требуется перепроектирование, нашли страницы и функции, с которыми возникают проблемы у пользователей. Осталось дело за малым — понять, почему у пользователей возникают проблемы и как их исправить.
Четвертым шагом должно стать формирование гипотез по поводу того, что не так со страницей, и исходя из этого, необходимо определить метрики (Wikipedia: ISO 9126 — Оценка программного продукта), по которым будут тестироваться функции (есть метод экспертной оценки, при котором эксперт выдвигает гипотезы по улучшению интерфейса сайта и, исходя из них, происходит перепроектирование сайта, однако проверить, действительно ли эта гипотеза верна, можно только по итогу внедрения изменений, что влечет за собой большую цену ошибки).
Пример: с помощью Google analytics мы определили, что пользователи заходят на страницу регистрации, однако ее не проходят. Возможно, пользователи не могут понять, какую информацию вводить в поля или не знают, что делать дальше, после заполнения полей. Значит, нам необходимо протестировать данную страницу по метрикам понятности системных сообщений и эксплуатационной последовательности.
После определения метрик, по которым будем тестировать проблемные зоны на сайте, необходимо определить персонаж и сценарий работы (книга: Алан Купер об интерфейсе. Основы проектирования взаимодействия), по которому будет проводиться юзабилити-тестирование. Данный шаг необходим для привлечения нужных респондентов и выбора задания для юзабилити-тестирования. Если упустить этот момент, то респондент, который не является целевым пользователем, может с успехом пройти проблемную зону, а у пользователя, который действительно использует данную страницу, возникнут действительно большие проблемы. Итогом будет перепроектирование интерфейса без учета данных, а проблема останется. Точное определение сценария поможет дать респонденту правильное задание. То есть, если задание будет купить мобильный телефон, а респондент и вовсе не будет регистрироваться (а мы тестируем именно регистрацию), то юзабилити-тестирование бесполезно.
Примечание: подбирайте сценарий так, чтобы как можно больше было протестировано проблемных зон.
Далее идет подбор респондентов исходя из выбранного персонажа. Чем больше респондент соответствует портрету персонажа, тем лучше. Достаточное количество респондентов – 5-8 человек. В выборе количества я основываюсь на рекомендации Якоба Нильсена и собственный опыт.
Проведение юзабилити-тестирования
Непосредственно перед самим юзабилити-тестированием дайте респонденту заполнить анкету, чтобы проверить на соответствие необходимых характеристик у выделенного персонажа и респондента. Проведите вводный инструктаж, в ходе которого опишите контекст использования сайта и задание (книги: Веб-дизайн: книга Стива Круга, или «не заставляйте меня думать!»).
Пример задания: в поисках нового мобильного телефона вы, через поисковую систему, зашли на данный сайт. Найдите телефон, который вам необходимо (также попросите респондента описать телефон, который он будет искать).
Проведение самого юзабилити-тестирования (программа: Usability Studio) не такая, как кажется, сложная задача. Вам необходим ноутбук с камерой и несколько программ для записи движения пользователей и записи действий с экрана. Попросите респондента комментировать все его действия и эмоции. Как практика показывает, он и так это будет делать (и в этом нет ничего удивительного, ведь даже в домашней обстановке пользователи зачастую очень любят ругать или наоборот холить различные формы и другие элементы на сайтах).
После завершения тестирования опросите респондента о его впечатлении, с какими он трудностями сталкивался и что ему показалось неудобным. Данные опроса не рекомендую использовать как закон для изменения всего, что ему не нравится. К пользователям нужно прислушиваться, однако очень недоверчиво относиться к его субъективному мнению. Лучше, если по результату опроса появилась гипотеза о необходимости изменения интерфейсов, внесите еще один пункт в список проблемных зон и протестируйте ее в следующей итерации.
Обработка данных юзабилити-тестирования
Далее необходимо просмотреть собранные видео материалы, проанализировать результаты юзабилит-тестирования и определить требования к интерфейсу для перепроектирования (книга: Web-дизайн. Удобство использования Web-сайтов). Изменения, которые будут внесены, исходя из определенных требований, стоит проверить при следующем юзабилити-тестировании. Количество таких итераций во многом должно зависеть от целей и бюджета, выделенного на перепроектирование сайта.
Примеры: добавить подсказки в форму регистрации, выделить кнопку покупки, добавить поле “платформа” в форму подбора телефона по параметрам и т.д.
Проектирование сайта
Вариант количественного юзабилити-тестирования я не рассматриваю, так как оно позволяет определить общую эргономичность интерфейса, но не позволяет определить какие проблемы возникают, почему и как их исправить.
Как оценить частотность проблем найденных в ходе юзабилити тестирования? Кейс Циана
Делать количественные выводы по «качественному» юзабилити тестированию так себе затея. Если 5 из 10 пользователей столкнулось с проблемой — это не значит, что 50% пользователей с ней столкнутся. Но как быть, если очень хочется получить количественные данные по частотности проблем, выявленных в ходе юзабилити тестов? Рассказываю свой кейс на примере исследования проблем на форме подачи объявлений на Циан.
Предыстория
Изначально product owner пришел ко мне с запросом понять какие у нас сейчас есть проблемы связанные с формой подачи, так как аналитика показывала что воронка «хромает». До этого мой коллега делал экспертный аудит, но чтобы понять с чего начать работу по улучшению хотелось подтвердить его гипотезы об живых пользователей и, желательно, количественно.
К сожалению, аналитика показывала факт существования проблемы, но не могла подсказать ничего более конкретного, так как на тот момент мы ловили только 2 события:
А все что происходило между двумя этими событиями было для нас загадкой. Сейчас мы уже это исправили 🙂
Дизайн исследования
Итак, как понять что стоит починить в продукте и в как потом приоритизировать найденные проблемы?
Дизайн этого исследования состоял их двух ключевых этапов, которые шли в параллели:
Качественный этап
Изучение контекста возникновения проблем и ответ на вопрос «Почему?»
Я решила не просто провести обычный юзабилити тест, а провести сравнительное тестирование — сравнить нашу форму подачи с ключевыми конкурентами, чтобы понять на кого стоит ориентироваться. В качестве дополнительной метрики использовала USS (модифицированный SUS), чтобы оценить субъективную удовлетворённость.
Количественный этап
Изучение частотности возникновения проблем и ответ на вопрос «Как часто?»
Используя UX Feedback запустила кампанию по сбору активного фидбэка, чтобы выявить дополнительные проблемы в продукте, которые не подсветились во время тестирования и собрать количественные данные по частотности возникающих проблем
Про юзабилити тестирование
Респонденты были поделены на 2 ключевых сегмента:
Для каждой площадки подбирали респондентов без опыта взаимодействия с ней, оказалось что найти людей без опыта работы с Авито очень сложно 🙂
Для «опытных» заданием было повторить их путь и разместить объявление о продаже своей квартиры на площадке.
Для «не опытных» использовала метод «Боливуд», где респонденту нужно было помочь продать квартиру друга, находящегося в бегах заграницей.
Боливуд
В рамках работы в Циан я применяла этот метод уже в нескольких проектов и могу однозначно сказать, что он очень хорошо себя показывает!
Суть метода состоит в том, чтобы погрузить респондента в выдуманных драматический контекст, в котором ему будет необходимо сыграть роль.Корни этого метода лежат в задаче сломать социально-желательное поведение респондента и помочь ему говорить то, что он действительно думает.
По аналогии с методом генерации идей «идеи от третьего лица», вовлекаясь в спроектированный сценарий «Боливуда» респонденту также проще выражать свои эмоции и недовольство сервисом.
Про сбор обратной связи с сайта
Параллельно с проведением юзабилити тестирования я запустила и кампанию по сбору активного фидбэка.
Чем активный фидбек отличается от пассивного?
Пассивный фидбек. Обычно это кнопка пожаловаться в подвале сайта, или в «дальнем» разделе приложения. Туда валится фидбек на все элементы продукта без разбора, поэтому сортировка такого потока задача не из легких. Ключевое отличие от активного фидбека в том, чтобы написать отзыв через такую форму пользователю нужно иметь действительно серьезную мотивацию, поэтому обычно эти формы собирают только самые острые боли внутри продукта (причем не всегда самые репрезентативные).
Активный фидбек. Собирается на конкретном эпизоде пути пользователя. За счет встраивания опроса в пользовательский сценарий мы существенно увеличиваем конверсию в ответ (в нашем случае от 0,1% до 20%) и получаем свежий, горячий фидбэк не отходя от кассы — напрямую из контекста пользователя, а не из сконструированных лабораторных условий.
Кампания со сбору фидбэка
UXFeedback подружился с нашей Google Analytics, это позволило нам сразу сегментировать ответы пользователей на категории: риэлторы, собственники, не авторизованные.
Заходя на форму подачи пользователь через определённое время видел всплывающее окно с вопросом « Удобно ли размещать объявления на нашем сайте?» и вариантами ответа «Да, вполне!», «Нет, есть трудности».
А теперь магия! При выборе варианта «Нет, есть трудности» конверсия в расширенный текстовый ответ была 20%! За 2 недели мы получили 1000 текстовых ответов, с описанием конкретных проблем, с которым столкнулись наши пользователи на форме подачи. Для сравнения, когда мы запускали подобные кампании через Floctary (в этом инструменте отсутствует такая гибкая настройка событий), то, бывало, что за месяц мы собирали всего 6 ответов! Встраивание опроса в пользовательский сценарий в разы поднимает конверсию в ответ.
Комбинирование качественных и количественных результатов
Рейтинг USS (User Satisfaction Score) помог понять на каком месте мы находимся относительно конкурентов, чтобы решить насколько срочно нам вообще нужно бежать и чинить что либо.
Сегментация проблем
Обычно я сегментирую проблемы по 3-м категориям:
1. Критические ошибки
Критическими считаются те проблемы, которые блокируют выполнение пользовательского сценария и могут непосредственно влиять на успех заполнения формы подачи. То есть шанс того, что столкнувшись с этой проблемой пользователь уйдет с нашего сайта большой.
Барьер — это не техническая ошибка нашей платформы, то есть всё происходит как и было задумано, но пользователь все-равно может раздумать пользоваться нашей проблемой, если столкнется с ним. Барьеры негативно влияют на опыт использования продукта.
Упс! Тут пояснять не буду, баги у всех бывают. 🙂
Анализ текстовых ответов
Пожалуй был одновременно самый интересный и самый нудный этап. По завершению всех тестов, когда был понятен контекст возникновения проблем нужно было проанализировать 1000 текстовых ответов и распределить их по категориям для обнаружения частотности.
В итоге я определила частотность всех проблем обнаруженных в ходе юзабилити тестирования и обнаружила еще несколько критичных проблем и багов не выловленных на респондентах.
«Сшивание» данных и табличка вместо отчета
Заключение
Если ваши продакты вечно клянчат у вас количественное подтверждение и уже надоели вам с вопросом «А сколько пользователей столкнулось с этой проблемой на тесте? » — то возможно вам стоит повторить описанный мной эксперимент. 🙂
Что еще можно сделать?
Комбинировать количественный и качественный сбор данных в рамках одного исследования — хорошая практика. Но если говорить про масштабирование этого метода, то мне кажется что его можно и нужно оптимизировать с помощью CJM.
У многих есть CJM, но мало кто с ним действителньо работает. Мне кажется очень хорошей историей запускать кампании по активному сбору фидбека на ключевых эпизодах пути пользователя, чтобы:
А. Собирать клиентские метрики по каждому эпизоду
Многие собирают NPS, но что нам дает эта «средняя по больнице » цифра? Как понять что и где стоит улучшить, чтобы вырастить эту цифру? Собирая CES (Customer Effort Score) или CSAT (Customer Satisfaction) на конкретных эпизодах мы сможем понять где конкретно и почему в продукте возникают проблемы.
Б. Точечно собирать фидбек по отдельным элементам/функциям продукта
Убиваем двух зайцев одним ударом: экономим время на категоризацию (собираем фидбек только по нужной нам теме) и вовлекаем пользователя оставить отзыв (за счет встраивания в сценарий получаем более высокую конверсию в ответ). Например, выкатили новую функцию — добавили опрос, сразу собрали «горячий » фидбэк; или появилась гипотеза — сделали опрос, собрали данные напрямую из контекста.
Лично я вижу такой подход одним из наиболее перспективных для формирования целостного взгляда на продукт и отслеживания изменений в пользовательском опыте.
Как собирать данные и анализировать юзабилити-тестирования
Заключительная часть серии статей от AIC о том, как анализировать ю-тесты
В прошлой статье мы писали, что на юзабилити-тестировании приоритетнее записывать действия респондента, а мнение и комментарии — по возможности. Вы можете вести записи во время тестирования и/или после по видеозаписи.
Выбирайте наиболее удобный и эффективный для вас формат сбора данных. Собирать их вы можете на стикерах, бумаге, в протокол или электронный документ.
Для записи на чистую бумагу запаситесь достаточным количеством листков и ручек, чтобы не пришлось сбегать с интервью. Помечайте вопрос, который вы задаете респонденту, затем записывайте его действия, ошибки и особо эмоциональные комментарии.
Другой вариант записи данных от руки: распечатайте сценарий вашего интервью на половину страницы, а данные записывайте на вторую половину. Старайтесь записывать данные в едином формате для всех респондентов, чтобы потом было просто соотнести их между собой и сделать выводы.
К примеру, вы можете разделить листок или документ на несколько частей в соответствии с шагами, который выполняет пользователь на сайте или в приложении. Напротив каждой такой части фиксируйте наблюдения за всеми респондентами. В итоге получите табличку, в которой будут уже рассортированные наблюдения, по которым легко будет делать выводы о каждом задании и шаге.
Первые два варианта подойдут тем, кто уверен в своем почерке и скорости письма. Альтернативой является запись в документ на компьютере. Для протокола лучше всего использовать табличку, в первом столбце которой будет сценарий интервью, а в других столбцах записи за респондентами.
Во время интервью записывайте пошагово действия и слова респондента. Не пытайтесь интерпретировать, давать оценку его действиям и словам. К примеру, если пользователь несколько раз пытался ввести свой пароль, есть соблазн написать: «Не понимает подсказку как создать пароль». Записывайте только факты: «Три раза пытался создать пароль, не получилось». Со словами так же — записывайте прямую речь, не делая выводов.
После тестов собирается достаточно много записей, особенно если у вас было больше 10 респондентов. Поэтому постарайтесь сначала выделить основные сложности, с которыми столкнулись участники исследования на каждом шагу. Следом найдите комментарии (пользовательскую оценку) респондентов по каждому этапу и в целом по отношению к продукту. Для каждого пункта таблицы анализируйте собранные данные и составляйте выводы.
К примеру, если несколько человек не смогли или не сразу придумали правильный пароль, то можно это выделить в проблему: «Пользователи не понимают, как составить пароль».
Если у заказчика были конкретные вопросы до исследования, найдите в данных ответы на них и отметьте, чтобы потом внести в отчет или презентацию. Данные нужно тщательно отобрать и интерпретировать их, исходя из контекста — ответ пользователя всегда зависит от его персональной ситуации, и при выводах нужно учитывать все детали.
К примеру, человек говорит, что не будет пользоваться авторизацией через соцсети. Причинами могут быть:
При любом из этих ответов мы не можем однозначно ответить: убирать такую авторизацию, оставить или изменить ее. Нужно разбирать ситуацию каждого респондента, чтобы не сделать неверных выводов на основании его ответов. И затем, при необходимости — проверять это на большой аудитории продукта.
Итак, вы провели интервью и собрали все данные. Проведите их анализ и сделайте выводы. При анализе записанных интервью смотрите каждый шаг заданий по каждому респонденту и группируйте наблюдения по общим темам. Прочитав все наблюдения по одной теме, постарайтесь сделать общие выводы для всех респондентов.
Проставьте в таблице оценку успешности прохождения сценариев каждому респонденту в зависимости от его ошибок: от «не выполнено» до “выполнено успешно”. После этого оцените, какие из заданий или шагов тестирования оказались наиболее проблемными и сложными для прохождения — о них стоит сообщить команде и заказчику в первую очередь.
Также в процессе тестирования отмечайте: какими путями при прохождении сценариев респонденты пользуются чаще, какие элементы вызывают положительную оценку или упрощают прохождение заданий. Это пригодится при редизайне, для планирования элементов и принятия решений о выборе ключевых их них.
После того, как вы выделили темы и собрали проблемы, не забудьте оценить их по критичности прохождения сценария исходя из того, как они влияли на респондентов:
Если в ходе тестирования респондент столкнулся с неинтерфейсными проблемами, их стоит вынести в раздел инсайтов. Инсайты — это знания, которые вы получили во время интервью или тестирования, но которые не относятся напрямую к интерфейсу. Здесь содержатся знания, которые могут быть полезны представителям бизнеса в целом и сделают отчет интересным не только команде продукта.
К примеру, респонденты отказываются оформлять заказ, потому что нет возможности оплатить заказ при получении. Стоит сообщить об этом команде и проверить с аналитиками, сколько пользователей уходит на этапе оплаты.
Выпишите полученные проблемы и инсайты исследования в отдельную табличку по каждому заданию и шагу — это содержание основной части вашего отчета. Такой список можно дополнить пояснениями, которые помогут другим членам команды понять, в чем конкретно состоит проблема и что происходило с пользователями при прохождении сценария.
Мы всегда делаем комплексные работы — с дизайном и A/B тестами. Поэтому важно понятно донести полученные результаты до команды, чтобы внести правильные изменения в интерфейс и протестировать их на большей выборке.
В создании отчета принимает участие специалист, проводящий исследования, ведущий UX-специалист с экспертными знания в отрасли, менеджер продукта и дизайнер (на случай, если нужна помощь в отрисовке макетов).
Отчет помогает членам команды и заинтересованным лицам узнать о недостатках продукта и точках роста. Также он помогает сравнить результативность продукта по прошествии нескольких итераций и отследить изменения.
В зависимости от целей исследования отчет также может включать в себя план развития продукта:
Если команда торопится с внедрением изменений в продукт или не нуждается в оформлении результатов — их можно презентовать команде, обсудить и передать в работу.
Для внешних заказчиков или руководства лучше составлять отчет или презентацию, в которых будет рассказано все об исследовании с самого начала. Текст отчета должен быть максимально простым, конкретным и поясняющим. Старайтесь писать его как будто для людей, которые никогда не слышали про юзабилити-тестирования, про детали продукта и его возможности. Для наглядности добавьте скриншоты.
Начните отчет с описания тестируемого продукта, целей тестирования и вопросов, которые были до тестирования. В начале отчета должно быть описание самого исследования: как и где оно проводилось, на каких сегментах ЦА.
Основная часть отчета состоит из описания инсайтов, проблем интерфейса и рекомендаций по их решению. Сделайте выводы:
Часть проблем может быть известны из данных аналитики или данных заказчика. В отчете эти проблемы следует раскрыть максимально, чтобы затем минимизировать уход пользователей.
К примеру, из данных аналитики мы знали, что анкета является узким местом на пути оформления покупки билетов. Поэтому в исследовании необходимо узнать, в чем причина проблемы.
Постарайтесь разобраться в каждом случае: почему проблема возникла, как сильно она нарушает сценарий, какие неверные или лишние действия совершают респонденты в процессе. Это поможет вам понять, какое решение позволит ликвидировать или снизить влияние проблемы.
В описании проблемы напишите, как она проявлялась во время тестирования (что делали респонденты), вставьте скриншот экрана, на котором есть эта проблема.
Опирайтесь на действия респондентов, а не на их слова, потому что часто это не совпадает. Например, респонденты не могут выполнить задание или выполняют его неправильно, но при этом говорят, что сайт удобный и понятный.
Старайтесь к каждой проблеме и инсайтам сформулировать рекомендацию. Это может быть текстовая рекомендация. Например, исправить верстку или оптимизировать скорость загрузки страницы. Либо это может быть макет элемента или целой страницы, или страница в дизайне. При этом визуальные рекомендации следует описывать: что сделали, что изменилось.
Если мы проводим юзабилити-тест с последующим A/B тестированием, на финальном этапе мы приоритезируем гипотезы, чтобы определиться с очередностью их запуска. Мы обсуждаем в команде с аналитиками все проблемы и оцениваем каждую гипотезу по нескольким критериям (обычно мы применяем PIE-фреймфорк):
После этого согласовываем список с заказчиком, поочередно выкатываем гипотезы на A/B тестирование и замеряем их эффективность.
Автор — Александра Вязовик, UX-исследователь в AIC