CRM Северстали поддерживала B2B-продажи: работу с клиентами, лидами, сделками, договорами и согласованиями. При этом менеджерам приходилось собирать информацию в разных системах, повторно вводить данные и проходить через перегруженные формы.
Я работал над продуктом в двух ролях: UX-дизайнером и UX-исследователем с декабря 2017 по ноябрь 2023 года, затем Junior Product Owner с декабря 2023 по декабрь 2025 года. В команде около 25 человек я прорабатывал решения от исследования проблемы до внедрения.
Сначала я разбирался в задаче, а не в экране
У CRM было много функций, полей и статусов, но это само по себе не объясняло, помогает ли система менеджеру. Мне было важно понять, что человек пытается сделать, какая информация ему нужна и где именно возникает лишняя работа.
Например, в системе были проблемы с качеством и актуальностью данных, а сведения о клиенте находились в разных корпоративных сервисах. Одни и те же данные приходилось искать и переносить вручную. В формах свободный ввод приводил к неодинаковым названиям организаций и затруднял поиск.
Я использовал интервью, наблюдение за работой, качественные и количественные исследования, коридорные проверки и юзабилити-тесты. Систематизировал обратную связь, формулировал вопросы и гипотезы, разбирал сценарии через анализ задач, CJM и JTBD. Пользовательские вводные поступали как напрямую, так и через бизнес-аналитиков и владельцев продукта.
Часть проблем была заметна на уровне конкретного поля. Другие затрагивали весь путь: данные приходили из нескольких систем, решение проходило через разные подразделения, а после заполнения формы человеку всё ещё могло быть непонятно, что делать дальше.
Переводил требования в проверяемые сценарии
Текстовые требования не всегда складывались в работоспособный процесс. Когда я переносил их в макет или прототип, становилось видно, каких состояний не хватает, где противоречат друг другу правила и как одно действие повлияет на следующие этапы.
Для проверки я делал прототипы в Figma и HTML, показывал их пользователям и дорабатывал по реакции. Затем обсуждал решение с заказчиками, аналитиками и техническими специалистами. Если требования противоречили друг другу, возвращался к ним до завершения разработки.
Так прототип становился способом уточнить не только внешний вид, но и саму постановку задачи: какие данные нужны, кто их вводит, откуда они появляются и что происходит после действия пользователя.
Учитывал роли и ограничения SAP
CRM была построена на SAP Fiori / UI5 и связана с другими корпоративными системами. Поэтому интерфейс нельзя было проектировать отдельно от данных, интеграций и уже существующих технических ограничений.
Например, при работе со структурой связанных компаний пользователю нужно было понимать, как соотносятся головная организация и дочерние юридические лица. Это требовало учесть бизнес-связи и технические ограничения системы. Я прорабатывал варианты и согласовывал их реализуемость с SAP-консультантами и разработчиками.
Разным ролям требовался разный рабочий фокус: менеджеру — текущие действия по клиентам, руководителю — состояние подразделения, аналитику — данные для анализа. Поэтому стартовую страницу я проектировал с учётом задач пользователей, а не как одинаковый набор показателей для всех.
Два сценария, где менялась повседневная работа
Заведение клиента
На карточку клиента приходилось тратить около 20 минут. Я проектировал сценарий создания карточки по ИНН с автоматической загрузкой реквизитов. В результате заведение клиента стало занимать около минуты.
Подготовка договора
Исходный процесс требовал заполнения более 100 полей в разных системах и занимал 30 дней. Я исследовал причины задержек, проектировал новые сценарии и интерфейс, а команда сократила число полей примерно в пять раз и общий срок подготовки договора — до семи дней.
Это был командный результат: мой личный вклад состоял в исследовании процесса, проектировании сценариев и проверке интерфейса.
Сопровождал изменения после согласования
После передачи решения в разработку я отвечал на вопросы команды, уточнял сценарии и проверял соответствие реализации. Работал с тестировщиками, проверял интерфейсы и функциональность, описывал дефекты в Jira и перепроверял исправления.
После релиза собирал обратную связь. Если обнаруживалось, что сценарий не покрывает реальную работу — например, не хватает нужного поля, — команда оценивала доработку для следующего релиза.
В работе с данными я инициировал обсуждение справочников и свободного ввода, предлагал использовать подсказки и предзаполнение. В интеграционных сценариях прорабатывал получение информации из корпоративных систем и автоматическое заполнение документов. Разработка интеграций выполнялась совместно с техническими специалистами.
Смотрел на использование отдельно от удовлетворённости и продаж
По предоставленным данным, доля менеджеров, использующих CRM, выросла с 3% до 60%. Это командный результат трансформации продукта.
При этом использование не означало, что все пользователи довольны: часть людей продолжала воспринимать систему как обязательную отчётность. И мы не смогли надёжно связать изменения CRM с ростом продаж. Для меня это стало важным ограничением: метрика использования показывает, что люди работают в системе, но сама по себе не доказывает, что продукт помогает продавать больше.
От изменений интерфейса — к концепции продукта
Со временем я сформулировал более широкое направление развития CRM. Система должна не только фиксировать информацию и контролировать процесс, но и помогать менеджеру работать с клиентом.
В концепции я предлагал объединить клиентский контекст с рыночной аналитикой, дать пользователю возможность фиксировать наблюдения и торговые гипотезы, а также показывать историю взаимодействий: что сделано → кем → к какому результату привело. Ещё одно направление — помогать определить следующий шаг по клиенту.
Это были предложения и гипотезы дальнейшего развития, а не описание функций, которые уже внедрили. Для них требовались отдельная проверка ценности и оценка реализации.
Что я вынес из этой работы
CRM научила меня смотреть на корпоративный продукт сразу с нескольких сторон: через задачу пользователя, бизнес-процесс, данные и ограничения платформы. Хорошее решение начиналось не с добавления новой функции, а с понимания того, какую работу она должна убрать или упростить.
Я работал над сценарием от первого исследования до проверки реализации: формулировал проблему, делал её проверяемой через прототип, уточнял требования с командой и сопровождал внедрение. При этом не приписываю себе командные результаты и отделяю реализованные изменения от идей о будущем продукта.