SberCRM. Конструктор форм
Я спроектировал конструктор форм для SberCRM, чтобы клиенты могли собирать заявки, контакты и обратную связь на своих сайтах и сразу передавать данные в CRM. Настройку нужно было сделать понятной маркетологам и учесть действия, для которых требовались права администратора.
Постановка задачи
Клиентам SberCRM понадобился инструмент для создания форм и виджетов на своих сайтах. Пользователь должен был собрать форму, разместить её на сайте и получать заполненные данные в CRM для дальнейшей работы. Новый конструктор предстояло встроить в продукт, где уже существовали свои сценарии, ролевая модель и дизайн-система.
Я отвечал за пользовательский сценарий и интерфейс: изучал потребности пользователей и аналоги, собирал прототипы, участвовал в тестировании и готовил макеты к разработке.
Начало работы
Работу я начал с изучения текущих сценариев пользователей и требований CRM. Параллельно разобрал no-code конструкторы: сравнивал, как в них устроены работа с полями, визуальные настройки, предпросмотр, публикация и настройка логики формы.
В SberCRM на настройку формы влияла структура данных. Независимую от CRM форму создать было нельзя: её поля нужно было связать с полями сущностей системы. От них же зависели доступные типы полей. Например, обычное текстовое поле нельзя было использовать в конструкторе как поле телефона или email. Перед публикацией форму также требовалось связать с сайтом и доменом, чтобы данные с внешней страницы поступали в CRM.
Эти настройки затрагивали работу двух специалистов. Маркетолог знал, какие данные нужно собрать, как должна выглядеть форма и где её использовать. Администратор понимал устройство CRM и имел доступ к сущностям, полям и другим системным настройкам. У маркетолога таких прав могло не быть.
Поэтому в сценарии нужно было учесть участие обоих. В конструкторе маркетолог мог настроить внешний вид формы и привязать её к домену. Работа с сущностями оставалась в другом сервисе и требовала административных прав.
Отправной точкой для первого прототипа стал существующий конструктор внутренних форм. Им уже пользовались администраторы SberCRM, и он работал с той же логикой данных. Мы взяли этот паттерн за основу и адаптировали его для форм на внешних сайтах.
Что изменилось после тестирования
Первый прототип мы вместе с аналитиком протестировали с клиентами. На тестировании выяснилось, что пользователи теряются на отдельных этапах и не всегда понимают, что от них требуется. Внутренний конструктор предполагал знание устройства CRM. Для маркетологов, которые должны были работать с новым инструментом, эта логика была непривычной.
По результатам тестирования я переработал сценарий: разбил процесс на короткие последовательные шаги и изменил порядок настройки. Параметры появлялись тогда, когда были нужны для продолжения работы. Так пользователю было проще понять, что делать на текущем этапе.
Ограничения CRM при этом сохранялись. Для настройки сущностей мы добавили подробные инструкции, а при нехватке прав интерфейс предлагал обратиться к администратору. В этих местах было важно объяснить, почему пользователь не может продолжить самостоятельно и какое действие требуется дальше.
Переработанный прототип мы проверили повторно. Пользователи увереннее проходили основные этапы, и вопросов возникало меньше. После этого команда перешла к реализации MVP.
Результат
В MVP вошёл весь путь от подготовки формы до получения данных в CRM. Пользователь мог выбрать или создать форму, настроить её, связать с CRM и доменом, проверить и опубликовать на сайте.
Клиенты получили встроенный инструмент для создания лид-форм: их можно было готовить в SberCRM, а собранные данные сразу поступали в систему для дальнейшей работы.
Главное изменение по итогам проектирования — последовательность настройки. Мы сохранили требования CRM и разделение прав, но выстроили работу так, чтобы маркетолог мог пройти свою часть сценария и понимал, когда нужна помощь администратора.
Следующий кейс
