Как мы измеряли удовлетворенность пользователей дизайн‑системой

от автора

Как и классические продуктовые команды, команда ДС формирует задачи из разных каналов, таких как:

  • Требования бизнеса (от стейкхолдеров)

  • Собственный вижн

  • ОС от пользователей

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

Как выглядел сбор ОС ранее

Раз в квартал мы присылали гугл-опросник разработчикам и дизайнерам с набором вопросов и просьбой оценить от 0 до 10 работу с ДС (NPS).

То, как выглядели оценки и сколько человек проходило опросы...

То, как выглядели оценки и сколько человек проходило опросы…

Насколько тебе понятно, как использовать Kite?

Хватает ли тебе компонентов и их возможностей для разработки своих фич?

Как ты оцениваешь качество компонентов Kite?

С какими трудностями ты сталкиваешься при использовании дизайн-системы?

 и т.д…

В общем, около 11 вопросов, к каждому — поле с комментарием, а некоторые вопросы ещё и подразумевали несколько вариантов ответа.

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

Спросим всех!

Мы решили опросить лично каждого пользователя и начали с дизайнеров.

Немного изменили основные вопросы. К тому же появилась возможность задавать доп-вопросы и вытягивать инфу. Чуть позже нашли лайфхак: просить продемонстрировать UI kit в Figma и пройтись по компонентам. В таких случаях пользователь вспоминал моменты, которые уже забыл. По сути, задача была сбайтить на разговор 🙂 И дальше песнь лилась, а нам оставалось только фиксировать всё на стикеры и группировать.

(Пример отчета по каждому опрошенному)

(Пример отчета по каждому опрошенному)

Сначала мы распределяли все инсайты на 5 групп:

  1. Онбординг — как быстро вливались, что было непонятно на старте.

  2. Ежедневное использование — какие проблемы испытывают прямо сейчас, «каждый день».

  3. Взаимодействие и коммуникация — насколько быстро узнают про обновления и получают ответы на вопросы. Короче, блок про качество саппорта.

  4. Ценность и эффективность — тут мы пытались понять, как они сами оценивают TTM: быстрее ли фичи едут в продакшн или нет.

  5. Будущее и хотелки — собирали хотелки и идеи 🙂

У 4-го и 5-го блоков изначально были свои вопросы для получения оценки, но мы от них отказались — они показались нам странными и слишком абстрактными.

Что узнали:

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

Как выглядит сбор ОС теперь:

Мы зафиксировали 3 параметра, которые будем замерять:

  • Онбординг

  • Каждый день

  • Коммуникации

Глубинные интервью (те самые тет-а-теты) решили проводить раз в полгода, пока не улучшится динамика гугл-опросов (спойлер: следующий опрос прошли уже в 2 раза больше пользователей!).

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

ссылка на оригинал статьи https://habr.com/ru/articles/1050662/