UX личного кабинета: структура, статусы, формы

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

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

Если кабинет пишут с нуля или пересобирают старый, дизайн и разработку выгоднее вести одной командой: тогда сценарии, роли и интеграции с учётной системой обсуждаются ещё до макетов, а не всплывают на этапе вёрстки. Такую YuSMP Group делает полным циклом — от исследования сценариев до подключения CRM и платёжных систем. Но независимо от того, кто будет писать код, логика проектирования одна — её и разберём по шагам.

Чем личный кабинет отличается от обычного сайта?

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

• Повторные визиты. Человек приходит в кабинет регулярно и запоминает расположение элементов. Любая перестановка ломает выученный маршрут, поэтому стабильность структуры важнее визуальной новизны.
• Персональные данные. Всё, что видит пользователь, — его заказы, его деньги, его документы. Ошибка в отображении суммы или статуса воспринимается не как баг, а как угроза.
• Задача вместо интереса. На сайте пользователя нужно увлечь, в кабинете — не мешать. Маркетинговые баннеры, которые уместны на главной, здесь отнимают внимание от действия.

Из этого следует простое правило: оценивать кабинет нужно не по тому, насколько он красив на скриншоте, а по тому, за сколько шагов и секунд пользователь решает типичную задачу. Красота важна, но вторична — она должна поддерживать иерархию, а не конкурировать с ней.

С чего начать проектирование личного кабинета?

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

1. Соберите реальные поводы визита. Лучшие источники — обращения в поддержку, логи поиска по сайту, аналитика текущего кабинета (какие страницы открывают чаще всего) и короткие интервью с пятью-семью клиентами. Как проводить такие интервью и тесты малыми выборками, мы разбирали в материале о юзабилити-тестировании на пяти пользователях.
2. Сформулируйте задачи в формате «когда… хочу… чтобы…». Например: «когда приходит уведомление об отгрузке, хочу увидеть, где посылка, чтобы спланировать день». Формулировка сразу подсказывает, какой экран нужен и какие данные на нём главные.
3. Отранжируйте задачи по частоте и важности. Обычно три-пять задач покрывают 80–90 % визитов. Именно они получают место на первом экране и в основной навигации.
4. Опишите роли. Покупатель, бухгалтер компании-клиента, администратор аккаунта, сотрудник поддержки — у каждого свой набор задач и прав. Роли нужно зафиксировать до макетов, иначе их придётся встраивать в готовый интерфейс заплатками.
5. Нарисуйте карту сценариев, а не карту страниц. Для каждой главной задачи — путь от входа до результата, с ветками ошибок и пустых состояний. Только после этого из сценариев собирается структура разделов.

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

Какой должна быть структура и навигация?

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

Несколько практических правил:

• Пять-семь пунктов в основной навигации. Если разделов больше, часть из них — на самом деле вкладки внутри других разделов или редкие настройки, которые можно убрать в меню профиля.
• Названия — словами пользователя. «Мои заказы» понятнее, чем «История транзакций»; «Счета и оплата» понятнее, чем «Финансовый модуль».
• Боковое меню на десктопе, нижняя панель на мобильном. На телефоне четыре-пять главных разделов уходят в нижнюю панель, остальное — в пункт «Ещё» или в профиль.
• Текущее положение всегда видно. Активный пункт меню, заголовок экрана и хлебные крошки на глубоких страницах — особенно в B2B-кабинетах, где пользователь проваливается в карточку заказа, оттуда в документ, оттуда в позицию.
• Поиск — если объектов больше пары десятков. Номер заказа, номер договора, название товара. Поиск в кабинете часто важнее, чем меню.

Типовой набор разделов для большинства кабинетов выглядит так: обзор (главная кабинета), основной объект (заказы, заявки, полисы, курсы), деньги (счета, платежи, бонусы), документы, сообщения или поддержка, профиль и настройки. Всё остальное — производные, которые стоит добавлять только при подтверждённой потребности.

Что показать на первом экране кабинета?

Первый экран — это не приветствие и не баннер с акцией. Это ответ на вопрос «что сейчас происходит и что мне делать дальше». В нём три слоя.

1. Статус. Активные заказы и их текущий этап, баланс, ближайший платёж, срок действия подписки или полиса. То, ради чего человек чаще всего заходит.
2. Следующее действие. Одна главная кнопка, привязанная к статусу: «Оплатить счёт», «Подтвердить доставку», «Загрузить документ». Если требуемых действий несколько — список задач с приоритетом, а не три равнозначные кнопки.
3. Быстрый доступ. Ссылки на частые задачи — повторить заказ, скачать акт, написать в поддержку.

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

Как проектировать статусы, уведомления и пустые состояния?

Статусы — сердце кабинета. Именно из-за непонятного статуса клиенты звонят в поддержку. Хороший статус отвечает на три вопроса: что происходит, что будет дальше и когда.

• Шкала этапов вместо одного слова. «Обрабатывается» ничего не говорит. Таймлайн «Принят → Собран → Передан в доставку → Доставлен» с датой у каждого шага снимает большую часть вопросов.
• Цвет — не единственный признак. Зелёный и красный значки дополняйте текстом или иконкой: это требование критерия 1.4.1 WCAG и просто здравый смысл для пользователей с нарушением цветовосприятия.
• Срок или ожидание. «Ответим в течение рабочего дня», «Деньги поступят до 12 ноября». Конкретная дата снижает тревогу сильнее, чем любая иллюстрация.

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

Пустые состояния — одна из самых недооценённых частей кабинета. Новый пользователь видит пустые разделы чаще, чем заполненные. Пустой экран с надписью «Нет данных» выглядит как ошибка. Хорошее пустое состояние объясняет, что здесь появится, и предлагает первое действие: «Здесь будут ваши заказы. Начните с каталога» или «Документы появятся после подписания договора». Полный набор состояний компонента — от загрузки до ошибки — удобно сверять по нашему чек-листу состояний компонентов.

Как устроить формы и редактирование данных?

В кабинете постоянно что-то редактируют: адрес доставки, реквизиты компании, телефон, состав команды. Здесь работают все правила хороших форм, но есть специфика.

• Предзаполнение. Всё, что система уже знает, подставляется автоматически. Критерий 3.3.7 WCAG 2.2 (Redundant Entry) прямо требует не заставлять пользователя повторно вводить данные, которые он уже указал в том же процессе.
• Режим просмотра и режим правки. Профиль по умолчанию показывается как читаемая карточка, а поля открываются по кнопке «Изменить». Так пользователь случайно не испортит данные и сразу видит, что именно хранится.
• Сохранение по секциям. Длинный профиль с одной кнопкой «Сохранить» внизу — источник потерянных правок. Каждая секция сохраняется отдельно и подтверждает результат.
• Чувствительные изменения — с подтверждением. Смена почты, телефона, реквизитов для выплат требует повторного подтверждения кодом. Это защищает и пользователя, и бизнес.
• Понятные ошибки рядом с полем. Не «Ошибка валидации», а «ИНН должен состоять из 10 или 12 цифр».

Подробно про маски, автозаполнение и тексты ошибок — в материале «Формы, которые заполняют». Всё сказанное там для кабинета верно вдвойне: формы здесь заполняют повторно, и каждое неудобство накапливается.

Как учесть роли и права в B2B-кабинете?

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

• Матрица ролей до макетов. Таблица «роль × действие»: кто видит цены, кто может оформить заказ, кто подписывает документы, кто управляет пользователями.
• Скрывать или блокировать. Действия, которые роли недоступны вообще, лучше скрыть. Действия, которые требуют согласования, — показать с пояснением «Отправить на согласование руководителю».
• Цепочки согласования. Статус «Ждёт согласования», имя согласующего, кнопка напоминания. Без этого заказ «зависает», и никто не понимает, где.
• Переключение между компаниями. Если один человек работает за несколько юрлиц, переключатель компании должен быть заметным и всегда показывать, от чьего имени вы действуете.

Отдельный слой — журнал действий: кто и когда изменил реквизиты, кто оформил заказ. Для B2B это не прихоть, а основа доверия и разбора спорных ситуаций.

Чем отличаются кабинеты в разных сферах?

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

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

Как сделать кабинет доступным и удобным на телефоне?

Существенная доля визитов в клиентский кабинет приходится на телефон: проверить статус, оплатить по ссылке из сообщения, показать документ. Мобильная версия не может быть урезанной копией десктопа.

• Главные задачи — в одно касание. Оплата, статус, документ — без горизонтальной прокрутки и разворачивания таблиц.
• Таблицы превращаются в карточки. Таблица заказов из восьми колонок на телефоне становится списком карточек с тремя главными полями и переходом в детали.
• Зоны нажатия. Критерий 2.5.8 WCAG 2.2 требует минимум 24×24 CSS-пикселя, гайдлайны платформ рекомендуют 44–48 точек. Для кабинета, которым пользуются на ходу, ориентируйтесь на верхнюю границу.
• Вход без мучений. Критерий 3.3.8 (Accessible Authentication) запрещает требовать от пользователя запоминать или переписывать коды вручную без альтернатив. Разрешите вставку пароля, менеджеры паролей, вход по коду из сообщения и биометрию в приложении.
• Фокус и контраст. Видимый фокус при навигации с клавиатуры, контраст текста не ниже 4,5:1. Подробности — в нашем разборе требований WCAG 2.2 к контрасту и фокусу.

Полный перечень критериев — в официальной спецификации WCAG 2.2 консорциума W3C. Доступность в кабинете — не только этика: именно здесь пользователь совершает целевые действия, и каждый, кто не смог войти или оплатить, — потерянный клиент.

Как совместить безопасность и удобство?

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

• Многоуровневая защита. Просмотр статуса заказа может быть доступен по ссылке из письма, а смена реквизитов для выплат — только после повторного подтверждения.
• Долгие сессии на доверенных устройствах. Выкидывать пользователя каждые 15 минут оправдано в банке, но не в кабинете магазина.
• Понятные настройки приватности. Кто видит мои данные, какие устройства подключены, как выйти со всех устройств, как удалить аккаунт. Это не юридическая галочка, а часть интерфейса.
• Предупреждения о необычной активности. Вход с нового устройства — уведомление с кнопкой «Это не я».

Хорошая проверка: может ли пользователь, не читая инструкций, найти, где удалить аккаунт и отозвать доступ устройства? Если нет — приватность пока существует только в политике конфиденциальности.

Как проверить, что кабинет действительно удобен?

Мнение команды о собственном интерфейсе почти всегда слишком оптимистично. Проверять кабинет нужно на реальных задачах и цифрах.

1. Тестирование задач. Дайте пяти-семи пользователям три-пять типичных задач и засеките успешность и время. Группа Nielsen Norman описывает эту методику в руководстве по юзабилити-тестированию.
2. Метрики задач. Доля успешно выполненных задач, среднее время, число ошибок. Для кабинета это важнее, чем общая конверсия сайта.
3. Опросник SUS после теста. Десять вопросов дают сравнимую оценку удобства, которую можно отслеживать от релиза к релизу. Как считать SUS и строить метрики по модели HEART, мы разбирали в статье о UX-метриках.
4. Обращения в поддержку. Тематика тикетов до и после редизайна — самый честный показатель. Если вопросов «где мой заказ» стало меньше — статусы работают.
5. Аналитика путей. Где пользователи бросают сценарий, какие страницы открывают по кругу, куда уходят после первого экрана.

Замеры стоит снять до изменений: без базовой линии невозможно доказать, что новый кабинет лучше старого.

Какие ошибки встречаются чаще всего?

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

Чек-лист перед передачей в разработку

1. Описаны три-пять главных задач и для каждой — сценарий с ветками ошибок.
2. Есть матрица ролей и прав, если пользователей у аккаунта больше одного.
3. Основная навигация — не больше семи пунктов, вложенность — не больше трёх уровней.
4. Первый экран показывает статус и одно главное следующее действие.
5. У каждого статуса есть текст, этап, срок и не только цветовое обозначение.
6. Для каждого раздела нарисованы пустое состояние, загрузка и ошибка.
7. Формы предзаполнены, сохраняются по секциям, ошибки описаны по-человечески.
8. Мобильные макеты главных сценариев сделаны отдельно, таблицы превращены в карточки.
9. Проверены контраст, фокус, размер зон нажатия и вход без ручного переписывания кодов.
10. Описаны настройки приватности, выход со всех устройств и удаление аккаунта.
11. Определены метрики успеха и сняты значения «до».

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

Редакция Флагштока

Пишем об UX/UI-дизайне: исследования, интерфейсы, дизайн-системы и доступность.