В2В • web • project management
Nocode. Конструктор сервисов
Конструктор готовых компонентов для создания заявочных
онлайн-сервисов без кода.
Проблема
Была негативная обратная связь от пользователей, потому что команда не валидировала существующие решения на пользователях. Бэклог опирался на предположения команды, а не на данные пользователей.
Проблемы в продукте, которые озвучивал дизайн, не попадали в приоритет разработки.
Результаты
Чтобы сформировать обоснования для команды, я инициировала исследование: интервью + опрос об удобстве продукта.
Выявила 6 основных проблем в работе с продуктом.
Из интервью и количественного опроса.
Команда получила данные о том, как пользовательские проблемы влияют на ключевые метрики продукта:
Time to Value, Time on Task, Error Rate и Completion Rate.
Это помогло подчеркнуть необходимость улучшения существующего пользовательского опыта.
Реализовала часть задач, заведённых после исследования. Более подробно описала ниже ↓
Конструктор страниц: настройка баннера
Интервью с пользователями
+ опрос
Перед стартом сформулировала гипотезы о возможных проблемах в работе с продуктом.
На их основе я подготовила бриф для глубинных интервью — выяснить, какие боли реальны и почему.
Затем провела опрос, чтобы понять, насколько часто каждая из них встречается.
13
Прошли интервью
100
Прошли опрос
Презентация команде, приоритезация
Результаты презентовала команде: проблемы, метрики и мои предложения.
Совместно с командой отсортировали проблемы по формуле:
Коэффициент приоритета
=
Ценность для бизнеса
Сложность разработки
В результате получили коэффициент, который показывает, что стоит брать в первую очередь.
Проблема
Гипотеза
Метрики
Коэффициент
Погружение
77% тяжело погружаются в продукт; освоение занимает от недели.
Если новичок начинает с готового шаблона, а не с пустого холста, то Time to Value до первого опубликованного сервиса у новых пользователей значимо снизится.
Если пользователь встречает новый функционал с подсказкой в нужный момент, а не разбирается самостоятельно, то Time to Value значимо снизится.
Time to Value
Время до первого собранного сервиса
3/2 = 1.5
Сложные настройки, неудобная справка
Настроек много и они сложные.
А инструкция по применению — отдельный большой файл, где трудно найти нужное.
В интерфейсе всё не объяснить, а пользователю не запомнить.
Если новичок может разобраться с незнакомым функционалом через встроенную справку, не обращаясь к коллегам или в поддержку, то Time to Value до первого опубликованного сервиса значимо снизится.
Если пользователь получает инструкцию прямо в точке настройки, не уходя в отдельный файл, то Time on Task настройки значимо снизится.
Если пользователь сверяется с инструкцией в момент настройки,
а не действует по памяти, то Error Rate на сложных элементах значимо снизится.
Если пользователь получает ответ в момент настройки, то Completion Rate настройки значимо вырастет.
Time to Value
Время до первого собранного сервиса
Time on Task
Время настройки сценария
Error Rate
Ошибки сборки сценария
Completion Rate
Доля пользователей, доведших задачу до конца
3/2 = 1.5
Нет поиска по сценарию
Чаще всего нужно найти все места применения конкретного элемента — приходится искать вручную, что замедляет работу и раздражает.
Если пользователь находит нужный элемент через поиск, а не проходит сценарий вручную, то Time on Task поиска элемента значимо снизится.
Если пользователь видит все места применения элемента через поиск, а не находит их вручную, то Error Rate сборки сценария значимо снизится.
Time on Task
Время настройки сценария
Error Rate
Ошибки сборки сценария
3/2 = 1.5
Роли в сценарии
Часты ошибки сборки сценария из-за отсутствия привязанных ролей к шагу или переходу.
Если система подсвечивает шаги и переходы без привязанной роли, то Error Rate ошибок сборки из-за отсутствия роли значимо снизится.
Если система подсвечивает шаги и переходы без привязанной роли, то Time on Task сборки сценария значимо снизится.
Time on Task
Время настройки сценария
Error Rate
Ошибки сборки сценария
3/3 = 1
Применение "костылей"
70% не закрывают свои потребности текущим функционалом. Из-за этого ошибки прячутся в lowcode и их трудно найти, чужой процесс сложно подхватить, один и тот же функционал реализуют по-разному.
Если на сценарии визуально помечены места с lowcode-вставками, то Time on Task значимо снизится.
Если пользователь сразу видит, где в сценарии lowcode-вставки, то Error Rate при доработке чужого сценария значимо снизится.
Time on Task
Время настройки сценария
Error Rate
Ошибки сборки сценария
3/3 = 1
Проектирование ролевой
Неочевидно, что ролевую нужно спроектировать самому до настройки — придумать права и роли даже для простых кейсов с двумя ролями.
Если пользователь выбирает готовый шаблон ролевой модели вместо проектирования с нуля, то Time on Task её настройки значимо снизится.
Time on Task
Время настройки сценария
1/3 = 0.33
+ Churn Revenue
Для всего продукта
Решения и результаты
Поиск по сценарию.
Результаты
Коэффициент: 3/2=1.5
↓ Time on Task
Элемент в большом сценарии находится за секунды.
По результатам юзабилити-тестирования.
↓ Error Rate
Меньше дублей.
Раньше элемент пересоздавали, потому что не могли найти существующий.
Меньше «костылей».
Часть «костылей», которые делались ради навигации, отпала — нужное теперь находится поиском.
Поиск по «всем местам применения» элемента снизил количество ошибок сборки сценария
Раньше находили не сразу и правили не везде.
Справка
Коэффициент: 3/2=1.5
В работе над задачей вместо статичной справки сделала
ИИ-чат: пользователь описывает проблему своими словами и получает инструкцию, подсказку и ссылку на нужный раздел руководства.
↓ Time to Value
Новичкам проще погружаться в продукт.
Можно разобраться самостоятельно, переписываясь с ИИ-помощником.
↓ Time on Task
Инструкция под рукой в момент настройки.
Не нужно уходить в отдельный файл и искать там нужный раздел.
↓ Completion Rate
Пользователь чаще решает задачу сам.
Частые вопросы закрываются в момент настройки, без ухода в поддержку.
↓Error Rate
Меньше ошибок в сборке сценария.
Пользователь сверяется с инструкцией прямо в момент настройки, а не по памяти.
Моя роль
Инициировала исследование
В команде не было исследователей, а дизайну нужно было обоснованно донести свою позицию.
Спроектировала методологию
Вначале глубинное интервью (почему болит), затем количественная проверка частоты опросом.
Презентовала итоги исследования команде
Обратила внимание команды к проблемам и необходимости их решать. Совместно с командой приоритезировали проблемы и выделили итоговые решения.
Реализовала часть задач, заведённых по итогам исследования
Часть из них вели два других дизайнера.
Давайте создавать классные вещи вместе
Эта страница доступна только в десктопной версии
Макеты содержат много деталей,
поэтому на мобильном устройстве их будет неудобно просматривать.
Эта страница доступна только
в десктопной версии
Макеты содержат много деталей, поэтому на этом устройстве их будет неудобно просматривать.