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

Поэтому проектирование следует начинать не с универсального дашборда, а с ролей, прав, бизнес-объектов и задач. Услуга POLADO UI/UX и продуктовый дизайн помогает превратить такие требования в информационную архитектуру, пользовательские потоки и согласованную систему интерфейсов до начала разработки.

Начинайте с задач и ограничений, а не с экранов

Названия «клиент», «сотрудник» и «администратор» обычно слишком общие для качественного дизайна. Полезнее определить, что именно должен сделать пользователь, с каким объектом он работает, какие данные видит и где требуется согласование другого человека.

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

Для каждой роли отдельно опишите действия: просмотр, создание, редактирование, согласование, экспорт и администрирование. В ролевой модели доступа RBAC права назначаются ролям, а пользователи получают их через назначенные роли. Такой подход упрощает управление и проверку доступа. Он должен опираться на принцип минимальных привилегий: роль получает только тот доступ, который нужен для выполнения её рабочих задач. ([csrc.nist.gov](https://csrc.nist.gov/projects/role-based-access-control?utm_source=openai))

Составьте матрицу ролей и прав

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

  • Видит ли пользователь все записи, только записи своей организации или только назначенные ему?
  • Могут ли два человека согласовать один объект, или согласование должно быть разделено между ролями?
  • Меняют ли маршрут согласования сумма, регион, тип документа или уровень риска?
  • Может ли пользователь приглашать коллег и в каких пределах?
  • Является ли конфиденциальным уже сам факт существования ограниченной записи?

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

Стройте навигацию вокруг задач, а не вокруг модулей

Одинаковое меню для всех ролей часто ухудшает B2B customer portal UX. Клиенту редко нужен раздел «Журнал аудита», а сотруднику не обязательно видеть заметный пункт «Создать новую заявку», если его работа начинается с очереди назначенных обращений. Навигацию стоит строить вокруг повторяющихся рабочих задач, а главный экран — вокруг того, что требует внимания сейчас.

В кабинете клиента приоритетными разделами могут быть «Активные заявки», «Документы», «Сообщения», «Счета» и «Команда». Для сотрудника логичны «Моя очередь», «Ожидают проверки», «Исключения», «Эскалации» и «Риск нарушения SLA». Для администратора — «Пользователи и роли», «Настройки организации», «Интеграции» и «Журнал аудита».

Дашборд не должен пытаться показать все показатели бизнеса. Он должен отвечать на три вопроса: что требует действия, что изменилось и куда перейти дальше. Карточки вроде «Два документа ожидают вашей подписи», «По пяти обращениям нужен ответ сегодня» или «У трёх приглашений истёк срок» полезнее декоративных графиков без следующего шага.

Сделайте статус, документы и ответственность прозрачными

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

Например, на странице согласования договора полезно показать:

  1. Текущий этап: юридическая проверка, финансовое согласование или подпись клиента;
  2. Когда запись обновлялась в последний раз и кем;
  3. Какая роль отвечает за следующий шаг;
  4. Какой документ, исправление или решение блокирует завершение;
  5. Понятное ожидание по сроку, если бизнес может его корректно указать.

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

Пустые состояния — это часть пользовательского сценария

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

Проектируйте согласования без лишнего трения, но с контролем

UX админ-панели — это не только таблица и фильтры. Административные действия могут иметь серьёзные последствия: повышение роли сотрудника, изменение правила процесса, экспорт клиентских данных или отключение учётной записи. Для значимых действий используйте подтверждение с описанием результата. Фраза «Этот пользователь получит доступ ко всем счетам Acme Ltd.» гораздо понятнее, чем абстрактное «Вы уверены?».

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

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

Адаптивность — не просто более узкий экран

Использование customer self-service portal часто зависит от задачи. Клиенту удобно проверить статус, открыть уведомление или сфотографировать документ с телефона. Сотруднику, который обрабатывает плотную очередь, может быть нужен desktop для широких таблиц, сравнений и массовых операций. Поэтому стратегию для устройств нужно определять на уровне каждого сценария, а не просто сжимать desktop-интерфейс до мобильного.

  • Приоритет для mobile: проверка статуса, переход из уведомления, загрузка документа, короткое согласование и сообщения.
  • Приоритет для desktop: сложная фильтрация, массовые изменения, длинные таблицы, сравнение записей и настройка системы.
  • Для всех устройств: единые статусы, одинаковая логика прав, сохранённый контекст и восстанавливаемые формы.

Доступность должна быть частью определения качества: управление с клавиатуры, заметный фокус, достаточный размер сенсорных целей, единообразная помощь и доступная аутентификация важны в защищённых продуктах так же, как и на публичных сайтах. WCAG 2.2 включает критерии, связанные с фокусом, размером целей, постоянством помощи и доступной аутентификацией. ([w3.org](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/?utm_source=openai))

Одна дизайн-система для клиентского и внутреннего интерфейса

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

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

Когда перед разработкой нужен UX discovery

Стоит провести UX discovery до начала разработки, если на несколько вопросов ниже нет ясного ответа:

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

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