Архитектор Групп — поставщик строительных материалов для девелоперов и генподрядчиков в Москве и Московской области. Компания работает на рынке более 12 лет и сотрудничает с крупными застройщиками, включая ПИК, Самолёт и А101.

По мере роста бизнеса существующие процессы перестали масштабироваться. Менеджеры тратили до 60−70% рабочего времени на ручную обработку заказов: уточняли наличие товаров, выставляли счета, согласовывали детали поставок и пересылали документы по электронной почте.
В периоды высокой нагрузки именно операционные процессы становились узким местом бизнеса.

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

Задача выходила далеко за рамки редизайна. Нужно было спроектировать новую цифровую платформу, которая сократила бы объём ручной работы, объединила ключевые процессы в одном интерфейсе и создала фундамент для дальнейшего роста компании. Дополнительным ограничением стало то, что архитектуру продукта нужно было сразу закладывать с учётом будущего выхода компании в B2C-сегмент.

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

Лид-дизайнер проекта. Я отвечала за исследование бизнес-процессов, формирование продуктовой логики и качество итоговых решений.

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

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

В результате сформировали три ключевых направления работы:

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

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

Сроки и бюджет проекта были фиксированными. Дополнительным ограничением стали интеграции с 1С, которые напрямую влияли на состав MVP и определяли, какие сценарии можно реализовать на первом этапе, а какие необходимо переносить в последующие итерации.

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

Исследование состояло из трёх частей:

• сегментация пользователей и формулировка JTBD;
• анализ текущих бизнес-процессов;
• конкурентный анализ и определение состава MVP.

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

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

Основной пользователь платформы. Отвечает за снабжение объектов и ежедневно работает с заказами.

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

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

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

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

Исследование показало, что большая часть информации уже существовала внутри компании, но была распределена между людьми, 1С, электронной почтой и ЭДО.

Практически каждый важный шаг клиента зависел от менеджера:

• уточнение наличия товара;
• получение персональных условий;
• формирование счёта;
• контроль статусов заказа;
• поиск документов.

Из-за этого менеджеры становились узким местом процесса, а клиенты не могли самостоятельно решать большинство задач.

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

По итогам исследования сформировались три принципа, которые легли в основу продукта.

1. Объект строительства важнее отдельного заказа
Пользователи мыслят не заказами, а объектами. Поэтому вся структура платформы должна строиться вокруг объектов и связанных с ними поставок.

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

3. Главная ценность платформы — прозрачность
Клиенты хотели получать доступ к информации, которая раньше была доступна только через менеджера: наличие товаров, персональные условия, статусы заказов и документы.
Эти выводы стали основой для формирования MVP и дальнейшего проектирования пользовательских сценариев.

Чтобы не изобретать велосипед там где уже есть хорошие решения, мы изучили рынок. Я регистрировалась и проходила полный пользовательский путь на Ozon Бизнес, ВсеИнструменты, Петрович, Лемена Про, Яндекс Маркет и сайтах производителей стройматериалов. Смотрела как устроено добавление сотрудников, оформление заказа, работа с документами в ЛК.

Два главных референса — Ozon Бизнес и ВсеИнструменты. На них ориентировался сам клиент. В итоге пошли своим путём, но бенчмаркинг помог понять где пробелы у рынка в целом.

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

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

Когда стало понятно для кого мы делаем продукт и какие задачи он должен решать, мы перешли к проектированию. Клиент обозначил позицию ещё на старте: не ориентироваться на то, что есть, а строить как нужно. Это освободило нас от попытки оцифровать хаос, но и усложнило задачу. Нужно было проектировать то, чего ещё не существует. Каждое решение я проверяла по нескольким осям одновременно

Аналитическая работа не заканчивалась с началом проектирования — она шла параллельно весь проект. Данные менялись постоянно. Иногда клиент сам до конца не знал как у него устроены процессы — это выяснялось прямо в процессе обсуждения конкретного экрана. Иногда появлялись новые хотелки: роли, сценарии, фичи.

Каждый раз нужно было быстро решить — берём в MVP или откладываем, влияет ли на архитектуру, укладываемся ли в сроки.

Первым делом мы зафиксировали структуру продукта — точки входа и минимально необходимый набор экранов. Платформа состоит из трёх слоёв.
— Публичная часть — каталог и карточки товаров. Доступна всем, включая неавторизованных
— Личный кабинет — заказы, документы, сотрудники, адреса объектов. Функционал зависит от статуса и роли
— Административная часть — управление каталогом, клиентами, контентом

После карты сайта перешла к созданию user flow — проработала сценарии для каждого сегмента. Особое внимание уделяла пограничным состояниям: что происходит, если клиент без ЭДО пытается получить документы, если менеджер пробует добавить объект без прав

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

Когда прототипы были готовы, мы провели UX-тесты — протестировали их на трёх сотрудниках отдела снабжения Архитектор Групп. Их работа максимально близка к тому, как будут работать реальные клиенты платформы. Тестирование помогло поймать проблемы до того, как дизайн ушёл в разработку.

Основные сценарии прошли без проблем: поиск заказа, скачивание документа, добавление сотрудника — всё понятно и быстро. Но кое-что нашли и исправили.

Выводы по итогам исследования

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

Одна из ключевых задач платформы — дать клиентам доступ к их истории заказов и документам. Но здесь сразу возникал вопрос безопасности: как убедиться, что человек, который регистрируется под каким-то ИНН, действительно является представителем этой компании? ИНН публичный — его может ввести кто угодно. Плюс персональные условия клиентов (скидки, цены, история сделок) — конфиденциальная информация. Открывать её всем, кто просто ввёл ИНН, нельзя.

Отдельная история — безопасность на уровне сотрудников. Менеджеры по закупкам приходят и уходят. Нужно было предусмотреть механику, при которой уволившийся сотрудник не сохранял бы доступ к персональным условиям и истории заказов своего бывшего работодателя. Мы запланировали: если сотрудник не был активен на сайте две недели, при следующем заходе система запрашивает подтверждение у руководителя. Если руководитель подтверждает — доступ восстанавливается. Если нет — аккаунт удаляется.

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

Был промежуточный вариант: разрешить 1−3 заказа без ЭДО, потом ограничивать возможность заказа. Мы отказались. Количество заказов произвольное, а ограничение не мотивирует подключить ЭДО — только создаёт негативный опыт.

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

Клиенту без ЭДО не блокируется доступ — он просто получает меньше функционала. Подключение ЭДО выступает неким стимулом для получения допвозможностей платформы.

Клиенты бывают разными: новые, действующие с ЭДО, действующие без ЭДО. У каждого — разный уровень верификации и разные потребности. Чтобы не решать каждый случай вручную, я предложила формализовать это через статусы. Каждый автоматически определяет, что видит клиент и что может делать.

Путь клиента выглядит так: он вводит ИНН при регистрации, мы сверяемся с базой 1С и определяем кто перед нами.

В B2B-заказе участвуют разные люди с разными задачами. Один логин на всю компанию создаёт хаос: непонятно кто сделал заказ, бухгалтер видит лишнее, менеджер может случайно изменить чужой заказ. Мы проработали логику и границы каждой роли и согласовали их с клиентом.

Добавление нового сотрудника осуществляется через приглашение по email. Руководитель выбирает роль, сотрудник получает ссылку и попадает в кабинет с нужными правами. При увольнении сотрудник удаляется из системы. Четвёртую роль «супер-админ» обсуждали и отвергли. Её функции полностью покрывает руководитель.

Для удобства демонстрации различий функционала, я создала матрицу ролей

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

Дизайн строили на основе уже существующего визуального языка компании — логотипа, логобука и фирменных материалов, которые мы разрабатывали для Архитектор Групп раньше. Задача заключалась в том, чтобы было перенести его в цифровую среду и адаптировать под B2B-продукт с высокой плотностью информации.

Регистрация определяет всё: какой функционал получит клиент, как будет верифицирован, как устроен его кабинет. Нужно было учесть три принципиально разных пути — в зависимости от того, кто пришёл на сайт.

Пользователь проходит стандартную регистрацию, вводит ИНН компании. Мы сверяемся с базой 1С — видим что этот клиент уже работает с нами по ЭДО. Вручную отправляем ему в ЭДО соглашение об обмене документами через сайт. Пользователь подписывает его в своей ЭДО-системе (Контур-Диадок или СБИС). После подписания в ЛК автоматически выгружается полная история заказов и документов.

Почему отправляем вручную, а не через API: прямая интеграция с ЭДО требует месяцев разработки. Для MVP ручная отправка надёжнее и реалистичнее по срокам. Автоматизация — в беклог.

Пользователь вводит ИНН. Мы сверяемся с 1С — видим либо что клиент работал с нами без ЭДО, либо что он новый. В обоих случаях предлагаем подключить ЭДО чтобы получить полный функционал. Если не хочет — ограниченный кабинет: заказы есть, документов, ролей и адресов объектов нет.

Важный момент про первую регистрацию
Первый зарегистрировавшийся от компании автоматически становится руководителем и получает полный доступ. Это неочевидно — поэтому на экране регистрации мы предупреждаем пользователя о том,что регистрацию должен проходить руководитель или уполномоченное лицо.

Личный кабинет — ядро платформы. Именно здесь клиент получает всё, за чем раньше звонил менеджеру.

Стандартная e-commerce структура: баннер, разводка по категориям каталога, преимущества покупки как юрлицо, популярные товары, акции, новости, популярные бренды.

B2B-карточка плотнее B2C: описание, детальные характеристики, документация для скачивания, сопутствующие товары и другие товары бренда. Сразу показываем когда сможем доставить — с учётом пула товара. Авторизованный клиент видит персональную цену и может запросить индивидуальные условия прямо со страницы.

На десктопе — двухколоночный лейаут: галерея слева, характеристики и действия справа. На мобильном — последовательная прокрутка с закреплённой кнопкой «в корзину».

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

Выбор объекта из сохранённого списка — адрес и контактные данные подтягиваются автоматически. Способ оплаты влияет на отображение сроков: карта — конкретные даты, счёт — предварительные с пояснением «точная дата появится после оплаты». Если счёт не оплачен в срок, заказ отменяется и цена может измениться.

Если в корзине товары из разных пулов (день в день и под заказ), предлагаем разбить на две поставки или объединить на позднюю дату. Пользователь выбирает сам.

Параллельно с проектированием собрали UI-библиотеку: навигация, карточки товаров, формы, таблицы заказов, статусные бейджи, модальные окна. B2B-интерфейс с высокой плотностью информации требует особого внимания к состояниям — пустые списки, ошибки интеграции, недоступные товары. Все edge-кейсы спроектированы и вошли в библиотеку.

Платформа в активной разработке. Дизайн финализирован, бэкэнд завершен. UX-тесты прошли, правки внесены. Всё, что не вошло в MVP, мы не выбросили — зафиксировали в беклоге. Это позволяет развивать продукт последовательно, не теряя ни одну из задач.

Проект уже повлиял на внутренние процессы клиента. На их стороне началась стандартизация данных — прямое следствие требований платформы. Сайт задал стандарт, которому теперь нужно соответствовать.
 
Следующие шаги:

• Запуск MVP и сбор первых метрик: доля самостоятельных заказов, снижение нагрузки на менеджеров
• Автоматизация отправки соглашений через ЭДО по API
• Автоматизация персональных условий
• Масштабирование продукта, выход в B2C (2027)