Дизайн личного кабинета: B2B, e-commerce, MedTech и другие сферы

Личный кабинет — это не список данных о пользователе. Это второй продукт внутри продукта. Человек возвращается сюда каждый день: заказать, проверить, оплатить, записаться, посмотреть прогресс. Основной продукт решает задачу пользователя. Личный кабинет помогает возвращаться к ней снова и снова.

Проблема в том, что дизайнеры часто проектируют ЛК по одному шаблону: слева меню, сверху аватар, справа карточки. Такой шаблон работает в одном продукте и ломается в другом. Кабинет пациента и кабинет оптового клиента — это разные продукты, которые живут по разным правилам. Ниже — как я подхожу к проектированию личных кабинетов и что меняется в зависимости от сферы.

Почему личный кабинет — это второй продукт

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

Поэтому я не рассматриваю ЛК как «экран настроек» или «список заказов». Это самостоятельная среда со своей навигацией, состояниями, приоритетами. И у каждой сферы — свои.

Что общего у всех личных кабинетов

Есть пять вещей, которые должны работать в любом ЛК, независимо от сферы:

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

Это база. Дальше — то, что отличает кабинеты друг от друга. Если хотите увидеть, как эти принципы разворачиваются в конкретной сфере, посмотрите страницу услуги UI/UX дизайн продуктов.

B2B: роли, права, согласования

B2B-кабинет — это не «кабинет для компании». Это кабинет, в котором параллельно работают 5–15 человек с разными ролями. Один создаёт заявку, второй согласовывает, третий оплачивает, четвёртый смотрит отчёт. Дизайн B2B-ЛК — это в первую очередь дизайн ролей и прав?RBAC (Role-Based Access Control) — модель, в которой доступ к функциям определяется ролью пользователя: администратор, менеджер, наблюдатель. От роли зависит, какие кнопки и разделы человек видит..

Что здесь меняется по сравнению с обычным ЛК:

• История действий — кто что изменил и когда.
• Согласования — заявка идёт по цепочке от одного человека к другому.
• Уведомления не «у вас новое сообщение», а «заявка ждёт вашего согласования».
• Массовые операции — выгрузить 200 позиций, а не открывать каждую по отдельности.
• Разделение «мои задачи» и «задачи компании».

Если в B2B-кабинете не проработать роли и права, интерфейс быстро начинает ломаться при появлении новых участников и сценариев. Подробнее об этом — на странице дизайн личного кабинета для B2B, а если хотите шире — посмотрите направление дизайн для B2B-продуктов.

E-commerce: повторные покупки и статусы

В интернет-магазине пользователь заходит в ЛК не «посмотреть историю», а сделать конкретное действие: повторить заказ, отследить доставку, оформить возврат, потратить бонусы. Если каждое из этих действий требует 4–5 кликов — кабинет не работает.

Что важно:

• Повтор заказа в один клик — не через корзину заново.
• Статус заказа виден без входа в детали: «в пути», «ожидает в пункте выдачи», «доставлен».
• Возврат — не квест на семь шагов. Две кнопки: «вернуть» и «выбрать причину».
• Бонусы и баллы — на видном месте, с понятным сроком сгорания.

Отдельная история — личный кабинет покупателя. А базовые принципы для всей сферы — в разделе направления дизайн для e-commerce.

MedTech: приватность и логика врача

Самый чувствительный тип ЛК. Здесь работают не с заказами, а с данными о здоровье. Правила меняются радикально:

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

Про личный кабинет пациента у меня есть отдельная страница. А если делаете платформу целиком — смотрите направление дизайн для MedTech.

EdTech: личный кабинет как мотиватор

Ученик должен заходить в ЛК не потому, что «надо», а потому что интересно. Здесь кабинет работает как часть продукта обучения, а не как админка.

• Прогресс визуально и с конкретикой. Не «47%», а «осталось два модуля и финальный тест».
• Домашки и дедлайны — на виду. Пропущенный дедлайн должен быть заметен сразу, а не через два раздела.
• Сертификаты — то, за чем возвращаются. Их должно быть легко скачать и легко показать.
• Геймификация, если она есть, живёт в ЛК. Достижения, стрики, рейтинг — не в отдельной вкладке «прогресс», а на главной кабинета.
• Родительский кабинет — отдельно. У родителя и ученика разные задачи и разный доступ.

Про личный кабинет ученика есть отдельная страница. А если нужно шире — направление дизайн для EdTech.

SaaS: подписка, лимиты, команда

В SaaS кабинет — это центр управления подпиской и командой. Здесь самая высокая цена ошибки: если пользователь не понял, как пригласить коллегу, он не вернётся и не оплатит тариф.

• Тарифы, лимиты, апгрейды. Пользователь всегда видит, что входит в его план и когда упрётся в лимит.
• Команды и права. Приглашение людей — не спрятанная функция, а один из главных экранов.
• Интеграции и API-ключи?API-ключ — уникальный токен, по которому внешние сервисы получают доступ к вашему аккаунту. В SaaS это один из первых разделов, куда заходят пользователи при настройке интеграций.. В SaaS это то, что подключают в первую неделю.
• Биллинг и счета. Скачать счёт, изменить способ оплаты, увидеть историю списаний — без обращений в поддержку.
• Использование ресурсов. Сколько места занято, сколько API-запросов, какие сервисы активны.

Проектирование личного кабинета для SaaS я разбираю отдельно. Общий контекст — в направлении дизайн для SaaS.

RealEstate: сделка на несколько месяцев

В недвижимости сделка идёт не час, а месяцы. Кабинет покупателя — это не «список квартир», а трекер состояния сделки:

• Статусы. Где сейчас заявка, какой следующий шаг, кто отвечает за следующий шаг.
• Документы. Что подписано, что нет, что нужно дозагрузить.
• Ипотека. Заявки в банки, статусы одобрения, условия.
• Живой менеджер. Связь с человеком, а не чат-бот с шаблонными ответами.

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

FinTech: удобство против безопасности

В FinTech нельзя просто выбирать между удобством и безопасностью. Хороший интерфейс должен делать защищённые сценарии понятными и не заставлять пользователя воспринимать безопасность как препятствие.

• Операции и история. Фильтры, поиск, выгрузка — стандарт.
• Лимиты и настройки безопасности. Пользователь сам управляет рисками.
• 2FA?Двухфакторная аутентификация — вход по паролю плюс второй фактор (код из приложения, SMS или push). В ЛК это отдельный раздел с настройкой и списком активных сессий. и устройства. Список активных сессий, выход со всех устройств.
• KYC?Know Your Customer — процедура верификации клиента, обязательная для финансовых сервисов. В личном кабинете это отдельный раздел со статусами и загрузкой документов. — статус верификации. Понятный экран: что загружено, что проверяется, что отклонено.
• Разделы. Карты, счета, вклады, инвестиции — не свалка, а осмысленная структура.

Общие принципы — в направлении дизайн для FinTech. Про редизайн финансового приложения — отдельная страница.

Сфера меняет не оболочку, а логику

В каждом из этих продуктов можно оставить одинаковую базу: навигацию, состояния, поиск, уведомления, безопасность. Но приоритеты внутри кабинета будут совершенно разными.

В B2B на первый план выходят роли и согласования. В FinTech — операции и безопасность. В EdTech — прогресс и мотивация. В MedTech — приватность и связанные медицинские данные.

Поэтому я не начинаю проектирование ЛК с готового шаблона. Сначала разбираю продукт, пользователей и сценарии — и только потом определяю структуру кабинета.

Ошибки, которые встречаются во всех сферах

Семь проблем, которые я нахожу почти в каждом ЛК:

1. Дублирование навигации. Слева меню, справа тоже меню. Пользователь не понимает, какое главное.
2. Пустой экран без объяснений. «У вас нет данных» — и всё. Что делать, чтобы появились?
3. Скрытые действия. Удалить, отменить, выгрузить — спрятаны в три клика и иконку без подписи.
4. Мобильная версия как уменьшенный десктоп. Таблицы не влезают, кнопки слишком мелкие, фильтры уезжают за экран.
5. Долгая загрузка. Пятнадцать запросов на первом экране — пользователь ждёт дольше, чем готов.
6. Нет уведомлений. Пользователь не знает, что что-то произошло: оплата прошла, статус изменился, документ одобрен.
7. Плоская иерархия. Все разделы выглядят одинаково важными, хотя в реальности это не так.

Все эти проблемы видны на UX-аудите — обычно два-три дня, и на выходе понятный отчёт с приоритетами.

Что в итоге

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

Если пользователь звонит в поддержку, чтобы узнать статус — это провал UX, а не «особенность сферы».

Чек-лист перед стартом:

• Определите роль ЛК в продукте: retention, повторные действия, самообслуживание.
• Спроектируйте навигацию под реальные задачи, а не под красивую схему.
• Продумайте все состояния — пустое, загрузка, ошибка, успех.
• Не копируйте шаблон: в каждой сфере свои правила.
• Тестируйте на реальных пользователях, а не на своём представлении о них.

Хороший личный кабинет — невидимый. Человек делает то, что ему нужно, и не замечает дизайна. Если заметил — значит, где-то сломалось.

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