Опыт пользователя — понятие составное. В случае с ИТ-продуктами это и про логику интерфейсов, и про типографику, и про специфику дизайн-системы; наконец, в целом про то, как клиент воспринимает продукт, начиная с этапа его поиска/приобретения.

На уровне отдельных аспектов оценивать UX, UI и CX нам помогают те или иные виды исследований. Но когда речь идёт о разноплановых продуктах с различными пользовательскими сценариями, задумываешься об унификации. Возникает вопрос: можем ли мы оценивать опыт пользователя комплексно — по единым критериям и в рамках одной методологии?

В Сравни для решения этой задачи мы разработали и внедрили Product Score — скоринговую модель оценки UX, UI и CX. С её помощью получаем независимую оценку продуктов, формируем конкретные гипотезы по развитию пользовательского опыта и пополняем бэклог улучшений.  

Под катом рассказываем, как устроен наш Product Score. И подробно раскрываем методологию оценки на практических примерах.


Привет, Хабр! Меня зовут Светлана, я UX-исследователь в Сравни. В компании у нас больше 50 команд — продуктовых и сервисных, и многим из них периодически нужны исследования. В рамках нашей UX/CX-лаборатории мы помогает коллегам решать подобные задачи. Проводим Discovery-исследования для выхода на рынок новых продуктов, изучаем сегменты пользователей, тестируем на респондентах изменения функциональности в интерфейсах. 

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

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

Структурно мы относимся к департаменту дизайна, и над UX/CX-улучшениями работаем вместе с дизайнерами. Это позволяет не упускать исследования из процесса разработки там, где это нужно. Например, благодаря общим синкам мы в курсе планов по дизайну и предлагаем протестировать юзабилити, если флоу пользователя заметно меняется.

Что такое Product Score и зачем он нам понадобился?

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

Это и стало предпосылкой к созданию единой метрики. Нам хотелось системно и централизованно отслеживать качество пользовательского опыта в случае с самыми разными продуктами; по единым критериям и в рамках единого процесса. 

Плюс, поскольку продакты «мыслят цифрами», часто UX-проблемы ускользают из фокуса внимания команды — в силу того, что мало людей из качественной выборки с ними столкнулось. Бывают ситуации, когда часть флоу вообще может быть не протестирована на пользователях: заказов в лабораторию команда по ней не делала, а самостоятельно проверяет только всё новое. Это натолкнуло нас на мысль, что было бы неплохо иметь инструмент для проактивного влияния на продукты — без необходимости предварительного заказа на дизайн или исследования со стороны коллег. 

Так родилась идея разработать скоринговую модель оценки UX/CX/UI: внутри команды мы назвали её Product Score. Решили, что это должна быть именно числовая метрика, чтобы можно было отслеживать её динамику во времени и сравнивать продукты нашего портфеля между собой — по уровню качества пользовательского опыта и интерфейса.

В результате внедрения Product Score мы хотели научиться делать независимую оценку UX/UI/CX любого продукта в компании, получая при этом не только цифру, но и конкретные гипотезы по улучшению пользовательского опыта. А ещё получить бэклог улучшений и приоритизировать его по критичности для пользователя и сложности разработки.

Как устроен Product Score?

Это скоринговая модель, состоящая из двух частей: UX/CX и UI-оценки.

1. UX/CX-часть (далее: UX-часть) предполагает прохождение полного флоу продукта с респондентами, включая его покупку и использование, коммуникации в процессе. Эту часть проводит исследователь, и по сути она выглядит как немодерируемое юзабилити или демо.

2. UI-часть — ревью UI по заданным критериям от дизайнера, который относится к другой команде (для объективности) и не зафреймлен продуктовым процессом конкретного сервиса.

Результаты UX-части выглядят похоже на CJM (Customer Journey Map), в котором есть слои:

  1. Этапы и шаги — количество этапов будет важно нам позже для расчёта формы, чтобы продукты разной «длины» (от витрины до полной сделки) имели сравнимую и справедливую оценку.

  2. Экраны — для визуального понимания найденных триггеров и барьеров.

  3. Триггеры — позитивные реакции и комментарии респондентов

  4. Барьеры — самый важный для расчёта скора элемент; проблемы, которые мешают пройти флоу успешно, их мы классифицируем по 3-м уровням:

    - Высокой критичности (коэффициент проблемности: 10) — приводят к срыву сценария, являются причиной невозврата в сервис; либо прохождение пути было невозможно без помощи модератора.

    - Средней критичности (коэффициент проблемности: 5) — приводят к уходу респондента с пользовательского пути, либо сильно влияют на скорость и удовлетворенность при выполнении задания, либо приводит к ошибкам при выполнении задания.

    - Низкой критичности (коэффициент проблемности: 1) — влияют на скорость и удовлетворенность при выполнении задания, но не приводят к срыву сценария и ошибкам при выполнении респондентом задания.

    Далее в формуле барьерам присваивается коэффициент проблемности: таким образом барьер высокой критичности в 10 раз сильнее повлияет на итоговый скор, чем барьер низкой критичности.

  5. Нативность — паттерн поведения респондента, который может быть любопытен команде продукта: какие решения принимает пользователь во время взаимодействия с продуктом или сервисом и почему?

  6. Оценка пользователя — в конце теста мы просим оценить по пятибалльной шкале два показателя:

    - Удобство — как пользователь оценивает удобство сервиса, с которым познакомился

    - Скорость — насколько быстро все прошло относительно его ожиданий

    Эти оценки также попадают в формулу расчета скора.

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

  1. CJM, интуитивность и логика

  2. Типографика, шрифты и тексты

  3. Анимации

  4. Графика

  5. Единообразие, соответствие дизайн-системе

В итоге оцениваем каждый кумулятивный критерий по шкале от 0 до 5 баллов, где 5 баллов — если все критерии первого порядка соблюдены, а 0 — не соблюден не один из критериев.

Примеры оценки по критериям
Как выглядят UI-рекомендации

В итоге на скор влияют четыре основные показателя:

  1. Насколько далеко по флоу смог пройти каждый респондент — по итогам тестов этот показатель значительнее всего влияет на расчёт, что кажется нам справедливо отражающим реальность. Так как коррелирует с воронкой и метриками непосредственно.

  2. Количество и критичность найденных с респондентами барьеров

  3. Субъективная оценка респондентами скорости и удобства 

  4. Оценка UI по заданным критериям

Итоговый скор может принимать значения от 0% до 100%, где 100% — идеальный сервис/продукт, а 0% — его отсутствие или нерабочий вариант. Все найденные недочёты и барьеры снижают оценку на определенный коэффициент. 

В итоговой оценке UX-скору отдается вес 75, а UI — только 25%, поскольку считаем, что прохождение флоу на реальных респондентах и успех выполнения целевой задачи значительнее отражает качество продукта для пользователя в целом.

Углубляемся в Product Score: формулы и цифры

Так выглядит наша модель расчета Product Score: 

Заполняем в ней только зелёные ячейки, остальное рассчитывается по этим данным:

  • Этапы в продукте — сколько этапов в целевом флоу продукта при полном его прохождении. Этапом считаем крупный шаг в воронке, например: анкета, выдача, оформление, погашение и т. д.

  • Количество найденных проблем/барьеров — переносим из артефакта по результатам прохождения флоу с респондентами. Заполняем по каждому уровню критичности и по респонденту отдельно.

  • Оценка респондентов — заполняем ответы респондентов, так получаем общий скор за оценку пользователей. За каждый сниженный балл уменьшаем скор на 10%. Например, если респондент дал оценки 5 и 4, его скор составит 90%, если тройки — 60%.

  • Коэффициент успеха — если у респондента получилось пройти до начала третьего этапа, (например, анкеты), но срыв сценария произошел в процессе ее заполнения, то считаем, что он дошел до 3го этапа. 3 из 5 этапов дают коэффициент успеха в размере 60%, так как 5 этапов считаем за 100%, и снижаем их пропорционально при срыве сценария. Если респондент прошел дальше с помощью и по просьбе модератора и произошло несколько срывов сценария на пути, в формуле учитываем первый из них.

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

    Например, если было две критичные проблемы, 11 средних и 21 — низкой критичности, то получаем 2*10+11*5+21*1 = 96. Балл проблемности на этом этапе будет равен 96/5 = 19,2. Значит, коэффициент проблемности респондента составит 81,8%.

Для получения UX-скора каждого респондента: берем скор за оценку пользователей и умножаем на коэффициенты успеха и проблемности, которые имеют значения от 0% до 100%.

Далее считаем средний UX-скор по всем респондентам (чтобы избежать искажения при разном количестве респондентов в разных продуктах при будущем сравнении скора). Наконец, умножаем средний UX-скор на 75% (это вес UX-скора в общей оценке) и получаем оценку UX/CX-части, которая в максимуме может составить 75%.

В случае с оценкой UI: переносим оценку из UI-ревью и получаем показатель UI-скора, который, по аналогии, может составить 25%. Каждый недополученный балл снижает UI-скор на 1% (всего можно получить 25 баллов — по 5 в максимуме для 5 критериев).

Теперь несложно прийти к финальной оценке: 

Product Score = UX Score + UI Score

Вот синтетический пример рассчитанного скора для продукта, где данные похожи на реальные:

Подробности процесса: фиксируем опыт пользователя

Как выглядит классический кейс с оцениванием UX/UI/CX по нашей методологии?

Берём для примера реальную целевую аудиторию продукта — людей, которым требуется купить ОСАГО, и проходим с ними весь путь: от поиска нужного сайта до покупки и использования страховки.

Количество респондентов зависит от количества сегментов. На каждый сегмент мы берём по шесть человек. Сегмент определяем исходя из отдельного флоу, который требуется пользователю в том или ином сценарии: например, первоначальная покупка страховки или пролонгация — два разных флоу, поскольку процесс выглядит по-разному для таких пользователей. Значит, в скоре будет два сегмента, итого: 12 человек.

1. Тестируем продукт/сервис с респондентами

Тест проводим на проде и на реальных данных пользователей.

С каждым респондентом встречаемся по два раза: сперва для покупки, затем — чтобы оценить последующий опыт: какие были коммуникации со стороны сервиса, был ли спам от конкурентов?

Тест проводим немодерируемо, даём только одно задание: воспользоваться услугой или оформить покупку. Чтобы пользователь мог оценить скорость выполнения задачи реалистично, а мы — отловить все барьеры, с которыми он сталкивается без помощи модератора. Вмешиваемся, только если произошел срыв сценария, чтобы помочь респонденту и посмотреть оставшийся участок флоу (при технической возможности).

Помимо исследователя и дизайнера приглашаем на тесты и остальных представителей команды. Это позволяет не только быстро исправлять ошибки, но и погружать команду в «реальность пользователя».

На основе анализа опыта респондентов мы планируем и внедряем изменения.

Примеры UX-изменений в одном из наших сервисов после Product Score
  • У респондентов возникли трудности с выбором нашего целевого флоу среди опций по займам в меню (так как есть несколько точек входа и разные продукты — витрина/полная сделка):

  • Часть респондентов не смогла выбрать подходящий тип занятости и пройти дальше:

     

  • Респондентам было сложно найти оформленные займы: 

  • И досрочно их погасить:

2. Передаём результаты

Рассказываем о результатах команде, бизнес-оунерам, а также партнерам. Некоторые наши сервисы содержат части флоу, которые проходят на стороне наших партнеров, и для пользователей здесь нет концептуальной разницы: изначально они приходят к нам и в будущем ассоциируют весь полученный опыт с компанией Сравни.

3. Отслеживаем внедрения

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

Проводим трекинг прогресса в Jira по внедрениям и периодические синки при необходимости.

К чему пришли и что ещё планируем

Глобально работа с Product Score позволила нам оптимизировать цикл внедрения доработок и изменений в продукты компании. Часть проблем, которые проявляются на тесте, команды устраняют прямо в момент проведения оценки. 

В свою очередь партнеры оперативно устраняют барьеры на своей стороне, о которых мы им сообщаем (благодаря Product Score коммуникация с ними в целом стала более систематизированной). 

В ближайшее время планируем отслеживать прогресс метрики Product Score во времени по основным продуктам — и проводить её раз в год или в другой период, если накопится критическая масса изменений. Плюс провести Product Score по всем нашим основным продуктам (на данный момент провели для команд ОСАГО и МФО, а также Product Score некоторых конкурентов).

Но уже сейчас наши дизайнеры и исследователи счастливы: благодаря Product Score они могут проактивно влиять на продукт, без запроса на дизайн или исследование от команд. А бизнес — доволен тем, что продукты развиваются с учётом реальных потребностей их аудитории.

Комментарии (0)