Личный кабинет и порталы: что важно при разработке

Личный кабинет давно перестал быть «страницей с профилем». Сегодня это рабочее место клиента, партнёра или сотрудника, через которое проходят деньги, документы и персональные данные. Ошибка в архитектуре кабинета стоит дороже, чем ошибка в landing page: здесь ломается не конверсия, а доверие и иногда закон. Ниже — то, на что мы в OneDev смотрим в первую очередь, когда проектируем кабинет или корпоративный портал.

Роли и доступы: фундамент, а не настройка «потом»

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

Правильный путь — заранее описать роли через права (permissions), а не через жёсткие «должности». Роль — это набор разрешений на действия и объекты. Тогда новую должность вы собираете из готовых кубиков, а не переписываете код.

• RBAC (доступ по ролям) покрывает 90% B2B-кабинетов: оператор, менеджер, бухгалтер, владелец.
• ABAC / scoping нужен, когда доступ зависит от данных: «менеджер видит только свой филиал», «партнёр — только своих клиентов».
• Мультиаккаунт и делегирование: один человек работает в нескольких организациях, владелец передаёт права заместителю.

UX кабинета: скорость и предсказуемость важнее красоты

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

На что мы обращаем внимание на практике:

• Понятная навигация и состояние. Пользователь всегда должен видеть, где он, что загружается, что сохранилось, а что — нет.
• Пустые состояния и онбординг. Новый клиент не должен видеть пустой экран без подсказки, что делать первым.
• Ошибки по-человечески. Не «Error 500», а что произошло и что делать. Особенно в платежах и загрузке документов.
• Производительность списков. Тысячи строк — это пагинация, серверная фильтрация и кэш, а не «подгрузим всё и отфильтруем на фронте».
• Мобайл и язык. В Узбекистане кабинет часто открывают с телефона, а интерфейс нужен минимум на двух-трёх языках (ўзбекча, русский, English). Локализацию закладывают сразу, а не «допиливают».

Интеграции: кабинет редко живёт сам по себе

Портал почти всегда — это узел, связанный с другими системами. Для рынка Узбекистана типичный набор интеграций выглядит так:

• Платежи: Payme, Click, Uzum, эквайринг банков. Важно правильно обрабатывать вебхуки и сверять статусы, а не доверять одному ответу от фронта.
• Документооборот и налоги: Didox, ЭСФ, выгрузки для бухгалтерии.
• Идентификация: OneID, SMS-провайдеры (Eskiz, Play Mobile), при необходимости — сверка по ПИНФЛ.
• Внутренние системы: 1С, CRM, ERP, складские и логистические сервисы.

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

Безопасность: персональные данные и деньги в одном месте

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

• Аутентификация. Надёжные сессии, защита от перебора, опциональная двухфакторка для ролей с доступом к деньгам и настройкам.
• Авторизация на каждом запросе. Проверка прав должна быть на бэкенде по каждому действию, а не «спрятали кнопку на фронте». Скрытая кнопка — это не защита.
• Изоляция данных между арендаторами. В мультиаккаунтных порталах самый опасный класс багов — когда один клиент по прямой ссылке или подмене ID видит чужие данные. Это проверяется на уровне запросов к БД.
• Шифрование и хранение секретов. Токены и ключи — не в коде и не в git, а в защищённом хранилище. Трафик — только по HTTPS.
• Минимизация данных. Не собирать и не хранить лишнего; то, что не хранится, невозможно утечь.

Аудит и наблюдаемость: видеть, что происходит

Когда в кабинете крутятся деньги и документы, рано или поздно возникает вопрос «кто и когда это сделал». Без журнала действий ответа не будет, а спор с клиентом или сотрудником превратится в слово против слова.

• Журнал действий (audit log): кто, что, когда, с какого устройства изменил. Особенно для платежей, прав доступа и изменения реквизитов.
• Неизменяемость записей: логи нельзя редактировать из самого кабинета — иначе они теряют доказательную силу.
• Мониторинг и алерты: ошибки, всплески отказов платежей, недоступность интеграций — лучше узнать от системы, чем от рассерженного клиента.
• Метрики продукта: что реально используют, где застревают. Это основа для развития кабинета, а не догадки.

Аудит — это ещё и удобство поддержки: когда клиент пишет «у меня не прошла оплата», по логу видно, что именно сломалось, без догадок и долгих переписок.