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