Личный кабинет — это не «страница с профилем», а сердце платформы: место, где пользователь работает с данными, а бизнес — с пользователем. Ошибки в его проектировании всплывают позже всех и стоят дороже всех, потому что вокруг кабинета вырастает вся система. Разберём, с каких решений начинается проектирование и почему порядок здесь важен.
Роли: кто приходит в систему
Первый вопрос — не «какие будут экраны», а «кто пользователи и чем их работа отличается». Клиент, исполнитель, менеджер, администратор, бухгалтер — у каждой роли свои задачи, свои данные и свой кабинет, даже если визуально они похожи. Список ролей определяет всё остальное, и добавление забытой роли посреди разработки перетряхивает проект сильнее, чем любая новая функция.
Полезное упражнение — описать один рабочий день каждой роли: с чем человек приходит в систему, что делает, с чем уходит. Такие описания находят пробелы раньше макетов.
Права доступа: кто что видит и делает
Из ролей вытекает модель прав: кто какие данные видит, какие может менять, какие действия ему доступны. Здесь всплывают тонкости, которые не видны на поверхности: менеджер видит только своих клиентов или всех; кто может отменить оплаченный заказ; что происходит с данными сотрудника после увольнения. Модель прав проектируется до интерфейсов — попытка «прикрутить» её к готовым экранам почти всегда рождает дыры.
Модель данных: сущности и их связи
Параллельно с ролями описываются сущности платформы — заказы, документы, счета, объекты — и связи между ними. На этом уровне решаются вопросы, которые потом почти невозможно поменять дёшево: может ли у заказа быть несколько исполнителей, привязан ли документ к клиенту или к сделке, что происходит с историей при удалении. Модель данных — это скелет платформы: интерфейсы поменять можно, скелет — только хирургически.
Сквозные сценарии до отдельных экранов
Проектировать стоит от процессов, а не от страниц: заявка прошла путь от создания до закрытия — какие роли её касались, какие статусы она прожила, какие уведомления кто получил. Сквозные сценарии связывают кабинеты разных ролей в единую систему и выявляют стыки, где процессы рвутся. Экраны после этого рисуются почти сами — они просто обслуживают понятный процесс.
Что заложить с первого дня
Есть вещи, которые дёшево заложить сразу и дорого добавлять потом: журнал действий — кто и когда что изменил, без него не разобрать ни один спорный случай; продуманная система статусов и уведомлений; безопасная авторизация и восстановление доступа; экспорт данных для отчётности. Ничто из этого не выглядит эффектно на презентации, но именно это отличает платформу, которой можно доверять бизнес-процессы.
Путь к первой версии
Платформу с кабинетами не обязательно строить целиком сразу. Рабочая стратегия — выбрать одну роль и один сквозной процесс, довести их до конца и запустить, подключая остальные роли поэтапно. Так первая ценность появляется раньше, а обратная связь реальных пользователей корректирует проектирование остальных частей.
Коротко
Хорошая платформа начинается не с макетов, а с ролей, прав и модели данных — решений, которые определяют её на годы вперёд. Мы проектируем и строим платформы с личными кабинетами именно в таком порядке: сначала скелет, потом тело. Расскажите о своём процессе — предложим архитектуру под него.