Проектирование без CustDev’а. На примере развития корпоративного ПО для выездного обслуживания

Не секрет, что во время разработки программного обеспечения в b2b очень сложно найти пользователей, чтобы провести CustDev и проверить жизнеспособность гипотез и идей, которые родились во время исследования у продуктового дизайнера.

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

В b2b не покастдевить соседа

Меня зовут Армине, я продуктовый дизайнер в компании HubEx. Когда пришла в компанию после b2c, пришлось перестраиваться, потому что в разработке программного обеспечения для бизнеса уровень сложности выше (сложная мотивация + длинный цикл принятия решения о покупке), а доступ к клиенту для проведения исследований практически никакой.

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

А учитывая целевую аудиторию продукта – технические и генеральные директора, главные инженеры и руководители отделов сервиса – им совсем не до развития платформы и исследований.

Тем не менее, развитие продукта – непрерывный процесс, и нам нужно опираться на потребности нашей аудитории. Рассказываю, как мы их выявляем.

Наши способы Customer Development

Собственная база пользователей. Так как у нашей целевой аудитории, как правило, нет времени, то время от времени мы исследуем пользователей платформы. Стоит сказать, что в b2b, как правило, покупают ПО одни, а пользуются – другие. В случае с HubEx покупают платформу топ-менеджеры, а большинство пользователей – диспетчеры, сервисные инженеры и другие выездные специалисты. Их мы кастдевим, но результаты таких исследований не всегда применяем.

Объясню на примере. В системе есть карта, на которой можно видеть местоположение каждого выездного сотрудника в режиме реального времени. Она нужна, чтобы контролировать кто, где и когда находился, в какое время назначенный на заявку мастер выезжал на объект и выезжал ли. Когда мы проектировали возможность создания заявок на обслуживание прямо с такой карты, а не из меню «Заявки», большинство пользователей отнеслись к идее прохладно. Однако в результате оказалось, что это одна из наиболее популярных функций.

«Если бы я спросил у людей, что им нужно, они бы попросили более быструю лошадь», — поговаривал Генри Форд. Так и в нашем случае – мало кто может сформулировать и описать свои потребности, и периодически нам приходится наносить пользу принудительно =)

В случаях исследования своих пользователей, перед проектированием очередной пользовательской функции, мы приоритезируем идеи и гипотезы по ICE Scoring. Да, методологию часто ругают за субъективность, но учитывая специфику b2b, описанную выше, и скромный объем исследований, не вижу в этом катастрофы.

Наш скоринг выглядит так:

  • кол-во текущих клиентов, которые ожидают фичу

  • кол-во «горячих» потенциальных клиентов, которые ждут фичу

  • кол-во лидов, интересовавшихся фичей

  • кол-во проваленных сделок из-за отсутствия фичи

  • кол-во запросов на фичу от текущих пользователей через техподдержку и команду внедрения

  • кол-во жалоб, связанных с отсутствием фичи

  • наличие фичи у западных конкурентов

  • наличие фичи у российских конкурентов

  • влияние фичи на быстродействие, отказоустойчивость

  • сложность внедрения фичи по 4-бальной шкале

Маркетинговые агентства и аутсорсеры. Ввиду разнообразия масштабов и разношерстности сферы выездного обслуживания, отдать исследование на откуп сторонним исполнителям с непрозрачными методами исследования мы не решились.

Платформа Яндекс.Взгляд. На постоянной основе это недешево, тоже отказались.

Социальные сети. Про них стоит сказать отдельно. Это очевидный и массовый канал, который мы пока не пробовали. До недавнего времени у компании не было социальных сетей и сформированной в них аудитории. Сейчас они появились, надеюсь, через несколько месяцев мы обязательно воспользуемся аудиторией своих каналов.

Как проектировать без кастдева

Несмотря на customer development своих пользователей, в основном мы обходимся собственными силами.

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

ЭТАП 1. Как продуктовый дизайнер я получаю от владельца продукта User Story с общим описанием того, какой результат и какую ценность должен получить тот или иной пользователь. В моем случае вводные были следующими:

  • Как руководитель компании, я хочу увидеть, сколько запланировано заявок на день, на неделю, на месяц, с целью понимания загруженности персонала и необходимого штата сотрудников.

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

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

ЭТАП 2. Для понимания, в какую сторону двигаться и какой функционал проектировать, я пишу Job Story, которая мне помогает видеть:

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

В нашем случае – понимание загруженности каждого сотрудника в отдельности и компании в целом, возможность ускорить назначение и распределение заявок в целях соблюдения SLA с клиентами.

В нашем случае – равномерное распределение заявок, сокращение объема переработок персонала, оптимальная комплектация штата сотрудников.

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

Так выглядел месячный календарь с расписанием заявок до изменений:

Так выглядел месячный календарь с расписанием заявок
Так выглядел месячный календарь с расписанием заявок

Так он стал выглядеть после:

ЭТАП 3. Далее делаю mindmap – это помогает подытожить исследование и собрать мои мысли, идеи и гипотезы на едином борде. Использую Miro.

Так выглядела карта в моем примере (оригинал здесь):

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

ЭТАП 5. Прорисовка интерфейса. Здесь не буду подробно останавливаться. Отмечу только, что если есть дизайн-система, то можно не прототипировать. Но если вы работаете над новым продуктом, то прототип сэкономит ваше драгоценное время.

ЭТАП 6. После отрисовки интерфейса начинается самое интересное. Нужно проверить:

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

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

ЭТАП 7. Наконец, я отдаю дизайн тестировщикам, а владелец продукта проводит параллельный груминг интерфейса с командой разработки. Получается, своего рода, коридорное исследование.

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

Ура! Можно отдышаться =)

Надеюсь, получилось на своем примере с HubEx показать, как кастдевить в b2b, если нет возможности проводить полноценный Customer Development.

Читайте так же:

  • Реалити-конференция СПИК 2021: остаться в диджиталРеалити-конференция СПИК 2021: остаться в диджитал 27-28 мая в Санкт-Петербурге состоится знаменитая интернет-конференция СПИК – это место, где встретятся все! В офлайне на Васильевском острове и в онлайне на уютном диване соберутся чемпионы и новички маркетинга, PR и бизнеса. Быть в центре событий или наблюдать со стороны – каждый […]
  • Крестовник стрелконосный — особенный суккулентКрестовник стрелконосный — особенный суккулент Один из самых оригинальных комнатных суккулентов — причудливый крестовник стрелконосный. Розетки с длинными мясистыми цилиндрическими листьями-палочками вызывают разные ассоциации. Одним они напоминают о ежах и кораллах, а для других — схожи со стручками спаржевой фасоли или […]
  • Redmi Note 10 в Китае стали хитом ещё до начала продаж: собрано 230 000 предзаказовRedmi Note 10 в Китае стали хитом ещё до начала продаж: собрано 230 000 предзаказов Если глобальные Redmi Note 10 для нашего и многих других регионов вышли уже несколько месяцев тому назад. То китайские дебютируют только завтра. Но уже до старта продаж за ними выстроилась большая очередь: только на одной площадке JD.com собрано свыше 230 000 заказов на приобретение […]
  • Наполнение сайта удаленная работаНаполнение сайта удаленная работа Я ищу копирайтера для создания контента для моего сайта. Для того, чтобы вы поняли мои требования и ожидаемое качество работы. Очень важно. Чтобы вы взглянули на сайт наших конкурентов https://cpduk.co.uk что вас ожидает: - 10-15 страниц контента и 6 блогов. - 100% White Hat SEO - стиль […]