Цифровые сервисы для бизнеса обычно создают вокруг реально работающих процессов: закупок, логистики, складов, документооборота, согласований, финансовых лимитов, интеграций с 1С, CRM и так далее. Убрать эту сложность нельзя: за каждым статусом, полем и ограничением стоит регламент, договор, роль, юридическое требование или учетная логика. Но значит ли это, что сервис обязательно получится сложным, и сотрудники не разберутся в нём, пока не прочтут длинную инструкцию? Мы считаем, что сложный инструмент не обязан быть непонятным. И в этой статье мы разберем, как с помощью продуктового дизайна можно сделать такие личные кабинеты, дашборды и CRM, в которых пользователи разберутся без длинных инструкций и постоянного участия менеджера.
В онлайн-сервисах «для потребителя», или B2C, пользователь часто решает одну понятную задачу — выбрать товар, оплатить заказ, записаться на услугу, оставить заявку. В сервисах для бизнеса (B2B) все сложнее: это процесс, где есть роли, статусы, ограничения, документы, история действий и ответственность за результат.
Например, личный кабинет дилера может одновременно включать каталог продукции, остатки на складах, индивидуальные цены, заказы, отгрузки, закрывающие документы, акты сверки, обращения в поддержку и аналитику по продажам. Для бизнеса это сразу несколько процессов, связанных между собой.
Проблема начинается тогда, когда интерфейс проектируют как набор разделов: «Заказы», «Документы», «Финансы», «Логистика», «Поддержка». Формально все данные на месте. Но пользователь приходит не за разделом, у него всегда есть конкретная задача: понять, почему заказ задерживается, где скачать накладную, кто должен согласовать заявку, можно ли изменить количество товара.
Поэтому B2B-интерфейс нужно проектировать не как последовательность экранов, а как карту процессов. Дизайнеры и разработчики должны понять, что пользователь хочет сделать, какие данные ему нужны на каждом этапе и как система объяснит следующий шаг. Такая логика проектирования поможет сделать сервис понятнее без детальных инструкций, ведь он будет следовать за логикой знакомых пользователю бизнес-процессов.
В корпоративных проектах обучение и различные инструкции часто воспринимаются как обязательная часть внедрения. Это нормально, если речь идет о сложной системе с новой логикой работы. Но всё это не должно закрывать базовые ошибки интерфейса.
Типичные ситуации, которые говорят о слабом проектировании:
Сотруднику нужно открыть PDF-инструкцию, чтобы понять, где находится статус заявки.
Партнер пишет менеджеру с вопросами, почему недоступна кнопка оплаты.
Руководитель видит дашборд, но не понимает, какие метрики требуют внимания.
Хороший продуктовый дизайн позволяет избежать таких ситуаций, ведь с ним можно обойтись без долгого обучения. Пользователь должен понимать базовые сценарии без отдельной лекции: где он находится, что происходит, что нужно сделать сейчас и что будет дальше.
В B2B-сервисах цена ошибок выше, чем в «клиентских». Непонятный интерфейс увеличивает нагрузку на поддержку, замедляет согласования, провоцирует ошибки в данных и возвращает процессы в почту, мессенджеры и Excel. В итоге компания инвестирует в цифровой сервис, но продолжает работать вручную.
Когда B2B-интерфейс выглядит перегруженным, первым решением часто становится «почистить экран»: убрать колонки, сократить фильтры, спрятать поля, сделать меню короче. Это может улучшить первый визуальный эффект, но сломать работу реальных пользователей.
В B2B лишнее для одной роли может быть критически важным для другой. Финансовому контролеру нужны лимиты, счета, задолженность и условия оплаты. Менеджеру по закупкам — ассортимент, остатки, сроки поставки и история заказов. Руководителю — отклонения от плана, динамика, риски и агрегированные показатели. Складскому специалисту — статусы отгрузки, адреса, упаковочные листы и комментарии по приемке.
Если просто убрать данные, пользователи начнут искать их в других каналах. Если оставить все на одном экране, сервис станет тяжелым и пугающим. Поэтому задача продуктового дизайна — не механически упростить интерфейс, а выстроить приоритеты. Так сложность остается внутри системы, а пользователь видит понятный рабочий маршрут.
Что пользователь должен увидеть сразу? Что можно открыть по запросу? Какие данные нужны только в детализации? Какие действия доступны в конкретном статусе? Где подсказка должна появиться прямо в момент ошибки? Как показать одно и то же состояние разным ролям? Эти вопросы должны задать себе те, кто разрабатывает сервис, и найти ответы совместно с заказчиком — представителем бизнеса.
Продуктовый дизайн B2B-инструмента должен идти вместе с бизнес-анализом и техническим проектированием. UX-специалист описывает пользовательский путь. Аналитик фиксирует бизнес-правила и ограничения. Архитектор продумывает интеграции, роли, статусы и обмен данными. Разработчики реализуют API, права, логику состояний и обработку ошибок. Так разработчики точно будут знать, откуда приходят данные и кто может согласовать заявку.
Да, кнопка «Согласовать заявку» на макете выглядит просто. Но за ней стоит много условий: кто согласует, какой лимит у роли, что делать при превышении бюджета, нужно ли уведомлять финансовый отдел, можно ли отменить действие, где хранится история согласований. Поэтому до реализации важно описать процесс так, чтобы его можно было реализовать без потери смысла.
B2B-сервисы почти всегда работают с большим объемом данных, среди которых карточки товаров, таблицы, различные документы, остатки товара и так далее. Если вывалить все это на первый экран, пользователь утонет в информации. Если спрятать слишком глубоко, он не сможет работать.
Поэтому в продуктовых интерфейсах важен принцип постепенного раскрытия данных. Сначала пользователь видит то, что помогает принять решение или продолжить работу. Затем — детализацию. Потом — документы, техническую историю и дополнительные параметры. Эта логика особенно хорошо видна, например, с CRM: первый экран карточки клиента показывает, кто клиент, какой статус отношений, откуда пришла заявка. История коммуникаций, договоры, счета, задачи и вложения тоже важны, но менеджер «проваливается» в них уже при более детальном изучении карточки. Так постепенное раскрытие не упрощает бизнес-логику, а делает ее управляемой.
Для бизнеса хорошее качество проектирования выражается в конкретных метриках:
Объем операционной нагрузки на сотрудников (количество часов и число сотрудников);
Цикл согласования.
Количество ошибок в заявках и документах.
Как быстро новые сотрудники и партнеры начинают работать в системе.
Поэтому для того, чтобы оценить качество разработанного сервиса, важно заранее взять контрольные данные — например, «сколько часов операционной нагрузки есть у сотрудников сейчас» или «сколько длится цикл согласования» — и поставить цели.
Так, при разработке интерфейса киосков самообслуживания в аэропортах (заказчик — компания «Авиакод») мы использовали главную метрику: время на регистрацию. Выяснили, что у стойки она занимает около 4 минут на пассажира и поставили цель сократить её до 1 минуты. Подробнее о ходе работы рассказали в описании кейса.
Одна из частых ошибок в корпоративных сервисах — копировать структуру компании в интерфейс. Например, создавать разделы, названные как департаменты компании: «Логистика», «Финансы», «Сервисные обращения». Но такая логика работает только для внутреннего заказчика — сотрудников компании, которые хорошо знакомы с её структурой. Внешних партнёров это скорее запутает, потому что они приходят за решением конкретной задачи: например, «Почему счет не оплачен?» или «Кто должен подтвердить заявку?».
Поэтому проектирование B2B-инструмента начинается с описания сценариев. Именно типичные действия пользователя в системе — оформление заявок, оплата счетов, выгрузка документов — описываются и превращаются в разднелы интерфейса.
Пример. В личном кабинете поставщика сценарий «передать закрывающие документы» может затрагивать сразу несколько разделов: договор, заказ, отгрузку, акт и переписку с менеджером. Если разложить это по внутренним отделам, пользователь будет прыгать между вкладками. Если собрать сценарий вокруг задачи, он увидит чек-лист документов, статус проверки, комментарии и следующий шаг на одном маршруте.
Такой подход требует больше аналитики на старте, но экономит время после запуска. Сервис становится понятнее, а поддержка получает меньше однотипных вопросов.
В B2B-процессах пользователь часто работает не с финальным результатом, а с промежуточными состояниями.
Пример. Заявка создана, но не согласована. Если интерфейс показывает только сухой статус, пользователь не понимает, что происходит. Если «на проверке», то у кого? Если «в обработке», то сколько ещё нужно ждать?
Если же сервис сообщает не «Заявка в обработке», а «Заявка проверяется менеджером, ответ появится до 15 июля», то такой статус может заменить десятки писем менеджеру.
Чтобы в интерфейсе появились понятные подсказки, на этапе проектирования нужно заранее описать статусную модель. Вот какие вопросы важно прояснить:
Какие состояния есть у заявки, заказа, документа или сделки?
Кто видит каждое состояние?
Какие действия доступны?
Какие уведомления отправляются каждому типу пользователей?
Что и как пользователь должен понять без обращения в поддержку?
Если этих вопросов нет в проектировании, они все равно появятся после запуска. Только решать их придется уже через доработки и ручные объяснения.
Помимо промежуточных стадий, B2B-сервис сталкивается также с пограничными состояниями. Это ситуации, которые выходят за рамки типичного сценария использования. Если такие состояния не спроектированы, пользователь видит пустой экран и идет в поддержку.
Примеры пограничных состояний в работе цифрового В2В-сервиса:
данные из 1С не обновились;
ERP вернула ошибку;
документ еще не подписан;
пользователь не имеет прав на действие;
заказ нельзя изменить после определенного статуса;
по фильтру ничего не найдено;
синхронизация прошла частично;
руководитель открыл дашборд, но по выбранному периоду еще нет данных.
Хороший интерфейс объясняет, что произошло и что делать дальше. Например: «Данные из учетной системы временно не обновились. Последняя синхронизация — 22 июня, 09:30. Попробуйте позже или напишите менеджеру». Такие сообщения требуют связи дизайна, аналитики и разработки, но именно они экономят время и пользователя, и поддержки.
Правильно настроенная ролевая модель не только повышает безопасность сервиса, но и снижает визуальный шум. Интерфейс становится короче, потому что каждому пользователю показывают ту часть системы, которая нужна именно ему. Подробнее о ролевой модели в В2В сервисах и о том, почему она важна, мы рассказали в отдельной статье.
Хороший пример — портал Алюминиевой Ассоциации, который объединяет производителей, поставщиков, потребителей и научные центры алюминиевой отрасли. Участников много, задачи у каждого разные: администратор сайта модерирует заявки, представитель компании публикует новости и ведёт профиль организации, рядовой сотрудник работает с отчётами, гость видит только открытые разделы. Если бы все они видели один и тот же интерфейс, он был бы перегружен для одних и недостаточен для других. Ролевая модель здесь не просто разграничивает доступ — она делает каждый личный кабинет короче и понятнее. Подробнее о том, как устроена архитектура портала — в кейсе.
Понятный B2B-инструмент — это не простота, а зрелость проектирования, которая характеризуется правильной методологией и вдумчивой аналитикой.
Сложный B2B-сервис становится понятным без обучения тогда, когда команда проектирует не отдельные экраны, а систему: роли, сценарии, данные, статусы, ограничения, интеграции, ошибки и точки принятия решений.
Цифровой сервис для бизнеса может включать десятки функций, несколько уровней доступа, сложные таблицы, дашборды, документы и интеграции с учетными системами и при этом быть понятным без обучения. А всё благодаря тому, что пользователь не сталкивается со всей сложностью одновременно, а видит свой сценарий и получает понятные объяснения в нужный момент.
Именно в этом ценность продуктового дизайна для B2B. Он помогает разложить бизнес-процесс так, чтобы цифровой сервис был понятным, последовательным и работал «в мире пользователя».
Uplab много лет проектирует и развивает личные кабинеты, CRM, дашборды и цифровые сервисы для B2B. Если вам нужен рабочий B2B-инструмент, свяжитесь с нами через форму «Обсудить проект»!
Комментарии к статье
Комментарии: 0