В этой статье поговорим о таких вещах: почему сделать IT-продукт, который будет отвечать запросам клиентов принципиально важно в enKod, с помощью каких инструментов выявить запрос клиента и что делать, если пользователь не использует функционал, который сам просил?
Структура статьи: рекомендация по теме (записывайте, скриньте и сохраняйте) + вопросы Насте Аниськовой (CPO enKod) по тому, как это реализуется в enKod.
Настя Аниськова
CPO enKod
1. Все начинается с понимания целевой аудитории: кто они, какие у них потребности и что они ожидают от продукта
— Кто мы такие? Кто наши клиенты? Какие у них потребности и ожидания?
Мы, CDP платформа enKod — помогаем бизнесу удерживать привлеченных клиентов, мотивировать их на повторные покупки и делать более лояльными к бренду с помощью email, sms, push. (и теперь еще whatsapp)
У нас можно строить визуализированные цепочки, отслеживать действия пользователей на сайте и видеть в платформе выручку с покупок. Растить базу с помощью всплывающих окон. И увеличить конверсию в покупку на сайте или в email с помощью модуля товарных рекомендаций.
И всё это в одном окне с понятным интерфейсом, реально понятным.
Наши клиенты: Лукойл, Университет Синергия, LinguaLeo, Периодика, TutGood и др. приходят к нам с запросом либо на автоматизацию ретеншен-маркетинга (набор инструментов для удержания клиентов компании и формирования их лояльности), либо на оптимизацию каналов в едином сервисе. И, конечно, с запросом увеличить текущую выручку за счет новых каналов или механик в коммуникации с клиентами.
2. Создание удобного и интуитивно понятного интерфейса продукта
– Почему нам важно создать удобный интерфейс для клиентов?
Мы очень часто слышим, что одним из наших главных плюсов является понятный интерфейс. Честно скажу, мы этим очень гордимся. На первый взгляд может показаться, что это не играет особой роли, так как не влияет на коммуникацию наших клиентов с их пользователями. Но в случае, когда ты пользуешься каким-либо инструментом 5 дней в неделю по нескольку часов, отзывчивость и понятность имеют большое значение.
Весь новый функционал или расширение текущего мы пытаемся встроить максимально гармонично. По возможности шлифуем нелогичности и несостыковки. Добавляем как можно больше пояснений, чтобы не пришлось по сто раз спрашивать менеджера, что делает та или иная кнопка.
Хотя, справедливости ради, однажды мы слышали от потенциального партнера по интеграции, что «интерфейс, пояснения и красивые кнопки — это бесполезная трата ресурсов. Вот у нас интерфейса почти нет, зато сколько всего реализовано!». Мы не согласны с таким подходом. Не стоит забывать, что сервисом пользуются люди, а не роботы. Визуальный комфорт, понятность и максимальная простота — то, что заставляет тебя без боли и страданий выполнять рутинные задачи. Это ли не главное?
3. Использование методов юзабилити-тестирования для определения проблем пользователей с интерфейсом
— Какие виды тестирования у нас есть? Как проводим исследование или тестирование?
Иногда крупные задачи (новые модули, сложный функционал) требуют проведения юзабилити-тестирования, так как нашего с дизайнером предвзятого отношения бывает недостаточно для выбора лучшего варианта реализации.
Мы проводим тестирование разных видов:
1) Это могут быть опросы, даже без макетов в текстовом виде, чтобы узнать, пользуются ли клиенты тем или иным функционалом. И, если пользуются, то как именно.
2) Или коридорные тестирования с прототипом, повторяющим почти полностью интерфейс сервиса и позволяющим воспроизвести все механики, которые нам требуется оценить.
Прим. Коридорное тестирование — один из самых простых видов тестирования, при котором тестировщик может проверить макет или прототип своей программы на случайных людях.
Само коридорное тестирование на прототипах представляет собой краткое описание функционала, задание, которое необходимо выполнить пользователю, прототип и вопросы после выполнения.
Иногда дизайнер готовит несколько вариантов реализации одного и того же функционала. Задачи, выполняемые на прототипах, похожи, а в конце пользователю необходимо будет отдать свое предпочтение одной из версий и объяснить свой выбор.
Респондентами обычно выступают аккаунт-менеджеры и наши клиенты. Тестирование (особенно на прототипах) — это довольно утомительная по подготовке и длительная по срокам работа. Но очень часто результат может быть противоположен нашим ожиданиям. Так, например, было с enRecom — выбран был тот вариант, который понравился нам меньше всего, зато для пользователей был более понятным 🙂
Предложенный вариант.
Текущий, выбранный клиентами.
Если честно, даже простой тест в гугл опросах на 3-5 пунктов вызывает сложности. Не каждый хочет потратить три минуты на такое мероприятие. А рассчитывать только на мнение наших коллег, которые знают платформу от и до, неверно.
Надеюсь, в будущем мы сможем мотивировать наших клиентов помочь нам совершенствоваться и донесем до них ценность таких исследований.
Если вы любите подобные забавы, сообщите нам, и мы с радостью пригласим вас, когда будем проверять очередную гипотезу!
4. Стремление к постоянному улучшению продукта на основе обратной связи пользователей
— Как мы понимаем, какие из комментариев клиентов о сервисе надо взять в работу? И с помощью каких инструментов эти запросы выявить?
Наша дорожная карта продукта состоит из задач нескольких категорий: запросы наших клиентов, потребности рынка, внутренние улучшения. Каждый спринт (отрезок работы в две недели) мы берем в работу задачи из этих категорий в определенном соотношении.
Запросы наших клиентов — одна из самых важных частей нашего плана. Так было всегда, и мы не планируем бросать этот подход.
Чтобы выявлять эти запросы, мы работаем со следующими источниками:
- Демонстрации системы потенциальным клиентам
- CustDev интервью с текущими клиентами
- Чаты менеджеров с текущими клиентами
Запрос представляет собой краткое описание какого-либо нереализованного функционала, который позволит клиенту решить его задачу и упростить пользование сервисом.
Все запросы поступают к нам от аккаунт-менеджеров. Далее запросы переносятся на доску, похожую на канбан (система постановки задач, при которой все этапы проекта визуализируются на специальной доске) по своей структуре. У каждой карточки на доске есть поля:
1) Количество клиентов, которым требуется тот или иной функционал
2) Статус самой задачи
3) Раздел системы, к которому относится запрос
4) Дедлайн (если есть)
5) И многое другое…
Пример такого запроса от аккаунт-менеджера.
Пример доски с пожеланиями клиентов.
В столбцах доски мы используем сортировки, которые позволяют определить, какие из задач мы будем брать в работу в ближайшее время. Мы делаем упор на запросы, которые востребованы у большого количества клиентов, ограничены в сроках или ограничивают реализацию необходимых механик.
В процессе работы с клиентскими запросами задействована почти вся команда: аккаунт-менеджеры, дизайнер, продакт, разработчики. Зачем это делается? Все знают, из каких этапов состоит процесс, всегда можно получить информацию об актуальном статусе задачи, узнать детали и прочие важные в работе вещи 🙂
5. Разработка функционала, который решает актуальные проблемы и удовлетворяет потребности пользователей
— Решение каких проблем было самым востребованным за последнее время?
— Как проверяем после, используют ли клиенты продукт?
— И что делать с тем, если не используют?
Если рассмотреть нашу доску с запросами, то самым востребованным за последнее время был такой функционал, как:
- Количество контактов в сводном отчете при создании сообщения
- Отправка сообщений на группу рассылок
- Автообновление страниц
- Выравнивание кода по ширине в HTML-редакторе
Если бы мы не уделяли столько времени работе с клиентами, опрашивая их, выявляя сложности в их взаимодействии с сервисом, то никогда бы не догадались сами, что пункты, приведенные выше, имеют такое значение!
При работе над продуктом очень легко отдалиться от него самого, жить в планах, мечтах, задачах, забыв про текущее состояние сервиса. Очень важно держать связь с теми, кто пользуется системой ежедневно.
Важным пунктом в этом процессе является мониторинг того, насколько новый функционал или изменение востребовано у пользователей. Потому что нередко мы сталкиваемся с тем, что новой фичей не пользуется даже тот клиент, который рьяно её требовал.
Здесь есть несколько гипотез, почему так происходит:
- Мы не совсем понимаем, как донести до пользователя полезность или выгоду от функционала
- Мы нелогично или неочевидно размещаем функционал или делаем на нем недостаточный акцент, в результате чего пользователь его просто не находит.
Команда уже работает над тем, чтобы не допускать подобной «пустой работы». Каким образом? Рассказываем в наших ежемесячных дайджестах и телеграм канале о разных функциях в сервисе, о задачах, которые они могут решить, с примерами и кейсами.
Подведем итоги.
Чтобы сделать IT-продукт, который будет отвечать запросам клиентов, важно:
- Понимать целевую аудиторию: кто они, какие у них потребности и что они ожидают от продукта
- Создание удобного и интуитивно понятного интерфейса продукта
- Использование методов юзабилити-тестирования для определения проблем пользователей с интерфейсом
- Стремление к постоянному улучшению продукта на основе обратной связи пользователей
- Разработка функционала, который решает актуальные проблемы и удовлетворяет потребности пользователей
Была полезна статья? 🙂
Еще больше материалов в нашем дайджесте, блоге и социальных сетях (Telegram enKod on Air, enKod: новое и важное)
